Deepak Gupta

Identity for AI Agents

AI Security · advanced · 8 min read · last reviewed 2026-08-15

An agent is a new principal. Do not give it the user's cookie or the server's root key. Per-action auth, brokered secrets, and an audit id.

TL;DR

Keep the human, the agent, and the tool as three identities. Collapsing them is a confused deputy.
Issue a downscoped, short-lived token for the task. Never the human session or a static root key.
Authorize every tool call at invocation time, bound to the original user.
The model never reads a secret. Your gateway attaches it.
Destructive tools need a human approval. Prompt injection will ask for a wider scope. The model cannot mint one you never issued.

An AI agent that can call tools is not a feature. It is a new principal on your network: it acts, it holds credentials, it can be talked into doing the wrong thing. If that principal reuses a human's password, a static API key, or the server's own IAM role, you have built a confused deputy with a chat window.

I have spent a decade on customer identity and the last few years on agents that sit on top of it. The pattern that keeps showing up: teams wrap a model around an existing admin API and call it "agentic," then discover the model has the same power as the founder laptop. Secure an MCP server is the protocol-level version. This page is the identity model.

The agent is not the user

Three identities get collapsed in every bad design.

The human who asked. They have an account, a role, a tenant, maybe an SSO session.

The agent (the running process, the workflow, the MCP client) that will call tools for minutes after the human has closed the tab.

The tool or downstream API that actually mutates data.

Authorize the action as the human, executed by the agent, against a tool that has its own narrow credential. If you issue the human's session cookie to the agent, the agent is the human, including every admin toggle. If you issue the server's root key to the agent, the agent is you.

This is the same mistake as embedding a static sk_live key in a Slack bot, scaled up. Replace static API keys is the credential half.

What to issue the agent

Credential	Binds to	Lifetime	Use
User access token, downscoped	The human + tenant + this task	Minutes	Agent acts on behalf of a logged-in user
On-behalf-of / token exchange	Human token in, narrower token out	Minutes	First-party agents inside your IdP
Workload identity	The agent process, not a human	Minutes	Batch jobs, no user in the loop
Per-tool brokered secret	Never visible to the model	One call	MCP, function calling
Human session cookie or root API key	Everything	Hours to forever	Do not

OAuth 2.0 already has the shapes: authorization code for the human, token exchange or client credentials for the workload, fine-grained scopes for the tool. OIDC is how you know which human. You do not need a new protocol to start. You need to stop sharing the one credential you already have.

When the agent uses MCP, authenticate the caller on every tool invocation, not just at connection time. That is how you stop the confused-deputy path. The implementation checklist is in Secure an MCP server.

Authorization is per action, not per chat

A chat session is not a role. "The user opened the support agent" is not permission to refund, delete, or dump the customer table.

Check the human's RBAC (or ReBAC) at the moment of the tool call
Give each tool one intent. A tool that accepts arbitrary SQL is a shell
Put payments, deletions, and production access behind a human approval, not a model "are you sure"
Log every invocation with the human id, the agent id, the tool, and a trace id

Prompt injection will eventually talk the model into asking for a wider tool. The model cannot grant a scope you never issued. That is the whole defense. Red-team the LLM to prove it.

A build order that fits a real product

Week 1. Inventory every agent and MCP server. Write down which human, which credential, which tools. Anything running on a founder's API key is an incident you have scheduled.

Week 2. Put a gateway in front of tools. The model asks the gateway. The gateway attaches the secret and checks the human. No secrets in the prompt, the trace, or the tool description.

Week 3. Replace static keys with short-lived tokens. User-delegated where there is a user. Workload identity where there is not.

Week 4. Add approval on destructive tools and a single audit stream. If you cannot answer "which agent refunded this customer," you are not ready to scale the agent.

Do not start with a vendor for "AI identity" until this shape exists. Most of those products assume you already know who the agent is.

What "good" looks like

Every tool call is attributable to a human and an agent
The model cannot read a credential
A stolen agent token dies in minutes and cannot mint a wider one
Destructive actions need a person
You can revoke one agent without rotating the company's master key

If you are still arguing about which model is "safer," you are on the wrong layer. The model is persuadable. The scopes are not.

Failure modes

The founder's cloud key in the agent env. You automated a breach.
Authorizing at connect time only. The session outlives the user's intent.
One tool that can do everything. Prompt injection plus a shell.
Secrets in the context window. An injection will ask for them. See MCP.
No audit id. You will not be able to explain the action to a customer or an auditor.

Key takeaways

A chat session is not a role.
OAuth already has the shapes. You do not need a new protocol to start.
One tool that accepts arbitrary SQL is a shell you handed to a persuadable model.
If you cannot say which agent refunded a customer, you are not ready to scale the agent.
Do not buy an 'AI identity' vendor until this shape exists.
The safer model is the wrong layer. The scopes are the defense.

Frequently asked questions

Can the agent just use the user's login session?: No. Then the agent is the user, including every admin toggle, for as long as the cookie lives. Exchange the session for a downscoped token with a short TTL.
How is this different from securing an MCP server?: MCP is one way to expose tools. The identity model is the same: authenticate the caller, authorize the action, broker secrets, log the invocation. The MCP guide is the protocol checklist.
What credential should a batch agent use when no user is present?: A workload identity, not a copied user token and not a static API key. Client credentials or SPIFFE-style workload identity, scoped to that job.
Will prompt injection always get through?: Assume it will reach the model. It cannot grant a scope you never issued, and it cannot approve a refund if a human has to. Structure beats prompting.
Do I need a new identity product for agents?: Not first. Inventory, a gateway, short-lived tokens, and per-action checks get you most of the way. Buy a product when that shape is in production and the remaining gap is scale.