Agentic Browser Session Hijacking: Indirect Prompt Injection Into Authenticated Browser State

Agentic browser session hijacking is SSA descriptive wording for a specific target within tool and environment state: the authenticated session an AI browser holds on the user's behalf, including cookies, logged-in accounts, and autofilled payment data. The defining cause is adversarial content on a page or in a screenshot that an agent processes as if it were the user's own instruction. The defining difference from ordinary prompt injection is what the injected instruction reaches: not just the model's next reply, but a browsing session that is already logged into a bank, an email provider, or a stored payment method.

What it is

The defining object is the browser session state an agentic browser carries across every page it visits within a task: active cookies, account logins, saved addresses, and stored card details, all available to the agent without a fresh authentication step per site. The defining cause is untrusted content, embedded in a webpage's visible text, its HTML, or a screenshot the agent takes of its own browsing, that the agent's language model cannot distinguish from the user's typed request. The defining consequence is that the agent takes an action inside an already-authenticated context, an account lookup, a purchase, a credential read, that the user did not specifically request and would not have approved if shown it as a separate step.

What it is not

A phishing page that only fools a human, with no agent in the loop to carry authenticated session state into the attacker's hands.
A vulnerability in the underlying browser engine itself (a memory-safety bug in the rendering pipeline, for instance) rather than in how an agent layered on top of that browser interprets page content as instructions.
MCP tool description or tool-result poisoning, covered separately by MCP tool poisoning, where the untrusted content arrives through a tool call's return value rather than through a webpage the agent navigates to directly.
A user knowingly authorizing a purchase or account action after the agent surfaces it for confirmation. The defining failure here is the action completing without that confirmation ever being asked.

In scope

Indirect prompt injection delivered through ordinary webpage text, hidden or low-contrast text, and text embedded in images that an agent's OCR or vision path reads during a screenshot-based browsing loop.
The specific consequence of an agentic browser acting inside a session that is already authenticated, rather than needing to steal credentials first.
Autofill and stored-payment abuse, where the agent completes a transaction using saved data without a separate confirmation step.
Detection signals and defenses for the browser-as-environment case, distinct from the general prompt-injection literature this pattern draws on.

Target state, trust boundaries, and impact

The target state sits inside the browser profile an agent drives: cookies and session tokens for every site the user has ever logged into during that profile's life, the browser's autofill database of addresses and card numbers, and any credentials the agent itself can read from an already-open tab. The trust boundary that fails is the one between the user's typed request and the content of the page the agent is currently looking at. Both arrive in the same context window, and the model has no reliable, built-in way to mark one as an instruction and the other as data to summarize or click through. Brave's research team stated the failure directly after finding an indirect prompt injection vulnerability in Perplexity's Comet browser: the agent "treats everything as user requests," so a webpage's content and the user's actual goal compete for the same authority once both are inside the same prompt (Brave, *Agentic Browser Security: Indirect Prompt Injection in Perplexity Comet*, 2025-08-20).

The precondition that makes this target state especially valuable to an attacker, compared with ordinary prompt injection against a stateless chatbot, is that an agentic browser already holds standing authority. It does not need to steal a password to reach a bank account or an email inbox; it only needs to be told, by content it should never have trusted, to use the access it already has. Brave's proof of concept against Comet demonstrated exactly this chain: injected instructions directed the agent to its own account page to extract the user's email address, then to Gmail, where the user was already logged in, to read a one-time password, exfiltrating both without the user approving either step. Brave summarized the underlying exposure plainly: "the AI operates with the user's full privileges across authenticated sessions, providing potential access to banking accounts, corporate systems, private emails, cloud storage, and other services" (Brave, *Agentic Browser Security: Indirect Prompt Injection in Perplexity Comet*, 2025-08-20).

Persistence

A single successful injection can act within the current session, using whatever accounts are already logged in during that browsing task. Because the session state it abuses, cookies, saved logins, autofill data, lives in the browser profile rather than in the conversation, the same injected instruction can also trigger actions the next time the agent resumes a task in that profile, and any account takeover completed mid-session (a captured one-time password, a changed recovery email) persists as a compromise that outlives the browsing session entirely. That combination is why this entry is classified session to cross-session rather than single-turn: the immediate action is scoped to one browsing task, but the state it reaches and the state it can corrupt are not.

What the research establishes

Brave's security team disclosed the first Comet finding on 2025-08-20 after privately reporting it to Perplexity: a page could carry hidden instructions that redirected the agent into its own authenticated tabs, chaining an account-details lookup with a live Gmail session to exfiltrate a one-time password (Brave, Agentic Browser Security: Indirect Prompt Injection in Perplexity Comet). Brave's recommended mitigations from that disclosure were specific about where the fix belongs: the browser should "clearly separate the user's instructions from the website's contents when sending them as context," model actions should be "independently checked for alignment against the user's requests," and security-sensitive actions like sending a message should "always prompt the user to confirm."

