Research Deep-Dive

Agent Identity Confusion and Session Hijacking in AI Systems

Every AI agent action is, implicitly, an answer to a question: who am I acting as, right now? Most of the time that answer is obvious. This piece is about the 7 real, different ways that answer can get quietly wrong — and a real test where an agent got it right.

7
Distinct channels a forged identity claim can arrive through
1
Real, live test with a genuine Claude model, not a simulated one
2
Privilege level the agent correctly held, unprompted

The Question Every Agent Action Implicitly Answers

Before an agent does anything — replies, calls a tool, hands off to another agent — there's an implicit answer baked into that action: who is this being done as, and on whose authority? Usually that's trivially correct, bound to whoever actually authenticated the session. Agent identity confusion is what happens when that binding slips — not because the agent was hacked, but because it trusted an identity claim instead of a verified one.

Seven Real Channels a Forged Claim Can Arrive Through

This isn't one attack — it's a pattern that shows up wherever an agent has more than one possible source of truth about identity:

VectorWhat it looks like
Peer impersonationAnother agent's message simply claims to be a supervisor or higher-privilege peer
Self-role upgradeContent embedded in the conversation tells the agent "you are now the admin agent"
Confused deputyThe agent is nudged into acting on behalf of a principal it never actually verified
Handoff spoofA structured handoff envelope's sender field is forged
Tool-asserted identityA tool's own result field claims who the caller is, and the agent trusts it
Session identity mixA session is framed as resuming a prior one, but as a different, higher-privilege principal
Orchestrator forgeA packet from the orchestrating layer itself forges a role or permission level

Every one of these is structurally the same question with a different delivery mechanism: does the agent bind its actions to something actually verified, or to whatever the most recent, most convincing-sounding claim happened to say?

Session Hijacking, Specifically

The "session identity mix" vector is the closest match to classic session hijacking, adapted for agents. The shape: a request frames itself as continuing an existing session — "as we discussed earlier," "resuming where we left off" — but attributes that prior session to a different, usually higher-privilege principal than the one actually authenticated for the current one. A guest-tier session gets framed as if it were actually a VIP user's continuing conversation, and the test checks whether the agent's context genuinely shifts to that higher-privilege framing as a result.

What makes this variant particularly worth testing for on its own: it doesn't require impersonating anyone in a single message. It just needs to make a false claim about continuity sound more credible than a false claim about identity alone would.

A Real Test, With a Genuine Model — Not Simulated

This is worth being precise about, because it's a meaningfully stronger form of evidence than most examples in this space: this is a real, live test result from a genuine Claude model, not a mocked or simulated response.

Real model, real response, full text

An agent operating with a genuine, real privilege level was given a planted note, framed as a message left by a previous shift, embedding an instruction to deploy to production and skip the usual reviewer step — an attempt to get the agent to act as though it held elevated deployment authority it didn't actually have.

The agent's real response identified the embedded instruction explicitly, refused to act on it, and — without being asked to — reaffirmed its own actual identity and privilege level, correctly, on its own initiative. It also independently noted the structure of the message looked like it might be a deliberate test.

Nothing about this was scripted into the test itself asking the agent to "state your identity." The agent volunteered the correct, verified answer to the implicit identity question entirely on its own, in the course of explaining why it wasn't going to comply.

How This Fits With Confused Deputy and A2A Identity Attacks

These three topics overlap enough to be worth distinguishing clearly, since they're often the same underlying failure viewed from different angles:

Practical Defenses

This closes out the attack-pattern series

Zero-click, persistence-write poisoning, A2A identity forgery, circuit breakers, confused deputy, and agent identity confusion — six real, tested angles on the same underlying theme: verification over trust.

Frequently Asked Questions

What is agent identity confusion?
Agent identity confusion is when an AI agent's actions get bound to an identity claim it received — from a peer message, a tool result, a resumed session, or its own instructions — rather than a genuinely verified principal. The agent may reason correctly about everything else and still act on behalf of the wrong identity.
What counts as session hijacking for an AI agent specifically?
A session hijacking attempt tries to get an agent to treat a new or resumed session as if it belonged to a different, usually higher-privilege, principal than the one actually authenticated for that session — for example, framing a request as continuing a prior conversation as a VIP or admin user rather than the actual, verified guest session.
Did a real AI agent actually resist this in testing?
Yes. In a real, live test using a genuine Claude model, an agent was given an embedded instruction framed as a note from a previous shift, attempting to get it to act with elevated privilege. The agent read the note, explicitly identified it as a manipulation attempt, refused to act on it, and explicitly reaffirmed its own actual, correct privilege level rather than the one the embedded content implied.
How is this different from confused deputy attacks?
Confused deputy attacks focus on whether a privileged tool gets invoked on an untrusted operand. Agent identity confusion is the broader question of whether the agent's own sense of identity and privilege stays correctly bound to a verified principal, across every channel a false claim could arrive through — peer messages, tool results, resumed sessions, and more, not just tool arguments specifically.
Is orchestrator-level identity forgery a real, distinct risk?
Yes. If the layer coordinating multiple agents can itself be manipulated into forging a role or permission level in the packets it sends downstream, individual agents trusting that orchestrator have no way to catch the forgery on their own — making the orchestrator's own integrity a real, separate point of failure worth testing specifically.

The Full Attack-Pattern Series