AI security · Day 14 of 100 · AI cybersecurity · 16 min

How Does an AI Agent Get Its Identity?

TLDR: AI agents use application identities, service accounts, and tokens issued through ordinary identity systems. Following an imaginary assistant called Pip, I explain how OAuth delegation works and why a receiving service still needs to authorize each requested action and resource.

I started with an embarrassing gap: I understood what an AI agent could do, but not how it was allowed to do it.

• How was it authenticating?
• Who had given it an identity?
• Was it using my access or its own?
• Had someone issued it an employee badge while I wasn't looking?

The answer was familiar: applications, service accounts and tokens. No secret AI login ceremony.

Let's follow an imaginary assistant called Pip. Its first job is to read a project folder and prepare a summary. A modest beginning. No need to give it the Death Star's admin account.

Who gives Pip an identity?

The people operating Pip choose its identity setup; an identity service maintains the record. An authorization server issues its access tokens, and the receiving service decides what those tokens permit. These are roles, sometimes supplied by the same platform.

Pip's chat name is not a security identity. Its application may use a dedicated identity, a shared service account, or a connection you authorized. A conversation ID tracks a run; it does not create an account.

The owner is accountable for Pip and its shutdown. A token is a temporary credential used to exercise its access.

Pip can keep an identity while its tokens expire. But no universal identity follows every agent across companies. This is a design choice, not an AI birth certificate.

AWS AgentCore and Microsoft Entra offer examples, not a universal model.

Is OAuth authentication or authorization?

OAuth authorizes access. Authentication establishes who is signing in or which application is calling. A flow can involve both.

The client requesting access is Pip’s application or connector, not the human or the model itself.

• An ID token, in OpenID Connect, tells the client about the user's authentication: who signed in.
• An access token is presented to an API to exercise authorized access: what this request may access, subject to the API's checks.

“You signed in” and “this app may read documents” are different claims. OpenID Connect adds the identity layer; its ID token cannot replace an API access token.

Does somebody have to log in to give Pip access?

Sometimes. OAuth supports both access delegated by a user and application access without a user signing in. The difference is where the permission comes from.

Route one: Pip acts on your behalf

You connect the document service, sign in if needed, and approve access under its consent and policy rules.

The app exchanges the returned code for an access token. Production flows also need safeguards such as PKCE, which binds the code exchange to the client that started it. A refresh token may obtain later access tokens without another login. You do not type your password for every document Pip reads.

Route two: Pip acts with the application's own permission

For an application that can securely authenticate itself, an administrator grants application permissions. The app requests a token using the client credentials grant, without a human login or impersonated user.

These OAuth flows support different permission sources, not different safety guarantees. Pip may need only the Apollo folder while its application account can read every company folder. An attacker who redirects Pip could retrieve payroll too. A dedicated identity does not itself restrict permissions.

The API call is machine to machine; its permission can still come from a user. Unattended work may continue under an existing user-delegated grant.

When Pip requests a document, the API must decide whether to trust and allow it. That decision point is a security boundary, not necessarily a separate physical server.

A gateway or API middleware may validate the token; the application must also enforce access to that document. Database policies can add enforcement. Together, the checks must stop an Apollo-only request from reading payroll.

Keep credentials outside the model’s prompt: whoever possesses a bearer token can use its permitted access. Treating one as conversation material is a poor career move.

What does this look like in ChatGPT, Claude or a local agent?

Your login to an assistant and its access to another service are separate relationships. Signing into a chat product does not, by itself, give it your document account.

Connection details vary: see OpenAI’s authentication guide, Claude’s connector guide, and Claude Code’s MCP examples.

Local stdio means two processes exchange messages through standard input/output. It is a transport, not a login. A local tool may use credentials from its environment and the process’s operating-system permissions; the remote OAuth flow does not automatically apply. The MCP specification distinguishes these arrangements.

Pip uses an MCP server. Where does the next token come from?

Pip asks a connector for an Apollo document; the connector calls the document service. Downstream means the next service called to fulfil a request: here, the document service.

The document API serves files and enforces access. The document authorization server checks grants and issues tokens for that API. One provider may operate both roles.

The document authorization server issues Token B; the connector cannot invent permission because Pip asked nicely.

MCP lets applications call tools. Pip’s application contains the MCP client; the connector providing the tool is the MCP server.

Pip presents Token A to the protected remote connector. To call the separately protected document API, that connector needs Token B.

Example: you previously connected your document account. The connector was registered, you approved access, and the document authorization server issued a refresh token. Registration identifies the client; it does not grant document access.

For a fresh B, the connector presents that refresh token and applicable client authentication. The server checks the grant and client binding before issuing B. This refresh-token flow does not exchange A for B:

Alternatively, the connector can use administrator-granted application access. Token exchange presents one credential to an authorization server to request another under policy. RFC 8693 covers that separately configured option; it is not automatic in MCP or used above.

Without an approved arrangement, the connector must fail or request a connection. A alone is insufficient.

Why not forward A? A cinema ticket is not a train ticket merely because both have a barcode. A was issued for a different recipient. MCP security guidance prohibits blindly passing it through.

Suppose a shared connector can read Apollo and payroll, but you may read only Apollo. If it accepts your payroll request merely because you may call the tool, it lends you authority you lack. This is a confused deputy: a trusted service misusing its power for an unauthorized caller. It must check your access to the file; accepting a broadly privileged B does not establish your own right to the file.

How does the whole authorization flow fit together?

Two connections enable one request: Pip can call the connector, and the connector can call the document API. Here is the complete route.

This example uses delegated access on both connections. Setup and consent need not repeat for every request; renewal still depends on a usable grant.

