Prompt injection, session hijacking, CSRF, and XSS. Your buyer's security team is going to map the first one onto the other three, because that's how technical people process new threats: they find the nearest known thing and reason from there. Each mapping illuminates something real. Each one also breaks at a specific point, and the break is where the conversation gets interesting. The sentence you want in your pocket: "The agent was legitimately authenticated. Its intent was hijacked through content it processed. We don't have a clean precedent for that condition, and the defense model reflects it." This piece gives you the scaffolding behind that sentence.
Session Hijacking
What it is. An attacker steals or predicts a valid session token to impersonate an authenticated user.
What it does. A user logs in. The server issues a session token, usually a cookie, that proves identity for subsequent requests. The attacker obtains that token through network interception, malware, or prediction, then presents it as their own. The server sees a valid token and opens the door. No password required. MFA protects the initial login but doesn't stop an attacker from stealing the token created after authentication succeeds.
Who's behind it / where it comes from. An external attacker who needs proximity to the session: access to the network, the user's browser, or a vulnerability that leaks the token. Always outside the trust boundary, trying to get in.
What makes it distinct. The attacker steals the proof of identity. The credential itself changes hands. Revoke the token, the attack ends. The entire defense model is protecting the bearer artifact.
Cross-Site Request Forgery (CSRF)
What it is. An attacker tricks a user's browser into sending an authenticated request the user never intended.
What it does. The user is legitimately logged into a trusted site. The attacker crafts a malicious page that, when visited, causes the user's browser to fire a request to the trusted site, complete with the user's valid cookies. The server sees a properly authenticated request and executes it. The user never knew it happened. The attacker never touches the user's credentials. They exploit the trust that a site has in a user's browser, which is a different relationship than the trust a user has in a site.
Who's behind it / where it comes from. An external attacker who controls a separate site, email, or message.
What makes it distinct. The authentication is real. The credential isn't stolen. The server can't distinguish between a request the user intended and one the browser sent on its own. The fix is clean: anti-CSRF tokens and SameSite cookie attributes verify intent at the protocol layer.
Cross-Site Scripting (XSS)
What it is. An attacker injects malicious script into a trusted web page, which then executes in other users' browsers.
What it does. The attacker embeds JavaScript into a page the user trusts: stored in the site's database (stored XSS), reflected through a crafted URL (reflected XSS), or manipulated via client-side DOM processing (DOM-based XSS). When the victim's browser renders the page, the script runs with full trust, able to steal cookies, capture keystrokes, or rewrite content. The user sees a legitimate page. The code running on it is not.
Who's behind it / where it comes from. An attacker who can get content into a trusted channel: a comment field, a URL parameter, a stored document. The payload travels through the application's own delivery mechanism.
What makes it distinct. The attacker's code executes inside the trusted context. The browser can't tell the site's legitimate scripts from the injected ones because they share the same origin. The fix is input sanitization and Content Security Policy headers, both of which work because code and data are structurally distinguishable in HTML.
Prompt Injection
What it is. An attacker embeds instructions in content that an AI agent processes, causing the agent to take unintended actions using its own legitimate credentials.
What it does. An AI agent with valid access to enterprise systems retrieves content containing attacker-crafted instructions. The agent cannot reliably distinguish between the instructions it was given by its operator and the instructions embedded in the content it's reading. It follows the injected instructions using its own authenticated access. In the EchoLeak vulnerability (CVE-2025-32711), a crafted email sat in an inbox until Microsoft 365 Copilot read it during a routine summarization. Copilot extracted sensitive data and exfiltrated it to an attacker's server. It was doing what it was designed to do: reading emails and responding helpfully. The instructions just weren't the user's.
Who's behind it / where it comes from. An attacker who can place text anywhere the agent will read it: an email, a shared document, a webpage, a code comment, a calendar invite. The attacker never touches the agent. They poison the content and wait.
What makes it distinct. The credential stays put. The session is genuine. There's no injected code anywhere in the chain. The agent authenticates normally, retrieves content normally, and acts on instructions that arrived through that content. The agent's intent is hijacked. Its identity remains perfectly valid the entire time. There is no protocol-layer fix because instructions and data are the same thing to an LLM.
In traditional session management, Okta issues and manages the token that proves identity. Revoke the token, kill the session. With AI agents, the credential (an OAuth token, an API key) remains valid throughout the attack. The agent presents a legitimate token to every system it touches. Okta's token lifecycle management covers the credential side of this problem. You also need to scope what that token can reach, because the agent holding it may not be acting on the user's intent.
Trait-Led Comparison
I'm anchoring this comparison on four dimensions because they map to how your buyer already thinks about identity architecture: what trust relationship is exploited, what entity gets hijacked, whether a clean fix exists, and what the defense posture looks like. Each dimension is where one of the traditional analogies does useful work, and where it stops.
Trust relationship exploited
Session hijacking exploits the server's trust in a bearer token. CSRF exploits the server's trust that authenticated requests reflect user intent. XSS exploits the browser's trust in content from a known origin. All three involve a server or browser being deceived.
Prompt injection exploits the agent's inability to distinguish operator instructions from content-embedded instructions. The trust failure lives inside the reasoning layer, the model's process for deciding what to do next. The protocol layer is working exactly as designed. This is where your OAuth intuition helps. You understand that a valid token doesn't guarantee the request behind it is legitimate. This is where it starts to mislead you: with prompt injection, the token is fine, the request is fine, and the agent genuinely believes it's following instructions. The deception happens before the request is ever formed.
What gets hijacked
Session hijacking: the credential (the token changes hands). CSRF: the request (the credential stays put, the action is forged). XSS: the execution environment (attacker code runs in the trusted context). Prompt injection: the intent (the agent's decision-making process is redirected).
In every traditional attack class, you can point to a specific artifact that was compromised: a token, a request, a script execution context. With prompt injection, the artifact is the agent's reasoning. The security community has started calling this the confused deputy problem, and the name fits. The attacker convinces a trusted deputy to misuse its own authority.
Whether a clean technical fix exists
Session hijacking: yes. Secure token generation, HTTPS, HttpOnly cookies, token rotation. CSRF: yes. Anti-CSRF tokens, SameSite cookies. These work because intent can be verified at the protocol layer. XSS: largely yes. Input sanitization, output encoding, Content Security Policy. These work because code and data are structurally distinguishable in HTML.
Prompt injection: no. OWASP states there are no known fool-proof prevention methods. Researchers across OpenAI, Anthropic, and Google DeepMind (Nasr et al., October 2025, "The Attacker Moves Second") tested twelve published defenses under adaptive attack conditions. Every defense was bypassed, most with attack success rates above 90%. The reason is architectural: LLMs process instructions and data as a unified token stream. There is no equivalent of parameterized queries for natural language.
CSRF was solvable because you could add a secret token to each form that the attacker couldn't predict. Prompt injection has no equivalent mechanism. You can't embed a "secret token" in an instruction that the model verifies before following it, because the model processes everything as language and an attacker can instruct the model to ignore the check. When a buyer asks "can't we just validate the input?" this is the structural reason the answer is no.
Defense posture
For session hijacking, CSRF, and XSS, the defense posture is prevention. Implement the fix, block the attack class. For prompt injection, the posture has shifted to blast-radius limitation. You assume injection will happen and constrain what the agent can do when it does: least-privilege credential scoping, confirmation gates for sensitive actions, context isolation between trusted instructions and retrieved content, human-in-the-loop checkpoints.
OpenAI acknowledges this is an open problem. Their instruction hierarchy (teaching models to prioritize system messages over user messages over retrieved content) reduces success rates but doesn't eliminate them. The International AI Safety Report 2026 found that sophisticated attackers bypass the best-defended models roughly 50% of the time with just ten attempts.
Prompt injection is not solved and may not be solvable in the general case. The industry has moved from "prevent the injection" to "limit the damage when it happens." That's a consequence of how language models process information. The engineering effort has been substantial. The architecture is the constraint. Instructions and data are the same thing to an LLM. Until that changes, containment is the defense model.
The defense that translates most directly from traditional identity management to agent security is least-privilege access. If an agent's OAuth token is scoped to read-only on a single mailbox, a successful injection can read that mailbox but can't write to it, can't touch SharePoint, can't send messages. Okta's policy engine already enforces scoping for human users and service accounts. The buyer conversation is about extending that discipline to agent credentials, where the temptation is to grant broad access because the agent "needs to be helpful." Helpful and over-permissioned is exactly the attack surface.
How to Say This in the Field
| Don't say | Do say | Why it matters |
|---|---|---|
| "Prompt injection is basically session hijacking for AI." | "Session hijacking steals a credential. Prompt injection hijacks what the agent decides to do with a credential it legitimately holds." | The buyer needs to understand why token management alone doesn't solve this. |
| "We can prevent prompt injection with input filtering." | "Input filtering helps, but there's no general-case prevention. The defense model is scoping agent permissions so a successful injection can't do much damage." | False confidence on prevention will cost you when the buyer's security team pushes back. |
| "It's like XSS but for AI." | "Stored XSS is the closest structural analog: attacker content delivered through a trusted channel. The difference is you can sanitize HTML. You can't sanitize natural language without breaking the agent." | Lands the analogy and the break in one sentence. |
| "CSRF is the closest comparison." | "CSRF is the closest analog because both involve a legitimately authenticated actor performing unintended actions. But CSRF has a clean fix. Prompt injection doesn't." | Gives the buyer a mental model and immediately tells them where it stops working. |
| "AI agents need broad access to be useful." | "Every permission you give an agent is blast radius if the agent gets injected. Scope it like you'd scope a service account." | Connects to procurement logic the buyer already applies. |
| "This is a totally new problem." | "The closest precedent is the confused deputy problem: a trusted component tricked into misusing its own authority. The new wrinkle is that the trick happens through natural language, not code." | Gives the buyer a named concept to take back to their security team. |
| "OpenAI will fix this." | "OpenAI and Anthropic have both published that this is an open problem. Their defenses reduce success rates but don't eliminate them. Plan for containment, not cure." | Citing the vendors' own acknowledgments is more credible than your opinion. |
| "Prompt injection is the #1 AI risk." | "OWASP ranks prompt injection #1 in their LLM Top 10 for the second consecutive year. For agentic systems with tool access, it's the primary attack surface." | Gives the buyer a specific, citable authority instead of your editorial judgment. |
| "We need to worry about prompt injection." | "Direct injection is a user manipulating their own prompt. Indirect injection is the enterprise threat: an attacker poisons a document the agent reads later, and the agent acts on it." | Focuses the conversation on the attack vector that matters for the buyer's environment. |
| "The agent got hacked." | "The agent authenticated normally and used its own valid credentials. It followed instructions that came from a poisoned email instead of from the user." | Precision here is the difference between the buyer thinking this is a credential problem and understanding it's an intent problem. |
The agent was authenticated. Its credentials were valid. It accessed exactly the systems it was authorized to access. It did exactly what it was told. The problem is that the person doing the telling was an attacker who never touched the agent, never stole a token, never forged a request. They wrote some text in a document and waited. That's the condition your buyer is trying to understand, and the honest answer is that nobody has a clean fix for it yet. What we have is containment: scope the permissions, gate the sensitive actions, and make sure a successful injection can't reach anything that matters when it lands.
Things to follow up on...
- The lethal trifecta framework: Simon Willison's June 2025 formulation argues that any agent combining access to private data, exposure to untrusted content, and the ability to communicate externally is inherently exploitable via prompt injection.
- EchoLeak's XPIA bypass mechanics: The full technical breakdown of how CVE-2025-32711 defeated Microsoft's cross-prompt injection classifier by disguising agent instructions as human-directed email language is worth reading if your buyer runs M365 Copilot.
- Adaptive attacks beat every published defense: Nasr et al.'s "The Attacker Moves Second" (October 2025) tested twelve defenses with adaptive methods and found that prompting-based defenses collapsed to 95–99% attack success rates under adversarial conditions.
- Google's IPI trend data: Google Threat Intelligence reported a 32% increase in malicious indirect prompt injection detections between November 2025 and February 2026, signaling that attackers are actively scaling this vector against production systems.