AI Agent Identity and Delegated Permissions: Who Is the Agent Acting As?

The problem: agents borrow identities

OWASP's Top 10 for Agentic Applications (2026) lists ASI03 Identity and Privilege Abuse as one of the main risks. Its explanation is architectural: identity systems were built for people, and an agent without a distinct, governed identity of its own operates in an attribution gap where real least privilege cannot be enforced. The common patterns that cause it:

Shared or personal accounts. The agent logs in as its creator. Everyone who can talk to the agent now has that person's access (OWASP calls this identity sharing).
Static, broad API keys. One key with full rights, stored in a configuration file, used for every task.
Inherited privileges. An orchestrating agent passes all its rights to a helper agent that only needed one query.
Stale authorization. Permission is checked when a long workflow starts, but the user's rights change before the agent acts.
Cached credentials. Credentials stay in the agent's memory or session and are reused by a later, different user.

Principle 1: every agent gets its own identity

Register each agent as a non-human identity in your identity provider or access management system, with an owner, a purpose and an end date. This is what makes everything else possible: logs can say which agent acted, permissions can be limited to that agent, and access can be revoked for one agent without breaking others.

One identity per agent, not per platform. A customer-service agent and a finance agent on the same platform are two identities.
A named human owner who approves its permissions and reviews them on a schedule.
Short-lived credentials (tokens or certificates) issued at run time, not long-lived keys in configuration.
An entry in your register of AI agents with the systems and data it can reach.

Principle 2: decide whether the agent acts for itself or for a user

There are two different situations, and mixing them up is where most permission problems start:

Pattern	Example	Whose rights apply
Agent acts on its own behalf	A nightly agent that classifies incoming tickets	The agent's own, granted to its identity
Agent acts on behalf of a user	An assistant that drafts and sends email for the user who asked	At most the user's rights, narrowed further to what the task needs

For the second case, OAuth already has the right vocabulary. RFC 8693 (OAuth 2.0 Token Exchange) distinguishes impersonation, where the agent becomes indistinguishable from the user, from delegation, where the agent keeps its own identity and the token records that it acts for the user (the "act" or actor claim). Delegation is what you want for agents: the receiving system and the audit log can see both the user and the agent.

Rule of thumb. An agent acting for a user should never have more rights than that user, and usually far fewer: only the scopes the current task needs.

Principle 3: scope tokens to one task and one audience

The MCP authorization specification (version 2026-07-28) is a good model even outside MCP:

Audience binding. Clients request tokens for one specific server using resource indicators (RFC 8707), and servers must reject tokens issued for anyone else.
No passthrough. A server must not forward a token it received to another API. Each hop gets its own token, which stops one stolen token from opening every system behind it.
Minimal initial scopes. Start with low-risk read scopes. When a privileged tool is first used, the server answers with an insufficient-scope challenge and the client asks for exactly that scope (step-up authorization).

Add the controls OWASP lists for ASI03: issue short-lived, narrowly scoped tokens per task; bind permissions to subject, resource, purpose and duration; re-check authorization for each privileged step instead of once per workflow; and do not let one agent inherit another agent's rights unless the original user's intent is checked again.

Principle 4: humans approve what cannot be undone

Some actions should need a person regardless of the agent's permissions: sending data outside the company, payments, deleting records, changing access rights, and anything legally binding. Write these down as a delegation matrix: for each agent and action, whether it is allowed, allowed with approval, or not allowed. The approval itself should be specific ("pay invoice 4711 for EUR 2,300"), not a blanket "approve all".

Agent-to-agent protocols are adding the same idea. The A2A specification (version 1.0) has an auth-required task state that lets an agent ask its client for authorization, including human approval before a destructive action, and states that this state alone never counts as authorization for any operation.

Principle 5: log, review and revoke

Log each action with the agent identity, the user it acted for (if any), the scope used and the result.
Alert on new scopes, on an agent using a token outside its usual pattern, and on low-privilege agents receiving higher-privilege rights through delegation chains.
Review each agent's permissions at least quarterly with its owner, and remove what was not used.
Keep a kill switch: revoke all tokens of an agent in one step. Test it.
When an agent is retired, delete its identity and credentials the same day.

A worked example

An accounts-payable agent reads invoices from a shared mailbox, matches them against purchase orders and prepares payments.

Action	Permission	Why
Read the invoices mailbox	Allowed, read-only scope on that one mailbox	Needed for the task; no access to other mailboxes
Look up purchase orders	Allowed, read-only ERP scope	Matching needs it; no write access
Create a draft payment	Allowed	Reversible and reviewed before release
Release a payment	Not allowed for the agent; a person releases it	Irreversible; invoice emails are untrusted input that can carry injected instructions
Change supplier bank details	Not allowed	Classic fraud target; handled only through the supplier process

The agent has its own identity, a named owner in finance, tokens valid for one hour, and its actions show up in the ERP audit log as "AP agent on behalf of the AP team" rather than as a person's account.

What the regulations expect

Regulation	Requirement
NIS2	Access control policies and asset management (Art. 21(2)(i)), and multi-factor or continuous authentication where appropriate (Art. 21(2)(j)).
DORA	Limit logical access to ICT assets to what legitimate, approved functions require, with policies and controls for access rights (Art. 9(4)(c)); strong authentication mechanisms (Art. 9(4)(d)).
GDPR	Data protection by default: only the personal data necessary for each specific purpose is processed, which covers the extent of processing and accessibility (Art. 25(2)); security of processing (Art. 32).

An auditor will ask the same questions for an agent as for a person: who approved this access, is it still needed, and can you show what was done with it. An agent with its own identity, a named owner and logged, scoped tokens can answer all three.

Document it. The AI Agent Governance Pack ($49) includes a delegation and permissions matrix, a register of AI agents, a risk assessment workbook and an agent use policy. The Agent Security Bundle ($79) adds the MCP Security Audit Kit and the Vendor Security Pack.

AI Agent Identity and Delegated Permissions: Who Is the Agent Acting As?

The problem: agents borrow identities

Principle 1: every agent gets its own identity

Principle 2: decide whether the agent acts for itself or for a user

Principle 3: scope tokens to one task and one audience

Principle 4: humans approve what cannot be undone

Principle 5: log, review and revoke

A worked example

What the regulations expect

Sources

Related tools

AI Agent Risk Calculator

DPIA Helper