Don’t Reuse Human Identity for Agents

Your agent opens a browser profile that already holds your SSO cookie. Or it inherits the same API key your IDE uses. Or a child agent receives the parent’s token because “it’s already authenticated.”

That feels like identity. It is not.

A human session says who you are in one interactive context. An agent is a different actor: it runs without continuous supervision, crosses tool and org boundaries, and can spawn more agents. Reusing the human credential treats the agent as an extension of your browser tab. The blast radius says otherwise.

Short answer

Field rule: give the agent its own declared identity, bound to a principal chain that names who authorised it. Check declared versus observed behavior. Do not treat a reused human session, shared API key, or parent-token passthrough as the agent’s identity.

Agent identity is not “same as me, but automated.” It is a separate principal with a traceable grant.

Why human identity frameworks break for agents

Otsuka, Toyoda, and Leung define AI Identity as the continuous relationship between what an agent is declared to be and what it is observed to do, bounded by confidence that those two still correspond. Their gap analysis compares human and AI identity across substrate, persistence, verifiability, and legal standing. The asymmetry is structural. Extending human frameworks to agents without a structural change produces systematic failures. [1]

That matches what shows up in the field:

• A browser user has a body, a login ceremony, and a session that ends. An agent has none of those by default.
• SSO and OAuth sub claims were built for human subjects. When the subject is an autonomous agent, those claims do not name the agent; they name (or imply) the human whose credentials were reused.
• Revoking “the user’s session” does not cleanly answer which agent instance, which child, or which capability grant should die.

The Agent Identity Protocol (AIP) Internet-Draft states the operational gap directly: when an agent presents itself to an API, payment processor, or another agent, there is no standard mechanism for persistent agent identity, the human or organisation on whose authority it acts, permitted actions, compromise or revocation, or trustworthy history. [2]

Internet-Draft caveat: AIP draft-03 is a working document. It is not endorsed by the IETF and has no formal standing in the IETF standards process. Treat it as design vocabulary and a problem statement, not as a ratified standard.

Declared versus observed

The useful check is not “does the token look valid?” It is whether the agent’s declared identity still matches what the system observes it doing.

Declared: who the agent claims to be, which model or build it registered as, which capabilities it was granted, and which principal authorised that grant.

Observed: which tools it actually calls, which hosts it reaches, which child agents it spawns, and whether those actions stay inside the grant.

When declared and observed diverge, you do not have a small config drift. You have an identity failure. Otsuka et al. put that correspondence at the center of AI Identity. [1] Field practice follows: log both sides, compare them, and fail closed when they stop matching.

Principal chain: who authorised it

AIP’s architecture separates layers that human-session reuse collapses into one cookie:

1. Core Identity — who the agent is (persistent agent identifier, key material, registration metadata).
2. Principal Chain — who authorised it (human or organisational principal at the root; parent agents only as delegated links).
3. Capabilities — what it may do (scoped, constrainable, revocable).

Human sovereignty is explicit in the draft: every agent action must trace to a human or authorised organisational principal. [2]

That chain is the difference between “the agent has a token” and “this action is still under a named grant.” If a child agent acts, the record should show the attenuation path: root principal → parent agent → child, with scopes that never exceed the parent’s effective set. Passthrough of the parent token erases that path.

AIP also positions itself relative to adjacent stacks:

• MCP: AIP sits beneath MCP authorisation. It supplies agent identity that OAuth’s sub claim cannot supply when the subject is an autonomous agent rather than a human user. [2]
• SPIFFE: complementary for workload identity inside infrastructure-managed environments. AIP targets agents that act for named humans across organisational boundaries. Use both where each fits; do not pretend SPIFFE alone answers “on whose authority.” [2]

You do not need to implement AIP tomorrow. You do need the separation those layers force: agent identity ≠ human session ≠ workload identity ≠ tool grant.

What NOT to do

These patterns look convenient. They reuse the wrong unit.

1. Browser-profile reuse. Pointing the agent at your logged-in Chrome profile makes every cookie, SSO session, and “remember this device” token available to nondeterministic tool use. Isolate the agent’s browser context. Grant only the sessions the agent’s identity record allows.
2. Shared API key. One key for the human IDE and the agent means logs cannot distinguish actors, and revocation cannot stop the agent without stopping you.
3. Parent-token passthrough. Giving a child agent the parent token (or the human token) collapses the principal chain. Prefer attenuated, purpose-scoped credentials. See Do Not Give Child Agents the Parent Token.
4. SSO-as-agent-identity. Completing a human OAuth flow and stuffing the resulting access token into the agent runtime proves a human authenticated once. It does not create a persistent agent identity, a capability manifest, or a revocation handle for that agent.
5. Name-only trust for tools. Approving MCP servers by familiar label while the agent still runs under your session compounds two failures: wrong identity unit and unbound tool content. Pair this note with Bind MCP Approval to Content, Not the Tool Name.