The model chooses the call; software handles credentials and enforcement. Passing those checks does not prove it chose the right mission.

How does legitimate authority get abused?

Attackers can steal credentials or persuade their legitimate holder to misuse them. In the second case, every token signature can remain valid.

Pip's badge works. The problem is whose instructions Pip follows after entering the building.

1. Send credentials to the wrong place

An OAuth client can be misled about where to send credentials. A September 2026 MCP Python SDK advisory describes credential exposure involving malicious authorization metadata and missing issuer or credential binding.

The fix requires the SDK patch and appropriate issuer and client-registration configuration, not trust in whatever endpoint arrives.

2. Accept a real token meant for somewhere else

A token can be genuine and still be wrong for the service receiving it. An October 2026 Python SDK advisory describes missing audience enforcement. A signature check alone does not establish the intended recipient. Upgrading alone is insufficient: deployments must enable audience enforcement or enforce it in their verifier.

3. Persuade an authorized agent to leak private data

Here the attacker changes the agent's instructions rather than its credentials. Invariant's GitHub MCP demonstration placed malicious instructions in a public issue. With the demonstrated access and approval conditions, the agent retrieved private repository information and exposed it in a public pull request. This was a researcher demonstration, not evidence of a GitHub platform breach.

In my MCP response-poisoning lab, the agent spotted the injection. I then tested routing directly: the vulnerable local test bridge accepted an unauthorized recipient. Tool enforcement must hold even when model judgment does not.

4. Turn retrieved content into an outbound leak

The reported EchoLeak chain used malicious email content encountered by Microsoft 365 Copilot to drive an outbound data leak. The assistant's legitimate access became part of the attack path. The researchers' account describes the chain and remediation; this is a historical case, not a claim that the same flaw remains exploitable today.

In both cases, content to read becomes instructions to obey. A valid token cannot tell the difference.

What can we do about it now?

Give Pip less standing power, and enforce the important decisions outside the model.

• Give each connection an accountable owner and a way to revoke access.
• Limit resources, actions and token lifetime; keep credentials out of prompts.
• Validate the issuer, intended recipient and permissions at each service.
• Enforce allowed files, recipients and destinations in the tool or gateway.
• Require specific approval for consequential actions, bound to what will actually execute.
• Record the user, agent, tool and outcome so the action can be traced.

These reflect the OWASP AI Agent Security guidance. “Read the project folder” should not quietly become “publish its contents.” Pip may be enthusiastic; the permission system should be boring.

Do we need an alternative to OAuth?

OAuth grants access; it does not decide whether a tool call matches your task. Changing token formats alone will not solve that mismatch.

Two complementary directions look especially useful:

• Workload identity: only the approved Pip deployment should receive Pip’s identity. Checking evidence about the running process and environment against policy is attestation. Establishing which workload qualifies is the foundation; short-lived credentials are one benefit. SPIRE attestation documentation explains this approach, which can complement OAuth.
• Task-specific authority: restrict permission to “read this folder” or “buy this approved cart.” Google’s AP2 payment mandates illustrate the direction, not a universal solution.

For Pip, the useful improvement is a pass tied to the job, with an enforceable boundary. A shinier badge is optional.

Where is agent identity heading?

My bet: agents become managed participants in delegated work, with distinct identities, limited permissions and accountable owners. Keeping those limits intact across handoffs is the challenge.

NIST’s identity discussion connects this to familiar IAM problems: shared credentials blur accountability; long-lived secrets and excessive access magnify mistakes. Existing foundations help, but adopting a protocol does not make an agent safe.

Why does Pip need an identity lifecycle?

Permission must change with the job, owner or deployment. Pip’s project can end while its connector still holds a usable grant. Removing the chat shortcut does not end that access.

A continuing grant can renew tokens, and disabling Pip may not immediately invalidate existing ones. Test the services it could reach. Otherwise we have invented an employee who leaves but keeps renewing the door pass.

What happens when agents call other agents?

Each handoff needs a verifiable identity and limited authority. A more powerful agent must not lend its full privileges to every caller.

An identifiable actor is a security identity the receiving system can verify and authorize, not an agent name in a prompt.

You approve a laptop task and budget. Pip delegates quote comparison, supplier review and the approved purchase to three agents with separate identities. The purchasing agent’s wider company access must not expand this order’s authority:

A changed supplier, amount or delivery destination needs a new decision under policy. A subagent should not gain permission because another agent wrote “urgent” in a prompt.

The audit must identify who requested, delegated and executed the action, under what authority. Shared task IDs connect records; shared credentials obscure actors. Token exchange can support delegation, but does not supply every business constraint or cross-service revocation rule.

Approve the transaction, not merely access to the tool. The purchase service must enforce supplier, items, budget and expiry.

Permission for one small purchase must not become permission for a thousand. AWS’s work across agent actions illustrates why controls extend beyond individual calls.

Routine work can run inside approved limits; exceptions need specific decisions. Approving every harmless lookup would turn oversight into a clicking competition.

Across organizations, each must decide which identities and delegations it trusts. More handoffs mean more accountability to preserve, not fewer people responsible.

Takeaways

• Pip gets access through ordinary software identity and credential systems.
• OAuth can support user-delegated access or app-only access; neither guarantees safe behavior.
• Each service boundary needs appropriate authority. In this OAuth example, the connector obtains its document-API token from an authorization server under an approved grant.
• A valid credential can survive the entire attack. The tools must still enforce the task's limits.

I started by asking who gave Pip a badge. The more useful question turned out to be who can limit what Pip does with it, and take it away when the job is done.

Filed under AI security, identity, OAuth, MCP, authorization. If any of this is wrong, or you have hit the same thing, tell me.

Published 20 October 2026. Updated 4 November 2026.