Disclosure: BlueBear builds a gateway that scopes agent credentials, so we have a commercial interest. Most of what follows is architecture rather than product, and the article says where nothing needs buying.
The short answer: narrow the permission, not the prompt
Least privilege means an agent holds only the permissions its job requires, for only as long as it requires them. For AI agents there is a second clause that matters as much: the credential is supplied at the execution boundary rather than held by the agent.
The reason this is more urgent for agents than for ordinary software is that an agent chooses its own steps. Ordinary software does what it was written to do, so what its credential permits and what it actually does are close together. An agent's behaviour is decided at run time from text that can include content someone else wrote — so the only reliable bound on what it does is what it can do.
The progression
| Stage | What the agent holds | Reach when something goes wrong |
|---|---|---|
| Broad key | The application's credential | Everything the application can do |
| Own credential | A key issued to the agent | Everything that key permits — usually still a whole system |
| Scoped connection | A reference to a described connection | One system, all operations |
| Named operations | Permission to invoke specific operations | Those operations only |
| Boundary-held credential | Nothing. It asks; the boundary executes. | Those operations, and the secret never leaves |
Most systems sit at stage one. Getting to stage two is the largest single risk reduction available and is covered in what AI agent identity is. Stages three to five are this article.
Why "it only ever calls three endpoints" is never accepted
This is the sentence that fails reviews, and it is worth understanding why rather than resenting it.
A reviewer is assessing what could happen, not what usually happens. A credential that reaches an entire system means any bug, confusion, or successfully manipulated instruction reaches the entire system. Since instructions can arrive inside data an agent reads — a document, a ticket, an email — and no filtering approach reliably eliminates that, the design assumption has to be that manipulation will sometimes work.
Given that assumption, the only variable you control is the consequence. Narrowing the credential is the sole change that reduces the assessed risk. Behavioural arguments do not, because behaviour is exactly what is in question.
Named operations: what makes scoping tractable
"Give the agent access to the CRM" is not a permission, it is a description of a risk. The useful unit is the operation: this agent may look up an order by identifier and update a shipping address, and may do nothing else.
The Model Context Protocol — an open standard for describing a connection to a tool or data source and the named operations inside it — is what makes this practical at scale, because it turns an integration into an enumerated list that a policy can be written against rather than a credential with implied reach. Designing a governed integration catalogue covers running many of these, and MCP token security covers why the token must not pass through to the agent.
The verification is literal: ask for the list. If nobody can produce an enumerated list of the operations an agent may invoke, the scoping does not exist, whatever the design document says.
What a reviewable permission model looks like
Four properties, and the last two are the ones that separate a real model from a good intention.
Named, enumerable permissions. A fixed catalogue of scope names, not free-form strings. Ours is a registry of named scopes covering the resources the platform exposes, with reads and management as distinct permissions rather than one access level.
A risk tier on each. Reads sit at a lower tier than management and execution, so a review can concentrate on the high-tier grants rather than reading everything. The detail worth copying is what happens to an unrecognised permission: ours is treated as high risk rather than as unknown-and-therefore-fine. Fail-safe defaults cost nothing and reveal the design philosophy.
Granted versus effective scopes as separate concepts. One permission frequently implies another, and that is where quiet over-granting lives. If you can only see what was granted, you cannot see what was conferred. Both should be inspectable, and in our gateway any authenticated caller can ask what it is authenticated as and receive both its granted scopes and its effective scopes, with per-permission detail — which means an agent's real reach can be audited from outside rather than inferred from configuration.
Expiry. Access that never expires is access nobody removes. Ours defaults to an expiry rather than to perpetuity, which converts revocation from a task somebody must remember into a renewal somebody must justify.
The escalation paths worth closing
Two specific ones, because they turn a contained problem into an uncontained one.
A credential that can create credentials. If an agent's key can mint keys, its effective reach is unbounded regardless of its nominal scope. The clean rule is that minting requires a human session. Ours refuses key management from an API key entirely, returning a specific error rather than a generic denial — the design intent being that a machine credential structurally cannot be an escalation path.
A credential that can act across boundaries. The worst failure in a multi-customer system. Ours refuses cross-boundary minting unless a human platform administrator is behind the session, and records an explicit cross-boundary flag on the audit event when it happens. Multi-tenant isolation for buyers covers what to verify.
Where authorisation must be evaluated
At the execution boundary — the point where the call leaves your system — and nowhere else as the sole control.
Authorisation stated in a system prompt is a request to the agent, not a control over it, and it has a second defect beyond being argueable: it produces no record. Nothing evaluated anything, so there is nothing to write down. A decision made at the boundary produces both the enforcement and the evidence, which is why this single architectural choice shows up in the security article, the audit article and this one. How to make AI actions auditable covers the recording side.
Doing the access audit
The exercise is short and the finding is usually the same.
- For each agent, list what its credential can reach. Not what it uses — what it can reach.
- Separately, list what its job actually requires.
- The gap is the finding. It is almost always large, and it is almost always news to somebody.
- For the top two or three agents by consequence, close the gap. Ignore the rest for now.
Step 1 is the one people skip, because it requires asking what a credential permits rather than what a service does, and those questions usually go to different people.
If you operate in a regulated industry
The high-tier grants are what a review will concentrate on, so a permission model with risk tiers is worth having for the review process alone, independent of its security value. Pair it with an expiry policy, because an access list nobody has re-approved in two years is a finding on its own. Security posture evidence for buyers covers the artefacts to have ready.
If you are a platform or engineering lead
Move the credential to the boundary before you refine the scopes. Once the agent no longer holds the secret, narrowing is a configuration change you can iterate on; while it holds the secret, every narrowing is a deploy and the work stops after the first one. Data integrity at enterprise integration points covers the surrounding controls.
If you resell this to customers
Scopes have to be per customer as well as per agent, and the operation that proves it is revoking one customer's integration without touching anyone else's. White-label brand workspaces explained covers the structure.
Do this next
Do steps 1 and 2 of the access audit for your single most consequential agent. Two lists, half an hour, and the gap between them is the most concrete security finding available to you this week. Then read what AI agent identity is if the agent is still using the application's credential, or the security evaluation checklist if part of the answer is a vendor.
Questions people actually search for
- least privilege for ai agents
An agent holds only the permissions its job requires, for only as long as it requires them, and the credential is supplied at the execution boundary rather than held by the agent. In practice that means named operations on named connections rather than a database password or a broad API key. The test is not how the permissions are described but whether revoking one capability is a configuration change or a redeploy.
- ai agent access audit
Start by listing, for each agent, what its credential can actually reach - not what it is supposed to use. Those two lists are almost never the same, and the gap is the finding. Then check three things: whether permissions are expressible per operation or only per system, whether granting one confers others implicitly, and whether anything expires. Most access audits in this area end with a single recommendation, which is to replace a shared credential with a scoped one.
- ai agent authorization
Authorisation for an agent has to be evaluated at the execution boundary - the point where the call leaves your system - rather than expressed in the prompt. An agent constructs its own steps from text, so a rule in text can be argued with; a rule evaluated at the boundary holds regardless of what the agent was persuaded to attempt. That is also the only arrangement that produces a record, because something had to make a decision in order to record one.
- why do broad api keys fail a security review
Because the reviewer is assessing what could happen, not what usually happens. A credential that reaches an entire system means any confusion, bug or successful manipulation reaches the entire system - so the risk assessment has to assume the whole surface regardless of how the agent normally behaves. Narrowing the credential is the only change that reduces the assessed risk, which is why "the agent only ever calls three endpoints" is never an accepted answer.
- how do you scope an ai agent permissions
Work from the job rather than the system. List the operations the agent actually needs, express those as named permissions on a described connection, supply the credential at the boundary rather than to the agent, and attach an expiry. Then check the implied permissions, because a permission model where granting one confers others quietly re-widens what you just narrowed - which is why granted scopes and effective scopes should be separate concepts you can both inspect.