Sandbox tests: six cases

Use these as acceptance checks for an agent runtime, wrapper, or policy layer:

1. Session isolation: start an agent with a clean browser profile. Confirm it cannot read cookies or tokens from the operator’s interactive profile.
2. Distinct actor in logs: run one human API call and one agent API call against the same service. Audit logs must show different actor identifiers. A shared key fails this test.
3. Principal chain present: before tool access, require an identity record that names the agent, the approving human or org principal, and the grant scope. Missing principal → deny tools.
4. Child attenuation: spawn a child agent. Confirm it receives a narrower credential than the parent and cannot present the parent token. Revoking the child must not require rotating the human’s primary credential.
5. Declared vs observed mismatch: grant email.read only; attempt email.send or an undeclared host. The runtime must block and record the mismatch against the declared identity.
6. Revocation without human lockout: revoke the agent’s grant (or disable its identity record). Subsequent agent calls fail. The human’s own interactive login continues to work.

The test is not whether OAuth still succeeds. It is whether the agent has an identity you can grant, observe, and kill independently of the human session.

Fit with identity-record and credential-boundary posts

This note sits upstream of Give the Agent an Identity Before You Give It Tools. That post is the artifact: write the identity record first. This post is the reason the record cannot be “reuse my SSO.”

It also pairs with Credential Boundary for AI Coding Agents: separate the human’s credentials from the agent’s working set. A boundary without a distinct agent identity still leaves every action attributed to you.

Optional links for the same control plane:

• Child-agent authority attenuation — how the principal chain shrinks at each hop.
• Bind MCP approval to content, not name — tool trust is content-bound; agent trust is identity-bound. Both must be true.

OWASP’s State of Agentic AI Security and Governance 2.01 (published 1 June 2026) frames securing and governing autonomous AI systems as a frameworks-and-governance problem, not only a model-safety problem. Treat Agent Identity / non-human identity as a control-plane concern in that landscape—without pretending a resource-page blurb is a chapter-length standard. [3]

Evidence versus opinion

Evidence: Otsuka, Toyoda, and Leung define AI Identity as declared-versus-observed correspondence; they argue that extending human identity frameworks to agents without structural modification produces systematic failures; they identify structural gaps that engineering alone will not close. [1]

Evidence: AIP draft-03 describes an identity gap (persistent agent identity, authority, permitted actions, revocation, history), requires human sovereignty via a principal chain, separates Core Identity / Principal Chain / Capabilities, and states that AIP sits beneath MCP auth because OAuth sub cannot supply identity for an autonomous agent. It also treats SPIFFE as complementary workload identity, not a substitute for agent-for-human authority. [2]

Evidence: The OWASP GenAI project published State of Agentic AI Security and Governance 2.01 on 1 June 2026 as a landscape report on frameworks, governance models, and standards for autonomous AI. [3]

Caveat: AIP is an Internet-Draft (work in progress, no formal IETF standing). Do not cite it as a finished standard.

Opinion / field rule: do not reuse human browser sessions, shared API keys, or parent tokens as agent identity. Require a declared agent identity, a named principal chain, declared-versus-observed checks, and independent revocation before tools.

That last paragraph is the control design. Standards may evolve. The wrong unit of identity is already a production failure mode.

Sources

1. Takumi Otsuka, Kentaroh Toyoda, Alex Leung, “AI Identity: Standards, Gaps, and Research Directions for AI Agents” (arXiv:2604.23280) — https://arxiv.org/abs/2604.23280
2. Paras Singla, “Agent Identity Protocol (AIP): Decentralized Identity and Delegation for AI Agents,” draft-singla-agent-identity-protocol-03 — https://datatracker.ietf.org/doc/draft-singla-agent-identity-protocol/ · HTML: https://www.ietf.org/archive/id/draft-singla-agent-identity-protocol-03.html
3. OWASP GenAI Security Project, “State of Agentic AI Security and Governance 2.01” (1 June 2026) — https://genai.owasp.org/resource/state-of-agentic-ai-security-and-governance/

Next free step

Pick one agent this week. Write a five-line identity record before it gets tools:

1. agent name / instance id
2. approving human or org principal
3. allowed capabilities (short list)
4. credential that is not the human’s interactive session
5. revoke path (how you kill this agent without locking yourself out)

If you cannot fill those five lines, the agent is still borrowing a human identity. Fix that before you add another MCP server.