Skip to content
Bizzi AI Governance Framework
Pillar V: AI Security · § 09

Agent RBAC and excessive agency (LLM08)

LLM08 is the risk that an AI agent acts with privileges the user does not hold. The blast radius of a prompt injection or a logic bug depends entirely on what the agent was authorised to do at the moment of failure. An agent that only sees one user’s data caps its own failure mode at that user’s data. An agent with platform-wide rights caps its failure mode at “everything”. The Bizzi position is the first one, enforced architecturally.

The threat

Section titled “The threat”

When prompt injection succeeds (we plan against the case where it does), the question that decides the impact is “what does this agent do at all?” If the agent runs with the user’s token and the user is an accountant, the worst case is what that accountant does. If the agent has elevated rights for operator convenience, the worst case is the whole tenant, or the whole platform.

Token inheritance

Section titled “Token inheritance”

The pattern is mechanical and verifiable end-to-end. The user authenticates. The API spawns an agent with the user’s token pinned into the agent’s context. The agent’s tool calls carry that token forward. The MCP layer enforces row-level security against it.

  • User Accountant A
  • API Bizzi gateway
  • Agent Spawned with token
  • MCP Access layer
  • DB OLAP store
  1. 01 User API Request + JWT (scope=tenant, role=accountant)
  2. 02 API Agent Spawn agent with scoped token
  3. 03 Agent MCP Query with scoped token attached
  4. 04 MCP self Validate token, inject tenant filter
  5. 05 MCP DB SQL with row-level security
  6. 06 DB MCP Filtered results
  7. 07 MCP Agent Sanitised response
  8. 08 Agent API Output
  9. 09 API User Response
Access Token inheritance. Token issued at the user boundary travels with every call, enforced at MCP.

Implementation

Section titled “Implementation”

The Access Token inheritance rule has four concrete properties.

  • User authenticates to Bizzi and receives a JWT with user_id, tenant_id, role, and permissions claims.
  • Agent spawn pins the token into the agent’s runtime context. The agent has no other identity.
  • Tool calls forward the token to MCP and to internal APIs, which validate and scope every call.
  • Agents do not request escalation. There is no token-exchange endpoint that grants an agent rights beyond the calling user’s. Code review enforces this.

No superadmin agent

Section titled “No superadmin agent”

The phrase is not aspirational. We do not create elevated-privilege agents for operator convenience, batch jobs, or “trusted internal” workflows. The reasoning is conservative. A single moment of weakness (a prompt injection, a misconfigured tool, a logic bug) in a superadmin agent is a tenant-wide or platform-wide incident. Administrative actions (tenant configuration, user management, schema changes) stay in human-only workflows. The cost of the discipline is some operator inconvenience. The cost of breaking the discipline is unbounded.

Cross-tenant isolation

Section titled “Cross-tenant isolation”

Tenant isolation is enforced at MCP, not at the agent. An agent serving a user in tenant A has no path to tenant B’s data even if the prompt asks for it.

  • Every MCP query receives an injected tenant_id filter matching the calling user’s token.
  • The output validator (§8) scans responses for foreign tenant references before they are served.
  • Cross-tenant leakage is SEV1 by default and triggers the Kill-switch criteria in §11.

Service accounts for automation

Section titled “Service accounts for automation”

Some workflows (scheduled invoice extraction from email, periodic batch syncs) run without a human user. These use service accounts with explicitly scoped permissions, never superadmin. Service account credentials rotate on a fixed schedule and on every suspected incident. Audit trails attribute every action to the named service account so post-incident reconstruction is possible.

What Agent RBAC does not solve

Section titled “What Agent RBAC does not solve”

Agent RBAC is a layer in Defense-in-depth, not the whole story. It does not address:

  • Phishing-driven token theft. If a user is phished, the attacker holds a valid token. Defense is at the authentication layer (MFA, anomaly detection on session metadata).
  • Privilege creep. Users accumulate permissions they no longer need. Defense is periodic permission review (Pillar V §13 ISMS controls).
  • Authorised insider misuse. A user with legitimate permissions still misuses them. Defense is audit logging and behavioural monitoring.

The architectural claim is narrower than “secure agents”. It is this. When the layers above fail, the agent never has rights its caller did not already hold.

Standards mapping

Section titled “Standards mapping”