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.