Least privilege for AI agents: scoping what an agent can reach

How agents end up over-privileged

Nobody decides to give an agent admin rights. It happens by inheritance. An engineer prototypes with their own credentials because that is what works, the prototype becomes the deployment, and the credential is never narrowed because narrowing it risks breaking something that currently works.

The second path is defensive over-provisioning. An agent fails intermittently because a permission is missing in an edge case, the fastest fix is to widen the grant, and nobody returns to tighten it once the incident is closed.

Scope by capability, not by network

Network-level controls answer "can this process reach that host". That is the wrong granularity for an agent, because an agent that legitimately needs to read one table gets reachability to the entire database, and the control has no opinion about which rows or which operation.

Useful agent scoping is expressed in the vocabulary of the action: which datasets, which fields, which operations, which tools, with which parameters. "May read customer contact fields, may not read payment fields, may not write" is enforceable and reviewable. "Has database access" is neither.

Deriving scope instead of guessing it

The reason least privilege stalls is that nobody knows what the agent actually needs, and guessing produces either breakage or uselessly wide grants. The way out is to observe first: run the agent in a mode that records every data access and tool call without blocking any of them, then derive the scope from what it genuinely used over a representative period.

This turns a design argument into a measurement. It also surfaces the interesting cases directly, because an access that appears once in a month of traffic is either an important edge case or something the agent should never have been doing.

The intersection rule

Scoping the agent alone is not sufficient. An agent scoped to read all customer records, invoked by a user entitled to see only their own region, must not return the whole set. If it does, the agent has become a privilege-escalation path, and a convenient one, because the request looks legitimate in every log.

The rule is that effective permission is the intersection of the agent scope and the requesting principal scope. Neither can widen the other. This is why agent identity and human identity have to travel together through the call, rather than the agent authenticating alone.

Sequencing that survives contact with production

Least privilege fails when it is introduced as a big-bang enforcement change. A safer order:

• Record what each agent accesses, blocking nothing.
• Derive a candidate scope from observed use over a full business cycle.
• Run the candidate scope in report-only mode and count what would have been denied.
• Review the would-be denials with the agent owner; they are either bugs or missing scope.
• Enforce once the denial count is stable and understood.
• Re-derive periodically, because agent behaviour drifts as prompts and models change.