AI agent access control: scoping reach, credentials, and action class

Access control for software systems is a solved problem — in principle. Define subjects (users, services), objects (resources), and the operations each subject may perform on each object. Enforce it at a single choke point. Log everything.

Access control for AI agents involves all of that and a problem those frameworks were not designed for: the subject is non-deterministic. It decides at runtime what to do next, based on context that was not known when the policy was written. Standard RBAC assumes predictable subjects. Agents are not that.

This post maps the three mechanisms that compose into a working access model for AI agents: role-based tool scoping, per-worker credential routing, and action-class gating.

Mechanism 1: Role-based tool scoping

The first line of access control is visibility. If an agent cannot see a tool, it cannot call it — regardless of what the model decides in context. Role-based scoping assigns each agent role a filtered catalog of tools, hiding anything outside that role's remit.

A Sales Agent sees CRM read/write tools and calendar tools. It does not see production database tools, even if those tools exist on the same platform. A DevOps Agent sees CI/CD and infrastructure tools. It does not see customer billing.

This is different from building a separate agent per use case. Roles let you share a single agent framework and permission it differently for each deployment context. When a new tool is added to the platform, it is invisible to all roles until explicitly granted — opt-in by default, not opt-out.

Mechanism 2: Per-worker credential routing

Access control without identity routing answers the wrong question. "May a Sales Agent read HubSpot?" is not specific enough. The useful question is: "May this sales agent, running in the context of this client, read this HubSpot portal — and write its output only to the correct place?"

Per-worker credential routing maps agent invocations to specific connections: account A's Google Ads, workspace B's Slack, repository C's GitHub. The mapping is policy, not prompt. It does not depend on the agent remembering which account to use; the platform resolves it before the tool call reaches the external API.

This is especially important in multi-tenant deployments. An agency running AI workers for twenty clients cannot share credentials across clients and call it access control. Per-client identity routing enforces isolation at the platform level, not the agent level.

Mechanism 3: Action-class gating

Not all actions carry the same risk. Reads are generally reversible; large writes and mutations often are not. Action-class gating classifies tool calls by their risk profile and applies different enforcement policies to each class.

• Free reads: execute immediately, logged but not gated.
• Standard writes: execute immediately with a full audit record.
• Sensitive mutations: queued for human review before execution.
• Irreversible actions: blocked or require multi-factor approval.

The boundary between classes is defined by policy, not by the agent. A sales agent might be allowed to create a draft deal without approval but require a human to approve the pipeline stage move. An ads agent might read and report freely but gate any budget change above a threshold.

Approval gates do not have to block the entire agent. Async gating queues the sensitive action, continues the rest of the agent's work, and executes the action when approval arrives — or cancels it if the context has changed.

How the three mechanisms compose

In isolation, each mechanism is incomplete. Scoping without routing still exposes the wrong accounts. Routing without scoping still exposes the wrong tools. Neither without gating lets you deploy agents against production systems without unlimited trust.

Together, they form a complete access model:

1. The role determines which tools the agent can see (scoping).
2. The context determines which specific accounts and credentials each call uses (routing).
3. The action class determines whether the call executes immediately or waits for approval (gating).

Each check is independent and enforced at the platform layer, not in the agent's code. This means the access model survives prompt changes, model upgrades, and new tool additions without a full audit of the agent's instructions.

What this means for least privilege with agents

Least privilege — the principle that a subject should have access only to what it needs to do its job — translates naturally to agents:

• The role catalog should be the minimum set of tools the agent's function actually requires.
• Credential routing should resolve to the narrowest account scope that completes the task.
• The gating threshold should match the organization's risk tolerance for that agent type, not a blanket policy.

Least privilege is harder to achieve without an access control layer because there is no single place to inspect or adjust the policy. With one, the scope of any agent role is readable, auditable, and changeable in one place — without touching the agent's code.

FAQ

How is this different from just using scoped API keys?

Scoped API keys solve part of the credential problem — narrowing what a single credential can do. They do not solve tool visibility (the agent can still discover and attempt to call anything its framework exposes), identity routing (a single key is still shared across all invocations of an agent unless you provision one per agent instance), or action gating (there is no mechanism to pause and route a call for human review before it executes).

Can access control be defined per agent instance rather than per role?

Yes, and sometimes that granularity is necessary — particularly in systems where each agent instance corresponds to a specific customer or use case. Roles are a convenience layer that lets you define policy once and apply it to many instances. Instance-level overrides on top of role defaults handle the cases where finer granularity is needed.

How does access control interact with multi-agent systems?

In multi-agent systems, a sub-agent's access should be no broader than the scope it needs for its subtask — regardless of the orchestrating agent's access. The governance platform should enforce the sub-agent's role independently, not inherit the orchestrator's permissions. Otherwise, decomposing a task into sub-agents becomes a way to escalate privilege, which is the opposite of what you want.