Brave returned on 2025-10-21 with a second disclosure showing the same class of failure reached a new delivery channel: faint, human-imperceptible text, light blue on a yellow background, embedded in a webpage or image, invisible to a person but extracted intact when the agent's own screenshot-and-OCR path fed it back into the model as though it were the user's query. The same technique affected more than one AI browser, including Comet and Fellou, which is why Brave framed the underlying cause as systemic rather than product-specific: "each of these attacks look similar. Fundamentally, they boil down to a failure to maintain clear boundaries between trusted user input and untrusted Web content when constructing LLM prompts while allowing the browser to take powerful actions on behalf of the user" (Brave, Unseeable prompt injections in screenshots: more vulnerabilities in Comet and other AI browsers).

Guardio Labs' *Scamlexity* report, also published 2025-08-20, demonstrated the autofill and payment variant independent of Brave's account-takeover chain: prompted to buy an Apple Watch, Comet navigated a fraudulent storefront and "autofilled our saved address and credit card details from the browser's auto-fill database," completing the purchase with no separate confirmation step. Guardio's researchers characterized the underlying reliability problem in one line worth treating as a design principle rather than a punchline: "when security depends on chance, it's not security" (Guardio Labs, "Scamlexity": When Agentic AI Browsers Get Scammed). This article does not reproduce any of these techniques; it treats them as documented evidence that the browser's authenticated session, not just the model's next response, is the state at risk.

Detection: observable signs

A browsing agent navigates to an account, settings, or credential-bearing page that the user's own instruction never named.
A purchase, form submission, or account change completes without a distinct confirmation step the user can review before it executes.
Extracted page text or OCR output from a screenshot contains directive language ("ignore," "navigate to," "enter this code") that does not match the page's visible, human-readable content.
Autofill fields populate and submit within the same agent turn that first loaded a new, unfamiliar site.
The agent's narrated summary of what it did diverges from the destinations and form fields the underlying browser actions actually touched.

Useful telemetry includes a durable, per-step action log of every navigation, form fill, and click a browsing agent makes, kept separate from the model's own narration of its actions, plus the raw extracted text or OCR output for any screenshot the agent processes, since the injected instruction is often invisible in the rendered page a human reviewer would check afterward.

Defenses, containment, and recovery

The table below is SSA editorial guidance for defenders, not a standard requirement or effectiveness ranking.

| Control | Transition it interrupts | Applicability | Residual risk and verification | | --- | --- | --- | --- | | Instruction/content separation in the browsing prompt | Page content being read as a user instruction | Any agent that feeds extracted page text or screenshots into the same context as the user's request | Requires the browser vendor's own prompt construction to enforce the boundary; an agent built on top of an opaque browsing API cannot add this itself. | | Mandatory confirmation for sensitive actions | Hijacked session state completing a purchase, login, or message send | Agentic browsers with autofill, payment, or account access enabled | Confirmation fatigue reduces effectiveness if every trivial action also prompts; reserve it for actions touching credentials, payment, or account settings. | | Session and capability scoping per task | A single injected instruction reaching every authenticated account in the profile | Agentic browsers used across both sensitive accounts (banking, email) and untrusted browsing (search, shopping) | Narrows blast radius, not the underlying misclassification; verify by testing whether a scoped session still exposes the target account when the injection targets it directly. | | Output-versus-action alignment checking | A narrated summary hiding a divergent underlying action | Any agent whose action log can be compared against its own natural-language description of what it did | Only catches divergence the checker is built to compare; test with an injection payload that keeps the narration and the action superficially aligned. | | Autofill disablement for agent-driven sessions | Stored payment or address data being used without a human present to notice | Agentic browsers completing purchases or form submissions autonomously | Reduces convenience by design; the residual risk is a user re-enabling autofill for a "trusted" agent session that later encounters an untrusted page. |

Prevention should treat every character an agent reads from a page or a screenshot as untrusted content, never as an instruction, regardless of how the content is delivered. Detection should log the agent's actual navigation and form-fill actions separately from its own narration, since the two are the first place a hijack becomes visible. Containment should revoke or rotate any session or credential the agent's authenticated tabs could reach once an injection is confirmed, not only the account the injection appeared to target. Recovery should treat any account the hijacked session touched as requiring re-verification, since a one-time password or session token read mid-attack can enable an account takeover that outlives the browsing task that caused it.

