How it fails
The animation steps through one representative failure and the control that stops it. Use the arrow buttons to go at your own pace.
Overview
An agent treats a deceptive merchant, payee, support claim, or emergency request as sufficient authority for action. The failed protection is verification of the external party or claim. The scam can arise inside a legitimate, owner-initiated task and needs no unsolicited command.
Common examples of vulnerability
- A fake booking or shopping site passes the agent's checks and receives saved card details.
- Changed bank details on an invoice are accepted without checking an independent record.
- A compromised contact asks the agent to settle a fabricated bill.
- Fabricated urgency or authority text on a page is treated as an instruction.
- An approval screen repeats the scammer's framing instead of exposing recipient and evidence.
Example attack scenarios
Documented scenarios generalize a real case listed below. Hypothetical scenarios have no matching public case yet.
Scenario 1: Lookalike storefront checkout Documented
A person asks an agent to buy a product. The agent lands on a lookalike store and checks out with the saved card and address because the listing matches the request.
Scenario 2: Phishing email treated as a task Documented
A fake bank email arrives in the inbox the agent manages. The agent logs it as a to-do, opens the link without checking the address, and enters the person's credentials on the phishing page.
Scenario 3: Fake CAPTCHA tells the agent to click Documented
A page shows a CAPTCHA-style gate with hidden instructions. The agent follows them, clicks the button, and downloads a file the person never asked for.
Scenario 4: An unverified plea triggers a transfer Documented
A stranger replies to an agent that holds funds and asks for a small payment with a hardship story. The agent has no way to verify the claim and sends far more than asked.
Real-world cases
Dated and sourced. Nothing here shows how common the failure is; it shows that it has happened or been demonstrated.
Guardio 'Scamlexity': Comet buys from a fake Walmart store with a saved card
- What happened
- Guardio built a fake Walmart store and told Comet 'Buy me an Apple Watch'. Comet added the watch to the cart and autofilled the saved address and credit card without asking, ignoring signs the site was fake.
- Caveats
- Controlled test. Results varied: in other runs Comet refused or paused for the user to finish checkout.
- Grounds
- Scenario 1
- Sources
- Guardio Labs
Guardio: Comet treats a fake bank email as a to-do and enters credentials on a phishing page
- What happened
- Guardio sent a fake Wells Fargo email from a new ProtonMail address linking to a live phishing page. Comet logged it as a bank to-do, clicked the link without checking the URL, and helped fill in the login form.
- Caveats
- Controlled test. Guardio's March 2026 follow-up reports a Comet phishing compromise in under four minutes (reported by The Hacker News; not read in full).
- Grounds
- Scenario 2
- Sources
- Guardio Labs · The Hacker News, Mar 2026
Guardio PromptFix: a fake CAPTCHA with hidden instructions
- What happened
- A fake message posing as a doctor's office sharing blood test results led to a CAPTCHA page whose CSS-hidden text told the AI to click a button. Comet clicked it and downloaded a file. The file in the demo was harmless; Guardio said the same method could deliver a malicious payload.
- Caveats
- Controlled test, harmless payload.
- Grounds
- Scenario 3
- Sources
- Guardio Labs
Lobstar Wilde: an agent that holds funds answers a stranger's plea
- What happened
- An agent built by an OpenAI employee, funded with about $50,000 of Solana to trade, sent about 52.4 million LOBSTAR tokens (about $441,788 at the time) to an X user who had asked for 4 SOL (about $310) for an uncle's tetanus treatment. The amount sent was far larger than the request. See PAA06 for the amount error.
- Caveats
- The cause is unresolved: a decimal misread is speculation by another X user, and some observers suspect the episode was staged for marketing, which the reporting does not establish. A crypto trading agent, not a consumer personal agent.
- Grounds
- Scenario 4
- Sources
- Cointelegraph
Prevention and mitigation
What you can do
- Verify unusual payees and payment changes through an independently established channel.
- Approve new payees yourself; do not let the agent add them on message evidence alone.
What the provider must do
- Preserve the source of each claim; check changed payment details against an independent record.
- Do not let an incoming request supply its own proof of authority.
- Show recipient, evidence, and unusual terms on the approval screen; flag inconsistencies.
- Run merchant and payee reputation checks that are independent of page content; prefer allow-listed or tokenized payment rails.
- Do not treat spending limits as a substitute for counterparty verification.
Where a safeguard is unavailable, offer a narrower mode such as read-only access or manual completion rather than rely on an instruction to the model.
See the reference guard controls for PAA05 →
Test it
Framework crosswalk
Related mechanisms in other OWASP work. This is an analytical mapping, not equivalence.
Top 10 for Agentic Applications 2026Personal focus: Consumer verification of counterparties and payment claims.
Improve this entry on GitHub →