AI Agent Identity and Authorization: Credentials, Delegation and Least Privilege

When an agent calls an API, whose authority is it using? In many early deployments the answer is "a shared service account with broad access," which means every user, and every attacker who can influence the agent, effectively has that account's power. This article explains how to give agents proper identities and how to keep their permissions narrow.

The core problem: the confused deputy

A confused deputy is a privileged component tricked into using its authority for someone who should not have it. An agent is a natural deputy: it holds tools and credentials, and it takes instructions from text, some of which may come from untrusted sources. If the agent's credentials are broader than the user's, a user (or an injected instruction) can obtain access they were never granted.

The fix is to ensure the agent can do no more than the person it is acting for, and no more than the task requires.

Two identity models

1. Agent acts as the user (delegation)

The agent calls downstream services with the user's own authority, limited to what the task needs. Downstream systems see the user's identity and enforce the user's existing permissions. This is the right default for assistants working on a person's data.

2. Agent acts as itself (workload identity)

For autonomous or background agents, give the agent its own identity, such as a dedicated IAM role or service principal, with permissions scoped to its job. Each agent has a separate identity so access can be audited and revoked individually.

Avoid the third, worst option: one shared admin credential for all agents and users.

Delegation with scoped, short-lived tokens

For the delegation model, use OAuth patterns rather than passing the user's password or a long-lived key:

• The user authorizes the application, granting specific scopes (for example calendar.read but not calendar.write).
• The agent receives short-lived access tokens and uses them for the task.
• When calling another service, use token exchange (RFC 8693) to obtain a new token limited to that service and purpose, instead of forwarding the original token. Forwarding tokens ("token passthrough") lets a compromised component use them anywhere.
• Validate the audience claim so a token meant for one service is not accepted by another.

Prefer tokens that expire in minutes. If a token leaks through logs or an injected instruction, the damage window is short.

Enforce permissions in the tool, not in the prompt

Prompts such as "only read files the user owns" are advice to a model, not a control. A manipulated or confused model can ignore them. Put the enforcement in code the model cannot alter:

async function readDocument(ctx, docId) {
  const doc = await db.docs.get(docId);
  if (!doc || !(await acl.canRead(ctx.userId, doc))) {
    throw new ForbiddenError(); // identical response for missing and forbidden
  }
  return redact(doc);
}

ctx.userId comes from your authenticated session, never from model-generated arguments. Do not let the model supply "user ID" or "role" fields.

Practical rules

1. One identity per agent role. Separate identities for the reader, the planner and the actor (multi-agent trust boundaries).
2. Scope by task. Issue credentials per task or session with only the permissions that task needs, and let them expire.
3. Use cloud IAM, not stored keys. Run agents with workload identity (IAM roles) so there are no static secrets to leak (IAM hardening, secrets management).
4. Separate read and write. An agent that summarizes should hold read-only credentials.
5. Restrict by resource and condition. Limit to specific tables, buckets, folders, tenants and, where supported, time windows.
6. Record who acted. Logs should show both the user on whose behalf the call was made and the agent identity that made it.
7. Make revocation fast. You should be able to disable one agent's credentials without taking down the rest.

Multi-tenant considerations

If one agent service serves many customers, tenant isolation must be enforced at the data layer. Pass the tenant ID from the authenticated session, filter every query by it, and test with cross-tenant requests. Do not rely on the model to keep tenants apart.

What to do about secrets the agent needs

Some tools need API keys. Keep them in the tool layer or a secrets manager, never in the prompt or the model's context. The model should call "send_invoice" and the tool should attach the credential. If a model never sees a secret, it cannot be tricked into revealing it.

Checklist

• [ ] No shared admin credentials for agents
• [ ] Per-agent or per-task identities with narrow scopes
• [ ] Short-lived tokens with audience validation; no token passthrough
• [ ] Authorization checked inside every tool using session identity
• [ ] Secrets kept out of model context
• [ ] Audit logs capture user, agent, tool and arguments
• [ ] Tested revocation procedure