Least privilege for AI agents: permissions, accounts and credentials

Picture an AI agent sorting receipts for a tax practice. It needs one folder, yet under a partner's account it can reach every client file, every mailbox, perhaps the banking portal. Our position: the most effective security measure for agents is unglamorous. A dedicated account, minimal rights and short-lived credentials limit the damage regardless of why the agent goes wrong. The 2026 edition of the OWASP Top 10 for LLM Applications ranks excessive agency third and defines it independently of what causes the malfunction. This piece covers two of its three root causes, excessive functionality and permissions; the third, autonomy, is covered in our article on human approval.

Why personal accounts are the root problem

The principle of least privilege is old: grant only what the task requires. NIST builds it into its zero trust architecture (SP 800-207): access is granted per session with the least privileges needed, and authenticating to one resource does not automatically open another. An agent on a personal account breaks this three ways.

• Too much access: the agent inherits everything the person may do. OWASP describes a related pattern: a tool for one user's documents connecting through a privileged account that reaches every user's files.
• No attribution: the log cannot show whether the partner or the agent deleted a file.
• No targeted revocation: cutting off the agent means locking out the person too.

Dedicated accounts and an allowlist of tools

Major platforms now give agents identities of their own. Microsoft Entra Agent ID, generally available as of October 2026, assigns each agent identity an accountable "sponsor" and recommends one identity per agent, so one can be disabled without affecting the rest. Google Cloud offers per-agent identities instead of shared service accounts on its agent platform, and AWS AgentCore likewise gives agents identities of their own.

For a law firm, clinic or small business, that means one clearly named account per agent, such as "agent-receipts", with a named owner. Add an allowlist of tools. OWASP advises offering only the tools the task needs and avoiding open-ended ones such as shell access or arbitrary URL fetching.

Rights by task, with reading and writing kept apart

Full access plus limits written into the system prompt is convenient. OWASP rejects it: authorisation must be enforced deterministically outside the model, in the tool, a pre-execution check or the downstream system. Its example: an assistant that summarises emails needs only read access; if its tool can also send, one crafted email can make it search the inbox and forward what it finds. Illustrative examples of tight scoping:

OWASP also advises splitting workflows that need different rights, such as reading sensitive data and sending externally, by authorisation context, each part with only the rights it needs.

Credentials: out of the prompt, short-lived, revocable

OWASP now advises assuming that anything in a model's hidden context can be discovered. Passwords, API keys and tokens therefore do not belong in the context window but in systems the model cannot access directly. Our article on prompt injection explains how attackers steer models through content. The answer is secrets management: credentials sit in a vault and the executing component fetches them when needed. AWS describes such a token vault for AgentCore, and Microsoft recommends certificates or managed identities over client secrets in production.

Short-lived, so that stolen credentials soon expire. The OWASP Secrets Management Cheat Sheet recommends expiry dates, regular rotation and, where possible, dynamically generated secrets. Google binds agent identities' access tokens cryptographically to the agent's certificate and allows no long-lived keys for them.

Revocable means knowing which credentials an agent holds and cutting off precisely those. In February 2026 the Cline project, rotating credentials after a public vulnerability disclosure, deleted the wrong npm token. The exposed one stayed active and enabled an unauthorised release, available for about eight hours. More cases are in our collection of documented incidents.

Stopping privilege creep

Permissions grow quietly: OWASP cites a trialled tool, since replaced, left available to the agent, and Google notes that a deleted agent's IAM bindings stay in the policies as inactive grants until someone removes them. A simple routine helps:

1. Inventory: every agent with its account, tools, rights and owner.
2. Regular review: Microsoft recommends that sponsors confirm every six to twelve months that each agent is still needed. When the task changes, review at once.
3. Decommissioning: disable the account, remove permissions, revoke credentials and check the revocation against the credential itself.

For organisations within the scope of Austria's NISG 2026, this is an obligation: since 1 October 2026, § 32(4)(i) requires, among other things, policies on access control. Our article on NIS2 and AI agents covers the wider framework.

Minimal rights need a boundary outside the model

In AEGIS, the locally operated agent system from oQueo, the language model holds no credentials and has no access to tools; it can only propose actions. A separate checking authority admits only tools on the allowlist, caps each agent at a maximum action level and allows web access only to approved domains. Anything not explicitly permitted is refused (default deny). You decide the rights, and an allowlist drawn too generously stays too generous. More on our security page.