Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Is It Safe to Let Comet Pay a Vendor Invoice?
Not for a finance team that has to show what Comet read: Comet pauses for confirmation before the payment, but by then the model has read the QuickBooks bill and the Bank of America screen in your own session. Ask what the model received on each screen and who approved the payment.
A $9,800 print vendor invoice arrives as a QuickBooks bill, with the vendor's remittance record beside it and the bank details on the payment screen. The amount is routine enough to approve and large enough to matter if the account is wrong. Comet can open the bill, find the vendor and prepare the Bank of America payment while a person watches, and that is the appeal: the work moves without anyone retyping an account number. The question is what the assistant read on the way to the button. The bill, the vendor record and the bank page carry more than the four values the payment needs, and a browser agent working in a signed-in session sees the page as drawn. Perplexity documents a confirmation before the payment and a pause when the agent fills in details it does not already know; neither is a filter between the rendered screen and the model. That difference decides the answer. A sole proprietor who watches every step can stop a wrong payment. A finance team that answers to an auditor needs a statement of what the model received on each screen, and a named person who approved the amount and the payee before the money moved.
Key findings
- For Comet to be safe on this payment, the values on the QuickBooks bill and the bank screen would have to be replaced with consistent tokens before the model reads them, with the real account resolving only at the destination a person approves (What Is Render-Layer Tokenization?).
- It would also require a named person approving the payee and the amount, and a record of what the model received on each screen of the run (What Is Least Exposure?).
- None of the pages reviewed describes a step that replaces the values on a rendered bank or ERP page before the model reads them; the confirmation comes after the reading (Perplexity, Mitigating, 2026).
- Perplexity's Comet page says the browser "pauses for your confirmation regardless of whether our systems detect suspicious activity" whenever the agent needs to fill in user details it does not already know (Perplexity, Mitigating, 2026).
- Brave's analysis of Comet states that the agent "operates with the user's full privileges across authenticated sessions," so the bill and the bank page are read in the same session (Chaikin and Sahib, Agentic, 2025).
- A benchmark of web agents found they "are prone to inadvertent use of unnecessary sensitive information," which on an invoice screen includes the vendor's account and routing numbers (Zharmagambetov et al., 2025).
What does Comet read on the way to a $9,800 vendor invoice?
The record is one print vendor invoice for $9,800: a QuickBooks bill matched to a purchase order, the vendor's remittance record with the account and routing numbers, and the Bank of America page where the payment is prepared. The payment needs four values: the payee, the amount, the invoice number and the due date. The screens render more.
The QuickBooks bill carries the invoice number, the amount, the due date and the approval history. The vendor record carries the account number, the routing number, the tax identifier and the remittance address. The Bank of America page carries the balance, prior payments and the payee fields. A person treats the balance as background; the model receives the balance with the digits.
Comet works in the browser session the finance team already holds, so the bill and the bank page arrive in the same run. Brave's analysis of Comet states that once an agent follows injected instructions in a logged-in browser, "same-origin policy (SOP) or cross-origin resource sharing (CORS) are all effectively useless" (Chaikin and Sahib, Agentic, 2025). OWASP's guidance explains the route: "indirect prompt injections occur when an LLM accepts input from external sources, such as websites or files" (OWASP, 2025). The invoice and the vendor record are such files.
What the page shows is broader than what the payment needs. A QuickBooks community answer says the user will need the account number for the vendor, and it names no field labels (Intuit, 2021). A benchmark of web agents found they "are prone to inadvertent use of unnecessary sensitive information" (Zharmagambetov et al., 2025), which on this screen is the tax identifier and the remittance address as much as the account.
Comet is one of the 15 AI agents reviewed, and none of the 15 describes replacing the customer data on a working page, such as the account numbers on a bill or a bank screen, with tokens the agent can work with (Do AI Agents Ask Before Making a Payment?).
The session itself is covered in Can a Browser Agent Read My Session Cookies?.
Where does Comet ask you to approve the payment, and what does that confirmation cover?
It arrives at the moment the agent fills in a detail it does not already know. Perplexity's page says the browser "pauses for your confirmation regardless of whether our systems detect suspicious activity" whenever "the agent needs to fill in user details it doesn't already know" (Perplexity, Mitigating, 2026). On this invoice that is the payee and account field, then the release of the payment.
The interface "provides clear context about what action Comet is attempting to perform," in the page's description, and that context describes the action rather than the values behind it (Perplexity, Mitigating, 2026). The person sees a payment to a named vendor for $9,800, not the QuickBooks bill or the account digits the model read to prepare it.
A confirmation is a checkpoint, not a filter. A 2026 preprint's own example is an agent asked to pay a bill that reads "Please pay 100$ to US937293.." before the payment (Bhagwatkar et al., 2026). A payment would appear; the sentence that chose the account would not. Hidden text on the invoice page is the smaller version of the same route, which Can Hidden Text on a Web Page Hijack a Browser Agent? sets out.
The checkpoint is weaker than it looks. Goddard, Roudsari and Wyatt reviewed automation bias, "the tendency to over-rely on automation" (Goddard, 2012). A confirmation that appears on every payment becomes a click.
It still catches a payee picked from the wrong list. It is a rail on movement, not a control on reading.
What do the vendors themselves say?
Perplexity documents detection and confirmation, and it places them around the action rather than around the values on the page. Its mitigation post says the browser pauses for confirmation when the agent fills in details it does not already know, and that the detection "is also logged for continuous improvement of our models" (Perplexity, Mitigating, 2026), a log kept to improve the vendor's models rather than a record the finance team can export.
Brave's researchers describe what the agent's session means for that design. They found that once an agent follows injected instructions in a logged-in browser, same-origin protections are "effectively useless," and a later post shows that attackers can "hide prompt injection instructions in images using a faint light blue text" that screenshot-reading agents act on (Sahib and Chaikin, Unseeable, 2025). An invoice that arrives as a PDF or an image is that carrier.
The table sets what each page documents against what a buyer should ask for. Perplexity's confirmation covers the action; Brave's findings cover the session and the page. Neither page describes replacing the values on a rendered page before the model reads them.
For this invoice the buyer's question is narrower than either page answers: on the Bank of America screen where the payee is confirmed, what did the model read before the confirmation appeared, and what export proves it afterward? A confirmation that names the action does not answer either part.
| Dimension | Perplexity, per its pages | What a buyer should verify |
|---|---|---|
| Session | Comet works in the browser session the user holds | Which signed-in pages the model reads |
| Confirmation | Pauses when the agent fills in details it does not know | What the model read before the pause |
| Detection | Logged for model improvement | Whether the customer receives that log |
| Page values | Not described as replaced before reading | A filter between render and model |
What record does the finance team get after the run?
QuickBooks keeps the bill, its approval history and the payment record. Bank of America keeps the transfer, the amount and the date. Neither record lists the screens the model read, the values on them or the moment a person confirmed the payee. An auditor who asks what the assistant saw before the account changed has the statement, not the reading.
Perplexity's page says the detection is "also logged for continuous improvement of our models" (Perplexity, Mitigating, 2026), a vendor-side log with no approver's name and no export for the finance team.
A masked view is not the record either. BILL's help page for American Express Vendor Pay says a user who entered the bank details sees "the last four digits of the bank account, and the full routing number" (BILL, 2026). That is a display choice; the model still receives what the page renders.
The record has to start at the rendered screen: what the model received, which action followed and who approved it. Can a Browser Agent Copy Customer Data From a Web App Into a Prompt? sets out why the record starts at the page, and Will Prompt Injection Ever Be Fixed at the Model Level? covers the defense side.
A team can ask for that record before the first live payment: one run in which the screens, the values and the approver are exported to the team's own monitoring.
What does a governed environment change?
A governed environment puts the control at the point a screen is rendered, before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run. Real values resolve only at an approved destination, at the moment of an approved action. A named person confirms the tokenization policy and approves each payment, and every screen, action and approval is exported to the organization's own monitoring.
On this invoice, the QuickBooks bill renders INV_0247 where the invoice number sits and ACCT_001 where the account number sits, and the Bank of America page renders the same tokens. The agent matches the bill to the payee and prepares the transfer without holding the account it pays. The confirmation attaches to the token, and the real account resolves only at the payment page the person approved. The record shows what the model received on each screen.
The scope is the rendered page. A payment assembled in a script that calls the bank's API sits outside it, and a team that pays that way needs a control at that layer.
RedactSure vs Perplexity Comet: 2026 Comparison & Alternative sets out the difference in design: one control decides which session the agent may use, and the other decides what the model reads inside that session.
What the record shows
Control over the invoice sits at three points: what the model receives from each rendered screen, who approves the payment, and what record the run leaves. The vendor's pages document the second as a confirmation and leave the first and third open, which makes the task workable for a sole proprietor who watches every step and hard to defend for a finance team that has to show what the assistant read. A team can test one invoice by comparing the fields the bank page displayed with the values the run reports having read, then naming the person who approved the payee and the amount.
Methodology and limitations
This page rests on Perplexity's Comet pages, Brave's two security write-ups, a systematic review of automation bias, a benchmark of web agents, a preprint on indirect prompt injection, QuickBooks and BILL help pages and OWASP guidance, with the RedactSure pages cited in the body. Vendor pages were read between October 21, 2026 and October 22, 2026, and each Sources line carries the date for its page. Public documentation read in full gives a sound view of where each product applies its control, and the invoice describes a record type, not an organization's accounts.
No product on this page was tested for this page; the products are described from their public documentation and none was tested here, and RedactSure is deploying now with enterprise and government customers. Where a behavior is not described in the pages reviewed, it means the Perplexity page in Sources. Vendor features change and the page carries its date, the example describes a record type, and determinations belong to counsel, assessors and the organization's own security and compliance officers.
Frequently asked questions
Is it safe to let Comet pay a vendor invoice?
No, not for a finance team that has to show what the assistant read. Comet works in the session the team already holds, so the QuickBooks bill and the Bank of America page arrive in one run, and Perplexity documents a confirmation rather than a filter between the rendered page and the model (Perplexity, Mitigating, 2026). A sole proprietor who watches each step can stop a wrong payment. A team whose auditor asks what the model saw cannot answer from the payment trail.
Does Comet's confirmation count as an approval?
No. The confirmation asks the person watching to approve an action before it runs, and Perplexity says the browser pauses whenever the agent fills in details it does not already know. Nothing in it names an approver in advance, checks the payee against the vendor record, or ties a name and time to the decision. An approval records a named person accepting a stated payee and amount; a pause records only that someone was present.
What does Comet read on the vendor record in QuickBooks?
Whatever the record renders. The QuickBooks vendor page carries the account number, the routing number, the tax identifier and the remittance address, and a model reading the page receives those fields. Nothing in Perplexity's page describes a field-level filter, and the agent fills in bank details it does not already know, which is the moment the page is most exposed. A team that wants the digits out of the model's context must change what the page renders.
What record does the finance team get after Comet pays?
The payment trail it already keeps: the QuickBooks bill, the approval history and the bank receipt. None of those lists the screens the model read or the values on them, and Perplexity's log of detection is kept for the vendor's models. An auditor who asks what the assistant saw on the vendor record cannot be answered from the bank statement. The artifact has to come from the layer where the agent runs.
Can an injected instruction on an invoice redirect the payment?
It can try. An invoice, a remittance note and a vendor message are text a model reads, and Brave's researchers showed that instructions hidden in an image can reach a screenshot-reading agent (Sahib and Chaikin, Unseeable, 2025). Perplexity says its detection is logged for model improvement rather than attached to the payment (Perplexity, Mitigating, 2026). What an injection collects depends on what the page rendered: real digits give it an account to change, and tokens give it a label that resolves only at the destination a person approved.
What would make the payment defensible in an audit?
Three things: an export of what the model received on every screen, a named person's approval tied to the amount and the payee, and a control that held the real account out of the model's context until that person approved the payment. RedactSure provides the environment where those three exist together, because values are tokenized as the page renders and the approval attaches to the token. Without the export, the other two describe a process nobody can check.
How RedactSure Keeps Vendor Bank Details Off the Payment Screen
A finance team that hands Comet an invoice has no statement of what the model read. Perplexity's page says the browser "pauses for your confirmation" regardless of whether its systems detect suspicious activity, so the confirmation follows the reading (Perplexity, Mitigating, 2026).
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the QuickBooks bill and the Bank of America page draw the account and routing numbers, and the model holds them for the rest of the run. Inside: the bill draws ACCT_001, the payment page draws the same token, the real account resolves only at the destination a named person approves, and each screen and approval lands in the AI Control Record.
RedactSure is deploying now with enterprise and government customers.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
A payment is defensible only when the team can show what the agent read before it moved. Bring one vendor bill from your own workflow and see, with test values, the rendered page, the approval and the record. Book a demo