AI agent permissions (least privilege)

What it is

Least privilege is an old security principle. NIST's glossary defines it as restricting the access privileges of users, or processes acting on their behalf, to the minimum necessary to do their work. An AI agent is exactly such a process. Agent permissions apply the principle per agent: this key may read tickets and create them in one PSA; that key may only read invoices.

Why it matters

A model can be wrong, and it can be manipulated through prompt injection. Permissions decide how much damage either can do. The OWASP Top 10 for LLM applications lists excessive permissions as a root cause of excessive agency, and recommends limiting what extensions may do in other systems to the minimum necessary. OWASP's agent cheat sheet adds two rules: scope permissions per tool (read-only versus write, specific resources), and fail closed for unknown tools.

How it works

1. One credential per agent, so each can be limited and revoked on its own.
2. A scope listing what the credential may run: whole services, single actions, or classes such as read-only.
3. Enforcement where the call executes, not in the model's instructions. OWASP's prompt-injection cheat sheet warns against treating prompt wording as an enforcement boundary.
4. Narrowing only. A credential that creates another can grant at most what it holds.
5. Revocation that stops the agent at once.

Example

A ticket-triage agent gets a key that allows read:* plus service.ticket.create on the PSA. It can read every connected system and open tickets. It cannot close tickets, edit invoices or delete anything, whatever its prompt says.

Common pitfalls

• One shared admin token for every agent: no least privilege and no way to tell agents apart.
• Vendor scopes that are too coarse. Many OAuth scopes grant read and write together; the limit has to be applied above them.
• Rules written into the system prompt instead of checked by the server.
• Forgetting administration. An agent that can create connections or keys can widen its own reach.

How actionlake handles it

Every actionlake key carries allowed_actions. An entry may name one action, a canonical verb such as service.ticket.create, a whole service (xero.*), an effect class (read:*), an effect class on one service, or everything (*). An empty list allows nothing. The check runs before any cost is incurred. A key can mint keys only within its own scope, and revoking a key revokes every key it minted. Changing connections, credentials or keys needs a separate account:* grant that * does not include, and deciding approvals needs approve:*. Pair scopes with caps and approval rules. Details are on the trust page.