Least privilege for AI agents: scoping delegated authority
Definition
Least privilege for AI agents is the practice of giving each agent only the access it needs for the task in front of it, for only as long as it needs it, with the decision recorded.
It applies the oldest principle in access control to a consumer that chooses its own actions at runtime, which is why scope has to be expressed per tool and per argument rather than per account.
The principle has not changed. The consumer has. A person with too much access is a risk you can train. An agent with too much access is a risk that executes at machine speed, in a loop, without hesitation.
Why is least privilege for agents urgent now?
Agents inherited their access from the fastest path to a working demo. A personal token, a service account with admin scope, a key pasted into a config file. The permission model was rarely designed, and it is now embedded in how the agent works.
Agent identity is where identity practice lags furthest behind. A survey of 5,200 open-source MCP servers found 88% require credentials, 53% rely on long-lived static secrets, only 8.5% use OAuth, and 79% pass API keys through environment variables (State of MCP Server Security 2025, Astrix). Environment variables and config files are where least privilege goes to die, because a key that works everywhere is easier than four keys that work precisely.
The threat data explains why the scope matters more than the model. In the largest public agent red-teaming competition, 1.8 million attacks produced more than 60,000 successful policy violations across 22 frontier agents, and robustness did not track model size or capability (arXiv:2507.20526). A hijacked agent with narrow scope produces a denied call. A hijacked agent with broad scope produces an incident.
Reliability reinforces the same point. The top entry on the Berkeley function-calling leaderboard scores 77.47% overall and 68.38% on multi-turn tasks (BFCL), and on the retail benchmark Claude Opus 4.5 solves 79.6% of tasks on a single attempt and only 51.8% on all four (taubench.com). Systems that are wrong at that rate should hold reversible authority.
How exposed is your setup? Compass walks through how you scope agent access today and returns a starting risk read: compass.alyria.ai.
How is least privilege for agents different from least privilege for people?
Human access control assumes an accountable subject with a login, a job role and a manager. Workload identity assumes a deployed service with a fixed purpose. Agents are neither. They act for a person, choose actions from a menu, and their menu changes at runtime.
| Dimension | Human IAM | Workload identity | Agent least privilege |
|---|---|---|---|
| Subject | Person with a role | Service with a fixed purpose | Process acting for a task, often for a person |
| Scope expressed as | Roles and groups | Permissions on resources | Tools, arguments, data classes and destinations |
| Duration | Employment tenure | Deployment lifetime | Task or session |
| Who chooses the action | The human | The calling code | The model, at runtime |
| Change driver | Role change, joiner and leaver | New deployment | New tool, new server, new prompt, new data |
| Enforcement point | Directory and SSO | Cloud IAM and mTLS | Endpoint mediation plus policy on the call |
| Failure signature | Stale entitlement | Over-permissioned role | A plausible action nobody authorised |
In practice: Human reviews catch a wrong entitlement before it is used. Agent scope has to be right before it is used, because nobody is watching each call.
What breaks least privilege for agents?
The failures are consistent across industries, and most of them are inherited rather than chosen.
Authority borrowed from a person
The fastest way to make an agent work is to give it your token. The agent then inherits everything you can reach, including systems unrelated to the task, and every action in the audit log is attributed to you. This is the single most common finding in a first agent inventory.
Broad tool scopes
An MCP server that offers twelve tools is often approved as one unit. Writing is approved because the agent needs to write, and the scope silently includes closing issues, merging pull requests and deleting branches, because the server groups them.
Standing secrets
A key in a config file has no expiry, no audience and no attribution. It also travels: dotfiles repositories, laptop backups, pastebins, screenshots. The credential outlives the project, and the review that should have caught it happens after the incident.
Authority that composes
Two tools that are individually acceptable can combine into something that is not. Read on the customer table plus send on the mail tool is an exfiltration path, even if neither is privileged. The lethal trifecta describes the canonical version of this.
Dynamic capability sets
An agent's tool list is negotiated at runtime. A server update that adds a tool changes the agent's effective authority without a change to the agent, and without a review trigger. OWASP MCP02 calls this privilege escalation through scope creep.
In practice: the capability table is the deliverable. Every entry in it should be defensible by the team that owns the agent, not only by security.
Approval fatigue
When every action needs a human, humans approve everything. Scope design is what makes approval meaningful: a small number of high-impact actions, each with visible arguments, is a control. A queue of two hundred routine prompts is theatre.
How to implement least privilege for agents
The sequence is deliberate. You cannot narrow a scope you have not found, and you cannot revoke a secret you have not located.
1. Inventory the authority that exists
List every agent, the tools it can call, the credentials it holds and the data it can reach. Include the whisper-quiet cases: the CLI a developer installed, the local server started by an IDE, the environment variable in a shell profile.
Tip: The useful question is not "what does this agent need" but "what does this agent have". Start with the second and work backwards.
2. Replace standing secrets with short-lived leases
Broker credentials at the moment of use, scoped to the tools in play, and expire them in minutes. This bounds every other failure mode in this article, including the ones you have not found yet.
3. Express scope as capabilities, not endpoints
A capability names an action: read this repository, comment on this ticket, query this table with these columns. Capabilities are what the model chooses between, so they are the right unit for policy. Endpoint scopes leak through composition.
Tip: Write the denial case first. "This agent may not push to the default branch, may not read the secrets path and may not send mail" is usually clearer than the allow list.
4. Decide per call with the arguments visible
Policy should see the tool, the arguments and the session history. Denying write_file on the secrets path requires the path. Denying the twentieth identical call requires the history. A decision that only sees a tool name cannot express either.
5. Separate read from write, and write from irreversible
Read is usually safe to grant broadly. Write needs named targets. Irreversible actions, such as production deploys, payments, deletions and external sends, need approval or should not be automated at all.
6. Scope the agent's data, not just its tools
Treat data movement as the part of an incident you cannot undo. Define which data classes the agent may read and which may appear in its context, and enforce the boundary at the point where data enters the prompt, not only where it leaves.
7. Keep egress a decision
Named destinations, per agent, with a record of what left. An agent that can reach any host on the internet turns a small data scope into a large one.
8. Review on change and on schedule
Every new tool, server, credential and data source is a scope change and needs a decision. Add a periodic review for anything that can change state, and a retirement path for agents nobody calls.
Where least privilege applies in the agent lifecycle
Design
Scope is a design decision. Decide the capability set, the identity model and the approval boundary before the first demo, because the demo is where broad scope gets justified.
Note: Autonomy and scope are usually set together. A read-only agent can be more autonomous than a write-capable one, and treating them the same forces you into the worse of both.
Development
Tool lists belong in version control, not in a home directory. Credential acquisition belongs in a brokered call, not in an environment variable.
Pre-deployment testing
Test the denials. Confirm that the secrets path is refused, that the default branch is protected, and that a hostile tool description does not widen the set. A test suite that only exercises allowed paths proves nothing about scope.
Deployment
Issue the identity, confirm the lease path works, and verify attribution per call. If the audit record names a shared key rather than an agent, the deployment is not ready.
Runtime
The decision happens per call, with arguments and history. Denials should be visible to the agent as a clear refusal rather than a silent failure, because a silent failure invites retries that look like something else.
Note: An agent denied in the middle of a task often tries a different tool. Repeating the same denied objective through three different tools is a signal worth alerting on.
Continuous monitoring
Watch the scope drift: new tools per agent, new destinations, new credentials, and the share of calls that needed approval. Drift is usually the first observable sign of an incident.
Decommissioning
Revoke the identity, expire the leases, remove the tool registrations and keep the decision record. Orphaned authority is the cheapest thing to fix and the most commonly missed.
The takeaway: Least privilege for agents is not a smaller token. It is a written boundary per agent, enforced on the call, with an owner who can defend it.
Worked example: tightening a finance agent's scope
A payments company builds an agent to help its finance team answer vendor questions. It reads the procurement system, the accounts payable database and a shared drive of contracts, and it drafts email replies. The first version uses a service account with read access to all three and send rights on a shared mailbox.
Finding the real scope. A review finds the service account also has write access to the vendor table, inherited from a previous project, and its mailbox delegation includes the accounts receivable shared inbox. Neither was in the design. Both were in the token.
Narrowing the capability set. The agent keeps read on procurement, read on three tables in accounts payable and read on one contract folder. Drafting replaces sending: the reply is created as a draft for the finance analyst to send. That single change removes the external communication leg of the trifecta and removes the most plausible incident.
Brokering the credential. The service account is retired. Each session gets a 15-minute lease scoped to the three reads, issued against the requesting user's own entitlement. If the analyst cannot read a contract, the agent cannot either, which makes the agent's access auditable against a person.
Deciding per call. Policy checks the table, the columns and the row filter. A query that pulls bank account numbers is denied, not because the agent asked for something unreasonable, but because those columns are not in the data scope. The denial is recorded with the attempted query.
Handling composition. The agent can read contracts and draft mail, and the combination is the exfiltration path. The fix is not to remove the draft capability but to constrain it: drafts can only go to addresses in the vendor record, and attachments can only come from the contract folder the agent read.
Quarterly review. Four months later the review finds a new table added to the scope after a support request. It had been approved informally in a chat thread. The table holds payroll data. It is removed, the change path is documented, and future scope changes require a recorded decision.
The agent became more useful after the tightening, because analysts trusted it with more of the workflow. Broad scope had been a substitute for a decision, and the decision was cheaper than the incidents it prevented.
How standards and regulations influence least privilege for agents
| Framework | Primary focus | Relevance to agent scope |
|---|---|---|
| NIST AI RMF | Govern, Map, Measure, Manage | MAP asks for the AI system's context and dependencies, which is the capability set |
| ISO/IEC 42001 | AI management system with documented controls | Turns scope decisions into records a management system can audit |
| ISO/IEC 23894 | AI risk management inside enterprise risk | Connects agent scope to the access-control controls you already attest |
| EU AI Act | Obligations by risk class, including human oversight | Drives approval requirements where an agent sits in a high-risk system |
| OWASP Top 10 for Agentic Applications 2026 | ASI03 Identity and Privilege Abuse, ASI01 Goal Hijack | Names the exact failure modes that narrow scope reduces |
| OWASP LLM06:2025 | Excessive agency | Provides the three causes: functionality, permissions and autonomy |
| OWASP MCP Top 10 (beta) | MCP02 Privilege Escalation via Scope Creep, MCP01 Token Mismanagement | The tool-layer version of the same problem |
| SOC 2 | Access control and least privilege over a period | Expects evidence that access was authorised, limited and reviewed |
Further reading: Agentic AI security for the wider programme, Non-human identity and agent identity for the identity model, and Policy as code for AI agents for how the boundary gets enforced.
How Alyria handles it
Alyria enforces scope where the agent runs. Beacon, the signed daemon on every machine, inventories the agent's tools, MCP servers and credential sources, so the capability set is visible before anyone writes a policy about it.
Lyra is the policy layer. One capability-brokered, information-flow-aware policy decides which tools, MCP servers, models, data and egress each agent may touch, with the arguments in view, and it is enforced locally at the Beacon. A denial happens before the call, not in a report afterwards.
Umbra replaces the standing secret. Short-lived leases are injected at the moment of use and sealed to device hardware keys Alyria never holds, so an agent's authority expires with the task. Spectra streams signed, chained decisions to Alyria Cloud or to your own SIEM, which is what lets a reviewer answer who asked for what.
Free Agent Exposure Report: see what your agents can reach and which standing credentials they hold: alyria.ai/agent-exposure-report.
The platform overview covers how the modules fit together.
Frequently asked questions
- Is least privilege for agents just scoped API tokens?
- Scoped tokens are the starting point, not the answer. A token scope describes which endpoints an agent may reach. An agent also needs limits on which tools it may call, which arguments are acceptable, which data it may read and where results may go. Those are four different decisions and a token expresses one of them.
- Should an agent ever act as the user who started it?
- Sometimes, when the task is genuinely on that user's behalf and the action should fail if they lose access. What must not happen is an agent quietly acting as a user with broader rights than the task needs, because then every action is attributable to a person who never took it. Decide per use case and record the choice.
- How do you scope an agent whose tasks vary?
- Scope the capability, not the task. A support agent needs read access to tickets and a bounded write on a named field. If two tasks need materially different authority, that is two agents with two policies, not one agent with the union.
- What is the practical first step?
- Find every standing credential in an agent config and replace it with a short-lived lease. That single change removes the worst case for every other mistake and gives you a record of who asked for what, which you need before you can narrow anything.
- How does least privilege interact with agent reliability?
- It helps. On the retail benchmark, Claude Opus 4.5 solves 79.6% of tasks on a single attempt and 51.8% on all four. An agent that is wrong that often should not hold irreversible authority.
- Does least privilege break agents that need to explore?
- Not if read scope is generous and write scope is tight. Exploration is mostly reading. The failures people fear come from revoking read access the agent needs to be useful, not from refusing unattended writes.
- How often should agent permissions be reviewed?
- On every change to the agent, its tools or its credentials, plus a scheduled review for anything that can change state. Reviews that only happen annually will miss a tool list that changed three times in between.