Enforcement
What does least privilege mean for an AI agent?
For a person, least privilege means holding only the permissions their job requires. For an AI agent it has to be drawn more tightly, because an agent inherits the entire reach of every tool it is connected to whether or not its task needs it. The boundary therefore has to be set per operation rather than per system: an agent authorized to read invoices cannot approve them, even though both operations sit behind the same connection.
Why user least privilege does not transfer
The principle is the same and the unit is different, which is where most implementations go wrong.
A person granted access to the finance system does not thereby perform every operation it supports. Their role, their training, their manager, and the fact that they would have to decide to do it all constrain what actually happens. Access is the outer boundary; behaviour sits well inside it, held there by things that are not technical controls.
None of that applies to an agent. An agent connected to a finance MCP server can call every operation that server exposes, immediately, with no intermediate judgement — and it will, if the reasoning that produced the call concluded that it should. There is no gap between access and behaviour for organisational friction to fill. Whatever is reachable is, in practice, permitted.
So a permission model that grants access per system leaves an agent holding far more authority than anyone intended. The grant that gives it invoice reads also gives it invoice approvals, vendor edits, and payment releases, because those are operations on the same server.
The unit of scoping is the operation
Least privilege for agents means enumerating operations and deciding on each one, which is only feasible if the enumeration is automatic.
A single enterprise MCP server commonly exposes dozens of operations. An agent with three or four integrations can easily reach over a hundred. Nobody is going to review that by hand per agent, and the ones that matter are not obvious from the names — the difference between an operation that reads a payment record and one that releases it may be a single verb.
This is what SCOPE-MCP does at design time. It enumerates the complete action surface across everything the agent is bound to, and classifies each operation against Segregation of Duties rules and regulatory regimes, so the review is a decision about a labelled list rather than an investigation. The result is a scope: the specific set of operations this agent is authorized to perform, written down before it ships.
Three kinds of excess to remove
OWASP's LLM06:2025 Excessive Agency entry traces agent risk to three causes, and they map cleanly onto three separate scoping decisions.
- Excessive functionality. The agent is connected to tools it does not need for its task. Removed by pruning the bindings — the cheapest and most-skipped step, because integrations get added during development and never audited afterwards.
- Excessive permissions. The agent can call operations beyond its task on tools it legitimately needs. Removed by scoping per operation, which is the case that server-level access control cannot express at all.
- Excessive autonomy. The agent can complete high-impact actions with no human involvement. Removed not by denying the operation but by requiring approval on it — the escalate path rather than the block path.
The three are independent. An agent can be minimally connected and still hold excessive permissions on what remains, and it can be correctly permissioned and still have too much autonomy over the consequential end of its scope.
What enforcement looks like in practice
A scope that is not enforced at runtime is a document, so the design-time work only pays off if something checks against it on every call.
Arbiter evaluates each action against the agent's mapped scope after the agent reasons and before the tool call executes. An operation outside the scope is not a violation logged for review — it is a call that does not execute. That distinction is the whole point: least privilege enforced after the fact is a report about a breach, not a permission model.
Concretely, for an accounts payable agent scoped to read invoices and create payment proposals but not approve them:
- Reading an invoice clears, with the decision recorded.
- Creating a payment proposal clears.
- Approving a payment is blocked as outside scope — and blocked again, separately, as a Segregation of Duties violation if the agent raised the invoice itself.
- A proposal above the configured value is not outside scope, so it is held and routed to the named approver rather than refused.
Common questions
How is this different from role-based access control for agents?
RBAC assigns a role and grants that role access to systems, which is the right granularity for people and the wrong one for agents. The gap is that a role is a durable identity while an agent's legitimate authority is contextual: the same agent may reasonably create a payment proposal and never reasonably approve one, and RBAC has no way to express that beyond splitting it into two roles and hoping the binding is right. Scoping per operation captures it directly, and adding Segregation of Duties makes the check dependent on history as well — whether this agent raised the thing it is now approving is not a question any role assignment answers.
Does scoping an agent tightly stop it from doing useful work?
It removes reach the agent was not using, which is a different thing. In practice the action surface an agent actually exercises is a small fraction of what its integrations expose, so the operations removed by scoping are mostly ones it would never have called — until a confused reasoning step or a successful prompt injection caused it to. Where scoping does constrain real work, the escalate path is usually the right answer rather than a block: the agent keeps the capability, and consequential uses of it route to a named human first.
What happens when an agent needs a new permission?
It goes through the same mapping step that produced the original scope. Extending an agent's reach means new operations become available to it, and those are enumerated and classified the same way the originals were, which either widens the approved scope deliberately or flags that the change puts the agent outside it. The important property is that this is triggered by the binding rather than by someone remembering to file a review — attaching a new MCP server three weeks after deployment changes the action surface, and a scope derived from live bindings notices while a spreadsheet written at launch does not.
Can least privilege be enforced on agents you did not build?
Yes. The scope is derived from what the agent can reach rather than from its source code, so a vendor-supplied or third-party agent is enumerated the same way an in-house one is — by looking at the tools it is bound to and the operations those expose. Enforcement attaches at the same points, meaning the agent does not have to cooperate or even be aware of it. This matters for coding assistants and packaged agents in particular, where you control the integrations and the systems of record but not the agent's internals.
How does least privilege relate to Segregation of Duties?
They constrain different things and you need both. Least privilege is a statement about capability: which operations this agent may ever perform. Segregation of Duties is a statement about combination: which operations may not be performed by the same actor on the same object, regardless of whether each is individually permitted. An agent can be perfectly scoped under least privilege and still violate SoD, because creating a purchase order and approving one may both be legitimately within its permissions while doing both to the same order is not.
See every operation your agents can currently reach.
LangGuard maps your complete agent action surface in minutes. Free for the first five managed agents, with every Scope included from day one.