22 — Role-Based Access Control (RBAC)

Concept overview

Role-based access control maps users or service identities to roles and roles to permitted operations. In an agent architecture, it controls which tools can be invoked and which classes of resources can be accessed. The model can explain a requested action, but it cannot grant itself a role or establish the caller's identity.

Roles work best when they correspond to stable job responsibilities. Keep role assignment separate from role activation and apply separation of duties where one actor must not initiate and approve the same operation. Resource ownership, geography, and changing context may require additional attribute-based controls beyond a role alone.

Why it matters in production

Proof of concept

A prototype often uses one developer credential. Replace it with explicit reader and operator roles before exposing shared enterprise systems.

Production

Production centralizes role definitions, validates identity tokens, and checks permissions at tool services rather than only hiding interface buttons. Record the acting user and service identity separately.

Enterprise scale

At scale, role lifecycle and review matter as much as request-time enforcement. Prevent role explosion, revoke departed users promptly, and test nested-role behavior and privileged service-account scope.

Architecture components

Identity provider

Authenticates principals and issues trusted identity and group assertions.

Role directory

Maps approved organizational membership to stable role definitions.

Permission policy

Defines which actions and resource classes each role may access.

Enforcement point

Checks the actual tool or data request before execution.

Access review record

Tracks role grants, removals, exceptions, and separation-of-duties decisions.

The architecture, mapped

flowchart LR
 I["Identity provider"] --> R["Role directory"]
 R --> P["Permission policy"]
 A["Agent tool request"] --> E["Enforcement point"]
 P --> E
 E --> V["Read invoice"]
 E --> C["Create payment proposal"]
 E --> H["Independent approval"]
 E --> L["Access decision log"]

Runtime flow

1. 1

   Authenticate principal

   Validate the session or delegated token and establish both user and workload identity.

2. 2

   Resolve roles

   Load current approved roles without accepting role names from prompt content.

3. 3

   Map permissions

   Determine whether the requested operation belongs to the active role's allowed capability set.

4. 4

   Check constraints

   Apply separation of duties and any additional resource-specific conditions.

5. 5

   Enforce at service

   Reject unauthorized operations even if the agent or interface attempted to invoke them.

6. 6

   Audit outcome

   Record the action, principal, active role, policy version, and allow or deny result.

Separating invoice preparation from payment approval

Accounts payable · Illustrative enterprise scenario, not a reported customer outcome.

Business situation

A shared-services center uses an assistant to retrieve invoices, explain exceptions, and prepare payment proposals.

The problem

A broadly privileged integration account lets clerks accidentally request operations reserved for treasury approvers.

Agent requirement

The assistant must support each employee's work while preserving existing responsibility boundaries.

Architecture

Reader, preparer, and approver roles govern tool permissions, with an independent check preventing self-approval.

Runtime

• A clerk asks the agent to prepare a payment proposal; the gateway authorizes creation but rejects release of funds.
• An authorized approver later reviews the proposal under a distinct identity and the payment service rechecks the role.

Failure scenario

If directory synchronization fails, privileged actions deny access rather than reusing an indefinitely stale grant.

Operational impact

Track denied privileged requests, stale memberships, self-approval attempts, and time to revoke access. Role checks support the process but do not replace financial controls.

Architecture tradeoffs

Failure scenarios & recovery

Common architecture mistakes

Authorizing only at the chat interface

Enforce permissions in every backing tool service.

Accepting role claims from user text

Use authenticated directory assertions only.

Creating a role for each individual exception

Add scoped attributes or redesign responsibilities.

When to choose this pattern

Choose it when

• Job responsibilities map to stable permission bundles.
• Multiple tools need consistent action-level controls.
• Separation of duties is an explicit requirement.

Avoid it when

• Every access decision depends mainly on changing context.
• Roles cannot express resource ownership or tenant boundaries.
• A tiny public read-only service needs no differentiated access.

Architecture checklist

• Define roles from actual responsibilities.
• Enforce at every tool service.
• Separate user and workload identities.
• Test inherited effective permissions.
• Implement revocation and cache expiry.
• Audit grants and separation-of-duties violations.

Related concepts

• 11 — Tool Invocation & Function Calling
• 21 — Authorization-Aware RAG
• 23 — Attribute-Based Access Control (ABAC)
• 30 — Non-Repudiation Logs
• 34 — Tenant Isolation

Primary references

• NIST: role-based access control
• NIST SP 800-162: attribute based access control