Boundaries with similar concepts

MCP tool poisoning targets a tool's description or a tool call's return value; this working term targets webpage and screenshot content an agent reads directly during autonomous browsing, a different delivery channel into the same broader class of indirect prompt injection. Sandbox configuration escape targets an agent breaking out of its execution environment's isolation; this working term does not require any isolation break, since the agent is using authority the browser already grants it, exactly as designed, on content it should not have trusted. A page that is merely poorly designed or confusing to a human, with no adversarial hidden instruction, stays outside this working term.

Mapping to standards and research

| Source | Source-owned term or item | Relationship to this article | | --- | --- | --- | | Brave (2025-08-20, 2025-10-21) | Indirect prompt injection in Perplexity Comet; unseeable screenshot prompt injection | Documented named vulnerabilities across the visible-text and hidden-text delivery channels; direct evidence for this entry. | | Guardio Labs (2025-08-20) | "Scamlexity" report | Documented autofill and payment-abuse variant, independent confirmation of the same target state. | | OWASP Top 10 for Agentic Applications 2026 | `ASI01 Agent Goal Hijack`; `ASI02 Tool Misuse and Exploitation`; `ASI03 Identity and Privilege Abuse` | Risk categories covering the injected-goal-redirection, capability-misuse, and authenticated-session-abuse aspects of this pattern, without replacing OWASP's own risk descriptions. | | MITRE ATLAS v2026.06 | `AML.T0051.001 LLM Prompt Injection: Indirect`; `AML.T0053 AI Agent Tool Invocation`; `AML.T0086 Exfiltration via AI Agent Tool Invocation` | Attacker-behavior classification for the indirect-delivery and session-abuse chain; a defender-side complement, not an ATLAS-owned mitigation set. | | Agent State Attack | Agentic browser session hijacking | SSA editorial synthesis bundling the above under one target state, not attributed to the sources above. |

Related terms

Agent state attack: the SSA Working Term this article's scope sits under.
MCP tool poisoning: the adjacent tool-and-environment-state entry for the tool-description and tool-result delivery channel rather than direct webpage content.
Sandbox configuration escape: the adjacent execution-environment entry for isolation breakout rather than authorized-session abuse.
OWASP and MITRE ATLAS crosswalk: the broader framework mapping this entry draws its standards references from.

FAQ

Is this the same thing as ordinary indirect prompt injection?

It is the same delivery mechanism, untrusted content read as an instruction, aimed at a specific and unusually valuable target: a browser session that is already authenticated into the user's own accounts. Ordinary indirect prompt injection against a stateless chat agent can distort a reply. Reaching an agentic browser's session state can complete a purchase, read a one-time password, or take over an account, which is why Brave and Guardio both treated it as a distinct finding worth its own disclosure rather than a restatement of the general prompt-injection risk.

Does disabling autofill fully close this gap?

No. It removes the payment and address-abuse path Guardio demonstrated, but Brave's account-takeover chain against Comet required no autofill data at all, only an already-logged-in email session and an agent willing to navigate to it on an attacker's instruction. Autofill disablement is one control among several in the table above, not a substitute for instruction/content separation and mandatory confirmation on sensitive actions.

Can a user just review the agent's summary of what it did afterward?

Not reliably. Brave's screenshot-based finding specifically exploited content invisible to a human reader, so the page a user would look at to check the agent's work does not show the instruction that drove it. Detection needs the agent's actual action log and raw extracted or OCR'd text, not only its own narrated summary, which is the same class of gap the output-versus-action alignment control in the defenses table above is meant to close.

Sources

Verification and change history

Standards and versions referenced: OWASP Top 10 for Agentic Applications, Version 2026 (December 2025); MITRE ATLAS, data release v2026.06 (2026-06-30).

Last verified: 2026-09-08. The Brave publication dates and quoted findings were read from both of Brave's own disclosure posts. The Guardio Labs publication date and quoted findings were read from Guardio's own report page. The OWASP and MITRE identifiers were reused from this site's previously verified crosswalk entry.

Change history: 2026-09-08, initial defensive draft. Not scheduled for publication.

Working-term label: **Mixed provenance.** `ASI01`, `ASI02`, and `ASI03` are OWASP Standard Terms. `AML.T0051.001`, `AML.T0053`, and `AML.T0086` are MITRE ATLAS Standard Terms. "Indirect prompt injection," "unseeable prompt injection," and the Comet findings are Brave research/industry terms. "Scamlexity" is a Guardio Labs research/industry term. "Agentic browser session hijacking" as the umbrella covering the visible-text, hidden-text, and autofill-abuse variants together is SSA descriptive wording, not a standard term.