--- title: "Governing AI Without a Vendor Cloud" description: "How to govern AI use — identity, fine-grained policy and fleet-wide audit — when the control plane runs on your own server instead of a vendor cloud." url: "https://royalsoftworks.com/resources/enterprise-ai-governance/" source: "https://royalsoftworks.com" format: "markdown" note: "Markdown rendering of the HTML page at `url`. Same content, same canonical URL." --- [All resources](https://royalsoftworks.com/resources/) # Governing AI Without a Vendor Cloud ## A Policy, Identity, and Audit Plane That Runs on Your Server, Not Ours **A Royal Softworks whitepaper · AssistantGeneral** --- ## Abstract Enterprises adopting AI face a control problem: _who may use which model, against which data, with which tools — and what did they actually do?_ Cloud AI vendors answer this with governance over _their_ surface, hosted in _their_ cloud. For regulated and security- conscious organizations that is the wrong shape twice over: the data plane is outside the perimeter, and the controls cover only the vendor's own product. AssistantGeneral inverts the model. The agent runs on the employee's device, and the governance plane — policy, identity, and audit — runs on the **customer's own admin server**. This paper describes that governance plane and the principles behind it. --- ## 1\. The requirement A defensible enterprise AI deployment needs to answer, per user and per group: - **Which models** may be used (and which are forbidden)? - **Which tools, connectors, MCP servers, and messaging bridges** are permitted? - **Which knowledge bases** can each person reach? - **Which settings** can the employee change, and which are administrator-locked? - **What can leave** — can the user export or wipe data; can an administrator reach the machine remotely? - **What happened** — is there an audit trail? And it must answer all of this **without a mandatory dependency on the AI vendor's cloud**. ## 2\. The shape: customer-hosted control plane AssistantGeneral's enterprise build runs an embedded admin server — **the customer's server, on the customer's infrastructure**. Employee installs are managed clients that fetch their policy from it. There is no Royal Softworks cloud in the loop: both the data plane (on-device inference and retrieval) and the control plane (this admin server) sit inside the customer's boundary. A license _role_ — administrator versus managed user — decides whether a given install hosts the server or connects to it. ## 3\. The policy engine A managed user's capabilities are described by a single policy object that gates **every** surface of the product, including: - **Models** — the allowed providers (e.g. pin everyone to the company-hosted/on-device model), and whether the user may change the endpoint or the system prompt. - **Tools** — an explicit allow-list, and whether the user may add tool directories. - **Workflows** — which workflows are allowed; whether the user may create or delete them; whether scheduling and event triggers are permitted; whether the builder is available. - **MCP servers**, **messaging bridges**, and **connectors** — allow-lists and whether the user may add their own or sync them. - **Knowledge bases** — which the user may access; whether they may add or delete documents. - **Settings** — exactly which option groups remain editable, plus a list of administrator-locked keys. - **UI surfaces** — which gateable regions of the interface the user may even see. - **Voice** — text-to-speech and speech-to-text on or off. - **Data** — whether the user may export, import, or delete all data. - **Remote access** — whether an administrator may run read-only database queries or broker tool execution on the user's machine (off by default). ### Fail-closed and most-restrictive-merge The policy engine is designed to be safe by default: - **Fail-closed normalization** — a missing or malformed field becomes the most restrictive value (deny), so a partial or corrupt policy payload can never silently _widen_ access. - **Most-restrictive merge** — when a user belongs to multiple groups, capability flags are AND-ed, allow-lists are intersected, locked keys are unioned, limits take the smaller value, and the earliest expiry wins. A "deny" in any group denies. (Knowledge- base _data_ grants are resolved separately and remain additive — capabilities tighten, data access widens — which is the correct, intuitive behavior.) - **A usable managed default** — when an administrator hasn't authored a specific policy, managed employees get a restrictive-but-workable baseline: pinned to the company model, core/security/data settings locked, bulk export and remote control off — while everyday work (tools, workflows, knowledge bases, voice) keeps functioning. ## 4\. Identity: SSO and SCIM The admin server integrates with the organization's identity provider through **SSO (OpenID Connect)** for authentication and **SCIM** for user and group provisioning — so joiners, movers, and leavers flow from the IdP into AssistantGeneral's users, groups, and therefore policies automatically. ## 5\. Shared knowledge with access control Administrators can publish shared knowledge bases and control, per group, who may reach each one. Capability policies tighten what a user can _do_; knowledge-base grants govern what data they can _see_ — managed independently and correctly. ## 6\. Audit Actions are recorded to an audit trail and aggregated for review, giving the organization the "what did they actually do?" answer that governance requires — and that regulated environments mandate. ## 7\. Tailored interfaces: the modular UI Beyond security gating, administrators can shape _how_ the product appears per role. A **drag-and-drop layout composer** plus **surface entitlements** let an administrator issue a tailored profile, with shipped presets for **General, Legal, Medical, and Finance** teams. Security (which surfaces a user _may_ see) and presentation (where those surfaces _appear_) are decided separately — so a locked-down policy and a clean, role-appropriate layout are independent levers. ## 8\. Why this matters For the buyers who most need governed AI — legal, healthcare, finance, government — the governance plane is not a checkbox; it is the precondition for deploying at all. By making that plane fail-closed, group-aware, identity-integrated, audited, and — critically — **hosted on the customer's own server with no vendor cloud in the loop**, AssistantGeneral offers a control story that cloud-only AI products structurally cannot match. --- _To see the policy engine, SSO/SCIM, audit, and role-tailored UI running against your own identity provider and infrastructure, contact Royal Softworks._ ## Evaluate AssistantGeneral See the product this paper describes — a private, local-first AI agent with an enterprise control plane that runs on your own infrastructure. [Explore AssistantGeneral](https://royalsoftworks.com/products/assistant-general/) [Talk to us](https://royalsoftworks.com/contact/)