Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
What Did the Comet Prompt Injection Exploit Expose?
The 2025 Comet exploit showed a web page directing the assistant and the assistant acting inside the user's signed-in session, which put the records that session could reach in front of whoever wrote the page. Ask what the model reads before it acts, who approves the action and what record the run leaves.
A browser stays signed in to a payment portal, a mailbox and a document store, the ordinary setup for an assistant and the setup an injected page needs. The page does not have to break the browser; it only has to be read. The 2025 Comet research is the clearest public record of what follows, because the researchers did not need a stolen password or a malicious extension, only a page the assistant would open with the user's session already live (What Is the Lethal Trifecta for AI Agents?). The practical question is what that session can reach once a page gives an instruction, and whether anything limited what the model was shown before it acted. A remit-to account on a payee screen makes the stakes concrete: it is a value a person updates by hand, an agent can be asked to update it, and a change is worth money to whoever can make one. A security review has to answer both in writing, because detection improves from release to release while the data a run can reach stays the same until the screen changes.
Key findings
- For an assistant to keep the session out of an attacker's hands, the values on the rendered page would have to be replaced with consistent tokens before the model reads it, so an instruction copies ACCT_001 rather than the remit-to account (What Is Render-Layer Tokenization?).
- It would also require a named person approving each outbound action and a record of what the model received, so the real account number resolves only at the approved destination (What Is the Lethal Trifecta for AI Agents?).
- Perplexity's account of its mitigation describes detection, logging and a confirmation prompt, and does not describe replacing the values a page shows before the model reads it (Perplexity, Mitigating, 2026).
- Brave's researchers report that once an agent follows an instruction in a page, "same-origin policy (SOP) or cross-origin resource sharing (CORS) are all effectively useless," because the agent holds the session (Chaikin and Sahib, 2025).
- A web-agent benchmark found agents begin following injections in up to 86% of cases, though "even state-of-the-art agents often struggle to fully complete the attacker goals" (Evtimov et al., 2025).
- An environmental injection study reports hidden page elements let attackers take user data, with "EIA achieves up to 70% ASR in stealing specific PII" (Liao et al., 2025).
What did the Comet prompt injection exploit demonstrate?
The demonstration was a page-level instruction, not a compromised account. Brave's researchers describe what happens once an agent follows instructions planted in a page in a logged-in browser: "same-origin policy (SOP) or cross-origin resource sharing (CORS) are all effectively useless" (Chaikin and Sahib, 2025). The attacker never holds the password; the session supplies the access, and the credential-theft record has the same shape (How Do Attackers Steal Credentials Through Prompt Injection?).
The three parts are the lethal trifecta: access to private data, exposure to untrusted content and a way to send data out. A browser assistant holds all three by design: the session that reads the page can also open the mailbox, the invoice portal and the payee record.
The record type this page uses is a vendor bank details screen, the page where a payee's remit-to account is entered. A QuickBooks community answer walks a person through it: "To set up a vendor with open bills, select Set up Bank Transfers within the same line as the Payee," and it adds that "You'll need the account number for the vendor" (Intuit, 2021). Against that screen the exposure stops being abstract: an instruction can point at the field that decides where money goes, and the session makes the save possible.
What could an injected instruction read with the session open?
The model receives the page as the session renders it, which is the whole difficulty. On a payee screen that means the account number, the vendor name, the invoice references and any note a colleague left, because those are the fields the page draws. OWASP's definition covers the delivery route: "Indirect prompt injections occur when an LLM accepts input from external sources, such as websites or files" (OWASP, 2025). Hidden page elements stole specific personal data in up to 70% of tests, which is the mechanism the Comet exploit showed at the page level (How Often Do AI Agents Follow Injected Instructions?).
A page can also carry instructions a person would never see. The environmental injection study places them in hidden elements and reports that "EIA achieves up to 70% ASR in stealing specific PII" (Liao et al., 2025). A reviewer who reads the visible page therefore has not read what the model reads.
The exit can be quiet. In the EchoLeak disclosure, the client "automatically fetches the external image URL included by the attacker" (Reddy and Gujral, 2025), so a rendered image can carry data out with no click. The same-origin boundary that keeps one site from reading another does not sit between the model and the session it borrowed, the boundary the enterprise browser category argues about (Enterprise Browser or Render-Layer Tokenization?). The browser is doing what it was built to do, which is why the fix has to sit in what the page hands the model.
What do the vendors themselves say?
Three vendor pages bear on this question, and each describes a control around the action rather than a limit on what the model reads.
| Dimension | Perplexity, per its pages | What a buyer should verify |
|---|---|---|
| Detection | "If something looks unsafe, Comet doesn't move forward blindly or fail silently" (Perplexity, Mitigating, 2026) | What the detector covers, and whether its verdict is logged with the run |
| Confirmation | "Comet pauses for your confirmation regardless of whether our systems detect suspicious activity," for actions where the agent fills in details it does not already know (Perplexity, Mitigating, 2026) | Which actions count as filling in details, and what the confirmation shows |
Microsoft's account of its own defenses draws the same line. For markdown image exfiltration it took "steps to deterministically block the security impact," and for what remains "we rely on the explicit consent of the user to perform a specific action" (Microsoft, 2025). Consent is a decision about an action, and the instruction was read before the person was asked.
Brave's research names the constraint the vendor pages leave implicit: once an agent follows an instruction in a logged-in browser, "same-origin policy (SOP) or cross-origin resource sharing (CORS) are all effectively useless" (Chaikin and Sahib, 2025).
What did Perplexity change, and what does it still leave the model to read?
Perplexity's published mitigation adds three things: a detector that stops an unsafe step, a confirmation for actions where the agent fills in details it does not already know, and a log of the detection (Perplexity, Mitigating, 2026). The controls sit above the action, and they leave a record that a check happened.
What they do not change is the reading. A confirmation is a decision about an action, so it arrives after the model has read the page and decided what to propose. A person can decline the action. The account number on the page has already been in the model's context, and a page that hid its instruction in a hidden element never showed the person the text the model read. A confirmation shows the action, and the page behind it stays outside the person's view; a record of what the model read is the only thing that closes that gap.
The research record explains why better detection does not close it. Protections reduce risk without removing it, the conclusion the model-level review sets out (Does a Smarter Model Stop Prompt Injection?), and the standard guidance asks for least privilege rather than a perfect filter (OWASP, 2025). Least privilege narrows where the session may go; it does not change what the page shows when the model arrives.
What should a security team ask for in writing before an agent reads a page?
The answers differ by product, and a demo answers none of them. First: what does the model receive from a rendered screen, and is any value on that screen replaced before the model reads it? A vendor that answers with a detector, a blocklist or a confirmation has answered a different question: each acts on where the agent goes, not on what it reads.
Second: who approves an outbound action, and can the approver see the values the model saw? Third: what record exists of the run, and does the customer hold it? FINRA's 2026 oversight report supplies the regulator's version of both questions: agents may act "beyond the user's actual or intended scope and authority," and "Complicated, multi-step agent reasoning tasks can make outcomes difficult to trace or explain, complicating auditability" (FINRA, 2025).
Fourth: what happens to the value after the action? A confirmation screen that shows the account number again puts it back in front of the model unless the rendered value is the token. Ask for the answers in writing, and test them on one screen before trusting the reply.
The questions about a rendered screen are the ones most often left unanswered (What Is the PII Wall?). A review of one browser agent reaches the same test from a different direction (Is Claude in Chrome Safe to Use for Work?).
What does a governed environment change?
A governed environment moves the control to the point where the page is drawn. Values chosen by policy are replaced with consistent tokens for the whole run, so the model works on ACCT_001 in the payee field. Real values resolve only at an approved destination, at the moment of an approved action, so the save that changes the remit-to account carries the number the approver saw named. A named person approves each consequential action, and every screen as the model saw it, every action and every approval is written to a record that exports to the organization's own monitoring.
It changes two things the alternatives above leave open. The instruction still arrives, because no control at the render layer promises that a page will never contain one; what it collects is a token, and the token is worthless outside the environment that issued it. Detection can improve after the fact; the rendered value is the one thing on the page that does not depend on the detector being right.
Its scope is the rendered page. It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP. The comparison for this page's vendor applies the same test to the agent's own controls (RedactSure vs Perplexity Comet: 2026 Comparison & Alternative).
What the record shows
Exposure is set before any action is confirmed: by the values the rendered page carries, by the permissions the session brings to it, and by whether an instruction on that page can direct a save. A page the assistant read could give it an instruction, the signed-in session gave that instruction reach, and the outbound action was where the result would land. Perplexity's pages describe a detector, a logged check and a confirmation before an action proceeds, and they do not describe the model being shown a token instead of the account number the page carries, which leaves the confirmation as the last gate rather than the first. A security review can run the test on one screen and one save: note which field holds the remit-to account, and compare what the model read with what the approval named.
Methodology and limitations
This page rests on three research papers on web-agent injection, vendor documentation from Perplexity, Brave and Microsoft, OWASP's prompt injection entry, FINRA's 2026 oversight report and a vendor community answer for a payee screen, plus existing RedactSure research pages. Public documentation read in full gives a sound view of where each product applies its control. Vendor pages were read between October 21, 2026 and October 22, 2026, and each Sources line carries the date for its page.
No product on this page was tested for it. "Not described in the pages reviewed" means the pages listed in Sources. Vendor features change, and the page carries its date. The example describes a record type, a payee screen, not an organization. RedactSure is deployed with enterprise and government customers. Determinations about whether a workflow meets a regulatory, contractual or audit requirement belong to counsel, assessors and the organization's own security and compliance officers, and nothing here replaces a pilot of one workflow on the organization's own screens.
Frequently asked questions
What did the Comet prompt injection exploit expose?
It exposed a sequence rather than a single bug: a page can carry an instruction the assistant follows, the signed-in session gives that instruction reach across the sites the person uses, and the outbound action carries the result. The data at risk is whatever the session can display on the pages the agent opens, including a payee's account number. None of the three parts is exotic; each is ordinary browser behavior.
Does the confirmation step stop the injection?
No. Confirmation decides whether a proposed action proceeds, and it arrives after the model has read the page and chosen what to propose. Perplexity's description ties it to actions where the agent fills in details it does not already know, which is a narrower set than every action that moves data (Perplexity, Mitigating, 2026). A page that hid its instruction in a hidden element never showed the person the text the model read, so approving the action approves a decision made on unseen input.
Does the exploit need a malicious extension or a stolen password?
No. The delivery is the page itself. Brave's researchers describe the agent operating with the user's full privileges across authenticated sessions, which is why the same-origin boundary does not contain it (Chaikin and Sahib, 2025). A page the person would open anyway carries the instruction, and the session the assistant already holds supplies the access. An extension blocklist and a password rotation do not touch that path.
What can an attacker take from what the model reads?
Anything the pages show while the run is live: an account number, an invoice reference, a customer record, a verification code displayed on a screen. The model does not need to understand that a value is sensitive; it needs only to place it where the instruction says, which is why the measure of exposure is what the page rendered. A hidden element can carry that instruction, and the person reviewing the visible page never sees it.
What record would show what the agent read?
Only a record built at the point the page rendered: which screen the agent opened, which values were replaced before the model saw them, what action it proposed, and which named person approved. A detection log is not that record, because a check that fired says nothing about the account number the confirmation displayed. Ask for the record in the customer's own monitoring, not a vendor dashboard.
What should a security team ask a vendor in writing?
Five answers: what the model receives from a rendered screen, whether any value is replaced before it reads the page, who approves an outbound action, what the confirmation covers, and where the record lives. A detector or a blocklist describes where the agent may go, not what it read. Treat each answer as provisional until one workflow runs with test values.
How RedactSure Keeps a Page Instruction Away From the Session
Detection and confirmation arrive after the page is read, so neither changes what the instruction already put before the model.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the instruction sits in the page, the model reads the payee's account number with the session open, and the save carries the value the instruction chose. Inside the governed environment: the account number renders as ACCT_001, the instruction arrives with only the token, and the real value resolves at the payee screen a named person approved.
RedactSure is deploying now with enterprise and government customers. The agent in the Brave research held the user's full privileges across authenticated sessions, the reach a token removes.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
A page instruction can move a payment, and the run that read it is the only place the change shows. Bring a payee screen and see, with test values, what the model reads and who approves the save. Book a demo