AI agent permissions: seven lines for one agent
Identity, credential life, reads, tools, limits, approval and stop. Each one a decision someone signs.
An agent nobody scoped
A hypothetical example. An AI agent chases unpaid invoices. It can also change payment records. Then one email from outside asks it to swap a supplier's bank details. Nothing in its setup says no.
Ask who approved its access. Usually someone who clicked Allow in a pilot. That is a default. Not a decision.
Purpose says what an agent is for. Not what it may do.
The OWASP Top 10 for agentic applications calls the principle least agency. Autonomy is earned. It is not granted by default.
The seven lines
- Identity. The agent gets its own identity. Not a person's account and not a shared service account. Otherwise every action looks like someone else's.
- Credential life. How long its token lasts and who can revoke it mid-task. Hours rather than months. Never a token that does not expire.
- Reads. Name every source it reads. Mark the ones written outside your organisation. That is where a hidden instruction can come from.
- Tools and actions. An allow list of named tools. For each one say read or write. Anything not on the list is not permitted.
- Limits. Maximum value, maximum volume, maximum rate. Limits turn a bad hour into a small incident.
- Approval. Which actions need a person first. Start with anything irreversible, anything that leaves the organisation, and anything that moves money.
- Stop. Who can stop it and how fast. What happens to work in progress. And when that stop was last tested.
Every action is logged under the agent's own identity. That is how you explain afterwards what it did and why.
Worked example: the invoice agent
Hypothetical.
- Identity — its own agent identity, owned by the head of accounts receivable
- Credential life — a token that lasts eight hours; finance or security can revoke it
- Reads — the shared mailbox (outside content: anyone can write to it) and the invoice ledger
- Tools and actions — ledger: read; reminders: send; payee records: no access at all
- Limits — twenty reminders an hour, only to customers already in the ledger
- Approval — a person approves any message that departs from the standard reminder
- Stop — the accounts receivable lead, within five minutes; queued messages are held; tested last month
Run that email again. The agent cannot touch payee records. The request goes nowhere. Nobody had to spot it.
The worst-case test
Write the worst thing the agent could do before a person intervenes. One sentence. For the invoice agent it is twenty wrong reminders in an hour. Small. Visible. Easy to put right.
If you cannot write that sentence, the set is not finished. A worst case nobody can state is the finding.
Fix these first
- An agent that runs as a person. It inherits everything that person can do, including things nobody meant to give it.
- A token that never expires.
- A deny list instead of an allow list. Everything not forbidden is permitted. The list never keeps up.
What I would do on Monday
- Pick one agent that is already live. Not one still in design.
- Write the seven lines with its owner in the room.
- Fix anything that runs as a person or holds a token that never expires first.
- Get two signatures: the owner and security. A permission set nobody signed is still a default.
What this page is not
It is not an OWASP template. The seven lines are a working set built on the OWASP guidance, not a format OWASP publishes.
Sources
- OWASP GenAI Security Project, OWASP Top 10 for Agentic Applications 2026 — ASI02 Tool misuse and exploitation; ASI03 Identity and privilege abuse; the principle of least agency. genai.owasp.org
The invoice agent is hypothetical.
The same material, narrated: Day 30 of The First 90 Days on the CompoundTrust channel. Start with Day 1, the AI inventory, if you have not got one yet.