Most AI agents in production run with far more access than their job needs. Nobody chose that. The fastest way to get a pilot working was an existing login. Nobody went back. Least privilege for agents is the work of going back.
What it means for an agent
For a person, least privilege means your role's access and nothing more. For an agent, the idea is the same. The unit is smaller. An agent's job is a short list of actions. Each action should be allowed on only the records it needs.
OWASP names the failure "excessive agency" and ranks it sixth among risks for LLM applications. It splits the cause three ways: excessive functionality, excessive permissions, and excessive autonomy1. That split makes a useful checklist.
- Functionality: tools the agent doesn't need. OWASP's example is an agent that only has to read documents, given a plugin that can also modify and delete them1.
- Permissions: tools with more rights than the job needs. A read-only report tool on a login that can also update and delete.
- Autonomy: high-impact actions with no one approving them. See autonomy levels for where the hold belongs.
Scope by action
"The agent has access to NetSuite" tells you almost nothing. NetSuite can pay suppliers, change bank details, post journals, close periods and create users. Write the scope in actions.
An illustrative scope for an invoice matching agent:
| Can | Can't |
|---|---|
| Read open POs, receipts and supplier records | Read payroll, employee records or other entities |
| Create a draft bill against a matched PO | Approve or release a bill for payment |
| Attach the invoice PDF to the draft bill | Edit or delete an existing bill |
| Add a note explaining a variance | Change supplier bank details or payment terms |
| Send a hold to the AP lead | Email suppliers directly |
Illustrative. Your list comes from the process you're automating.
The right-hand column matters as much as the left. Every line in it is a decision someone made. Write it down. That's how you find the ones nobody made.
Give every agent its own identity
The most common shortcut is the worst one. The agent runs as the person who set it up. Or on a shared service account with admin rights.
That breaks three things at once. You can't limit the agent without limiting the person. Your system's own audit log can't tell you who made a change, the person or the agent. And when that person leaves, the agent breaks. Or an ex-employee's login stays active.
Give each agent its own identity in each system it touches. Its own credentials. Its own rights. This is ordinary separation of duties. NIST's control for it, AC-5, says the aim is to reduce "the risk of malevolent activity without collusion"2. An agent that can both prepare and release a payment is colluding with itself.
Guard those credentials like production ones. Ask any vendor where they're stored (our vendor questions include this). Anthropic's September threat report describes attackers harvesting exposed keys and tokens at scale, including from AI agents their victims had deployed. It tells organisations to treat "AI keys and agent integrations with the same level of seriousness as they do production credentials"3.
Keep secrets out of the agent's reach
Everything in the agent's working environment is within its reach. Config files. Shared drives. Tickets with pasted tokens. A browser with someone's session still open.
That matters more than it used to. OpenAI's disclosure about its own agents lists "use of exposed credentials" as one of the behaviours it found: agents that "found login details or access keys that had been made publicly available and used them"4. Nobody told those agents to. They were trying to finish a task.
The fix is plain. The agent's environment holds its own scoped credentials and nothing else. If an admin key exists anywhere it can read, assume it will be used one day.
Enforce it in two places
Scope works when it's enforced where the model can't reach. OWASP's advice is direct: "Implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not"1. Two layers do that.
- /01
In the system of record. The agent's own identity in NetSuite, Epic or your claims platform has only the rights in the left-hand column. It tries to change bank details. The ERP refuses.
- /02
Before each action. A check outside the model compares each proposed action against the scope. Anything outside it is refused. This covers what system permissions can't express well: "only for invoices under this amount", "only for suppliers older than 90 days", "only one email per supplier per day".
The first layer is blunt and hard to bypass. The second is precise. You want both. The prompt is neither. "Never change bank details" in a prompt is advice to the model.
How to review an agent you already run
- /01
Export the agent's actual rights from every system it logs into. Not what the design doc says. What the system says.
- /02
Pull 30 days of what it actually did. Compare. Every right it never used is a candidate to remove.
- /03
Look for four things first. Anything that can send email or messages outside the company. Delete records. Change payment details. Manage users. Those rights turn a bad day into an incident.
- /04
Check whose identity it runs as. A person or a shared admin account? That's the first fix.
- /05
Search its environment for secrets it shouldn't have. Tokens in files. Keys in environment variables for systems it doesn't use.
Fix the four from step 3 first. The rest can wait a week.
Where Gatehouse fits
Gatehouse is the second layer. Scope sits in a signed rules file. Changing it leaves a trace and takes a named person. Each action is checked before it runs. Anything outside scope is refused. The refusal is saved in the record with the rule that caught it. Already running an agent and want to scope it without a rebuild? See govern the agent you already run.
Start here
Pick the agent with the most access. Write its job as a list of actions. Then write the "can't" column. Hand both to whoever owns the system it logs into. Ask them to match the agent's real rights to the list. The gap between the two is your risk. Want help closing it? book a teardown.
Sources
- [1]OWASP GenAI Security Project, LLM06:2025 Excessive Agencygenai.owasp.org In text
- [2]NIST SP 800-53 Rev. 5, AC-5 Separation of Dutiescsf.tools In text
- [3]Anthropic, Countering misuse of AI: September 2026anthropic.com In text
- [4]OpenAI, The Hugging Face incident and other third-party impact from misaligned modelsopenai.com In text
Read next
What is an agent approval policy?
An approval policy decides which agent actions go ahead, which wait for a person, and which never happen. Most teams have a paragraph. You need a table.
Prompt injection in accounts payable: what an invoice can tell your agent to do
An invoice is text a stranger wrote, and your agent reads all of it. Prompt injection turns that text into instructions. You can't filter it out. You can limit what it can do.
What should you ask an AI vendor before signing?
Twelve questions that separate a system you can run from a demo you can't control. Ask us first.
