Centralized governance for AI agents and users
One policy layer. Humans and AI follow the same rules.
Centralized governance for AI agents and users means one set of workspace roles, one set of per-zone access levels, and one audit trail that covers both. Not a user access product with an agent-governance bolt-on. The agent in a zone sees exactly what the zone's policy allows, and nothing more.
// The problem
Two stacks for governance is one too many.
Most AI governance platforms are stapled onto an existing identity stack. Users are governed in one place. Agents are inventoried, policed, and audited in another. The policy on one side never aligns to the policy on the other, and the audit trails never line up.
That gap is where the real risk lives. An agent runs under a service account that bypasses the user policy. A document that was out of reach for a reader is suddenly reachable for the agent they summoned. A workspace isolates teams, except the connector pool is shared.
The whole point of centralized governance is to collapse those two surfaces into one.
// What one layer looks like
Bolt-on vs. unified governance.
Agent governance bolted on
Two stacks. Two policies. One audit gap.
- Users live in SSO; agents live in a separate agent registry.
- User roles and agent policies drift apart over time.
- Connectors are a shared pool across the whole org.
- Agent audit log is a different format in a different system.
- Spend by agent and spend by user are reconciled by hand.
- An agent can see a document the user who summoned it cannot.
Governance centralized by workspace
One policy. One audit. Agents inherit.
- Users and agents live in the same workspace, same roles.
- Per-zone access (DISCOVER, READ, WRITE, ADMIN) applies to both.
- Connections are workspace-scoped; no cross-workspace leak.
- One audit stream covers human actions and agent runs.
- Spend reports credit cost to the user who authorized the run.
- An agent inherits the owner's access. It never exceeds it.
// Mechanics
The four-tier zone policy.
Every zone has an access level per workspace member. The same four levels apply when an agent runs inside that zone under that member's authorization.
LEVEL 1
DISCOVER
The zone exists. No content is read, no documents listed. Used to let a user know a zone is out there without exposing anything inside it.
LEVEL 2
READ
Open the zone, read conversations, open documents, view runs. Agents at this level can read, cannot write.
LEVEL 3
WRITE
Create conversations, start runs, upload documents, invoke tools. Produces billable work. Agents at this level act, inside policy.
LEVEL 4
ADMIN
Manage the zone itself: members, policy, tools, connections. Only workspace OWNER/ADMIN get this by default; MEMBER requires explicit grant.
// What the policy covers
Six mechanisms, one layer.
Centralized governance is only real if it covers every surface an agent can touch. Here is what the policy touches in In My Mind.
01 · Workspace roles
OWNER, ADMIN, MEMBER.
Three workspace-level roles. OWNER sets policy and billing. ADMIN manages people, zones, and spend. MEMBER works inside the zones they are added to. Agents inherit the role of the user who runs them.
02 · Zone access
DISCOVER, READ, WRITE, ADMIN.
Per-zone access, per member. The same four levels gate both human and agent operations inside the zone. An agent cannot cross a zone boundary its owner cannot cross.
03 · Admin RBAC
Scoped admin, not root.
Platform admin is sliced into scopes: billing, models, users, cost analytics, support, triage. SUPER_ADMIN bypass is reserved and auditable. Every admin action is tied to a scope grant.
04 · Connections
Workspace-scoped, never shared.
Every OAuth, API key, and MCP server is attached to one workspace. Marketing's Salesforce never surfaces in Finance. Custom tools follow the same rule and are prompt-injection filtered.
05 · Attended runs
Autonomous means owner-attended.
Autonomous and scheduled runs always carry an owner identity. The run acts as that owner, with that owner's access and credentials. There is no anonymous service account quietly bypassing policy.
06 · Audit + spend
One stream, two views.
Human actions and agent runs land in the same audit stream, cross-referenced by zone, workspace, and owner. Spend is attributed to the user who authorized the run. OWNER/ADMIN see all member spend; MEMBER sees their own.
// Related
Where governance meets the spatial UI.
Centralized governance only scales if the interface respects the policy. The spatial UI makes a zone a visible, navigable boundary. You see where you can go, where you cannot, and what the AI inside each zone is allowed to touch. The policy is not a config file in a settings menu. It is the shape of the map.
That is why both pieces matter together. Read more on the spatial UI for AI workspaces, or jump to Enterprise & Compliance for SOC-ready deployment, SSO, and on-prem.
Enterprise
SOC-ready, SSO, on-prem option, full compliance surface.
Explore →
Teams
Multi-workspace, roles, per-zone access, shared playbooks.
Explore →
Security
Trust by architecture. Isolation, audit, encryption at rest.
Explore →
Spatial UI
The interface that makes governance visible, not configurable.
Explore →
// Governed from day one
Start a workspace with governance in place.
Every workspace ships with the same policy layer. Roles, zone access, scoped admin, workspace connections, attended runs, audit. There is no later for governance.