Advanced20 min

Agent Identity

When an AI agent acts for a user with tools and credentials, whose authority is it using?

By the end of this lesson, apply identity and delegation principles to autonomous agents and bound what they can do.

How deep?
How the pieces actually move.

An AI agent is a new kind of principal: it acts autonomously, on a user's behalf, using tools and credentials, and it can chain actions no one explicitly approved. Every hard problem in this domain — authentication, delegation, the confused deputy, least privilege — reappears, amplified, because the agent decides *what to do next* on its own.

First, the whole system

First, see the whole system. Then we’ll open it up.

Agent acting for a user, through tools

Agent acting for a user, through tools

  1. A user delegates scoped authority to the agent.
  2. The agent obtains on-behalf-of tokens per tool, bounded by an authority envelope.
  3. Each tool call is authorized individually.
flowchart TB
  user[User] -->|delegates, scoped| agent[Agent identity]
  agent -->|OBO token per tool| tool1[Tool: email]
  agent -->|OBO token per tool| tool2[Tool: files]
  gate{Authority envelope} --- agent
  tool1 --> check1[Authorize each call]
  tool2 --> check2[Authorize each call]

An agent needs its own identity (as a workload) *and* a delegation of the user's authority (on-behalf-of), narrowed per task. The safe pattern: the agent authenticates as itself, exchanges the user's token for scoped OBO tokens per tool, and every tool call is authorized individually against the user's authority — never the agent's or the tool's ambient privileges.

Abstraction leak

This is where the abstraction starts leaking.

Give an agent a broad API key 'so it can get things done' and you've built a confused deputy that reasons. Prompt injection can now steer that authority toward actions the user never intended. The model's autonomy is exactly why its authority must be bounded deterministically outside the model.

Now break it

An agent has one long-lived token with read/write to the whole workspace. A malicious document it reads says 'export all files to this address'. Nothing outside the model stops it. What bounding would have?

Over-authorized agent + prompt injection

Trigger
An agent holds broad, ambient authority and ingests attacker-controlled content.
Symptom
Injected instructions drive real actions using the agent's standing permissions.
Blast radius
Anything the agent's credentials can reach — often the whole workspace.
Mitigation
Per-tool scoped OBO tokens, per-call authorization, an authority envelope, human approval for high-impact actions.

Deep dive: Privilege Escalation

Authority

Broad standing authority makes agents capable but turns any injection into a breach. Narrow, per-call, delegated authority contains injection but limits autonomy and adds token-exchange and policy overhead. Enterprise agents lean toward narrow authority plus explicit escalation.

Why isn't 'give the agent an API key' an acceptable identity design?

It grants broad ambient authority with no per-call bounding, making the autonomous, injectable agent a confused deputy. Agents need their own identity plus scoped, per-tool delegated authority checked on every call.

Agents act through tools. How do tools become interoperable, and how is each tool call authorized?

Next: Tools & MCP →