Access control

Human access

The design separates organization-level administration from workspace-level operation. A user should receive only the administrative and review capabilities required for the work they perform.

Examples include:

• organization administration across multiple workspaces;
• workspace administration for agents, routes, policies, and members inside one boundary;
• reviewer roles that can decide held actions without receiving unrelated administration rights;
• read-only or evidence-review access for investigation and audit workflows.

Agent authority

An agent is designed to be treated as a non-human identity rather than a generic application label. Its effective authority is designed to be derived from the routes, connections, assigned capabilities, policies, environment, and other controls that apply to that agent.

By design, connecting a provider, API, or MCP server does not automatically grant an agent every capability available on that connection.

Approval separation

Where a policy requires human review, reviewer eligibility is designed to be checked independently from the agent requesting the action. An approval should apply to the action that was reviewed rather than becoming a broad permission for similar future actions.

Workspace boundaries

Workspaces are designed as governance boundaries for agents, routes, policies, provider credentials, evidence, and local administration. Organization-level controls may set a shared baseline while a workspace can apply stricter local policy.

Administrative actions

Sensitive administrative actions should be authenticated, role-scoped, and reviewable. Administrative access must not be silently conflated with the authority of the agents being governed.