Fake Merchant & Phishing Attacks
AI shopping agents are completing checkout on fraudulent sites — without the human ever seeing the suspicious domain.
Cybersecurity researchers at Guardio Labs demonstrated a new attack technique called PromptFix that tricked Perplexity's Comet AI browser into auto-filling a user's saved address and credit card details on a fake Walmart storefront that took 10 seconds to set up. The browser went all in: adding the item to cart, filling payment details, and completing checkout, without asking for confirmation. The human never saw the fraudulent domain. In a related variant, the same browser was directed from a spam email to a phishing login page, vouching for the site throughout without a single human touchpoint. Guardio named this new attack class Scamlexity: the collision of AI convenience with an invisible scam surface, where humans become collateral damage.
"With PromptFix, the approach is different: We don't try to glitch the model into obedience. Instead, we mislead it using techniques borrowed from the human social engineering playbook, appealing directly to its core design goal: to help its human quickly, completely, and without hesitation." — Guardio Labs, The Hacker News, Aug 2025
Visa reported a 450% increase in dark web posts mentioning "AI Agent" over a six-month period and a 25% increase in malicious bot-initiated transactions. Fraudsters are no longer optimizing for human SEO. They are optimizing for agentic search: steering AI shopping agents toward scam sites before the human user is ever involved.
The attack surface
Unlike prompt injection, where the agent is on a legitimate site but manipulated by page content, fake merchant attacks work by steering the agent to a fraudulent site entirely. The agent then operates normally, trusting what it sees.
Lookalike storefront
A pixel-perfect Walmart clone at walmart-deals.shop receives full checkout from an agent that never verified the domain
SEO and agentic search poisoning
Search results or agent memory is poisoned to surface fraudulent merchants above legitimate ones
Spam-to-phishing chain
Agent parses a spam email, clicks an embedded link, and enters credentials on a phishing page it navigated to autonomously
PromptFix CAPTCHA injection
A fake CAPTCHA on a fraudulent page contains hidden instructions that cause the agent to click invisible buttons and complete actions without human input
Typosquat domain
amaz0n-deals.com, target-shop.co, or walmrt.com receive payment data from agents that evaluate visual similarity rather than exact domain match
Brand impersonation with SSL
Fraudulent sites with valid SSL certificates and professional design pass LLM-based "does this look legitimate?" checks
Why prompt-based guardrails don't catch this
An LLM-based guardrail evaluating whether a merchant "seems legitimate" can be deceived by the same techniques that fool the shopping agent: good design, valid SSL, a convincing domain name, and social engineering copy. The guardrail and the agent are both language models operating on the same inputs. If the site looks real to the agent, it looks real to the judge.
ICME compiles your merchant policy to formal logic and checks every proposed checkout action against a mathematical solver. The solver does not evaluate whether walmart-deals.shop looks like Walmart. It checks whether walmart-deals.shop is in the approved merchant registry, a binary operation with no room for visual similarity scoring, brand impression, or persuasion. A fake site that is indistinguishable from the real thing to any language model still fails the solver's domain check.
The attack surface shrinks from "everything that looks legitimate to a language model" to "domains that are identical to the approved list", a set with exactly one member per merchant.
The policy
This policy is designed for multi-merchant shopping agents. Unlike a single-merchant policy, it must handle typosquat detection across a registry of approved domains and enforce fail-closed behavior on any domain that cannot be positively identified.
Each rule is written as a simple boolean condition with two consequences -- "not permitted" and "action must be rejected" -- which produces clean boolean variables that the AR solver can evaluate directly. Enum-typed schemas cause AR translation failures; explicit boolean phrasing avoids them.
Save the returned policy_id. Pass it on every checkIt call.
Check every checkout action before it executes
SAT = allowed. UNSAT = blocked. Every decision returns a cryptographic receipt.
Writing action strings: end every action string with "Therefore this purchase is permitted." This gives the AR solver a claim to evaluate. Without it the solver has premises but no conclusion to prove or contradict and may return SAT by default. Every boolean the policy references should be explicitly stated in the action -- do not rely on the extractor to infer missing values.
Live results
SAT: legitimate purchase -- exact match approved merchant
UNSAT: lookalike storefront -- fraudulent Walmart clone (Scamlexity / PromptFix scenario)
SSL certificate validity and brand appearance are not variables the solver evaluates. Only checkoutDomainInApprovedRegistry matters. A pixel-perfect Walmart clone fails on the same condition as a blank page at an unknown domain.
UNSAT: typosquat domain -- one character off approved merchant
UNSAT: spam-to-phishing chain -- agent navigated from email link
The checkout domain passes the registry check here -- this is the scenario where the agent lands on a convincing phishing page at a domain it cannot immediately identify as fraudulent. The navigationOriginatedFromEmailLink variable blocks it regardless.
UNSAT: PromptFix -- hidden CAPTCHA instructs agent to complete checkout
Note: purchaseInstructionFromPageContent: true is extracted correctly and the LLM returns UNSAT. The AR solver returned SAT on this test -- a known gap being investigated. The final result is still UNSAT via LLM enforcement.
UNSAT: domain substitution between navigation and payment
UNSAT: brand impersonation with SSL
Note: checkoutDomainInApprovedRegistry: false is extracted correctly and the LLM returns UNSAT. The AR solver returned SAT on this test -- a known gap being investigated. The final result is still UNSAT via LLM enforcement.
Reading the extracted variables
Every checkIt response includes an extracted map showing exactly what the solver evaluated.
checkoutDomainInApprovedRegistry
True only if the checkout domain is an exact string match to an entry in the approved merchant registry
checkoutDomainIsTyposquat
True if the checkout domain visually resembles an approved merchant domain but is not an exact match
navigationOriginatedFromEmailLink
True if the agent reached the current page by following a link in an email
paymentDomainMatchesCheckoutDomain
True if the domain receiving payment credentials is the same domain the agent navigated to
purchaseInstructionFromDirectUserPrompt
True if the instruction to purchase came directly from the user
purchaseInstructionFromPageContent
True if the instruction originated from page content -- a CAPTCHA, hidden element, product description, or any on-page source
Why two separate checkIt calls matter
checkIt calls matterThe Comet attack chain has two steps: the agent navigates to a page, then submits payment. A single guardrail check at purchase time misses the case where the agent is legitimately browsing but is then redirected to a fraudulent payment endpoint mid-flow. Calling checkIt separately for navigation and payment submission, and explicitly stating whether paymentDomainMatchesCheckoutDomain in the payment action, closes the gap that makes the Scamlexity attack class possible.
Deploying in production
Compile once -- call makeRules with your policy. Store the policy_id in your environment.
Check navigation and payment separately -- call checkIt before any checkout page navigation and again before any payment credential submission. Verify domain continuity between the two calls by explicitly stating paymentDomainMatchesCheckoutDomain in the payment action string.
Treat result: UNSAT as a hard stop -- do not retry, rephrase, or accept visual legitimacy signals as an override. Log the check_id for your audit trail.
Fail closed -- if the ICME API is unreachable or returns anything other than an explicit SAT, do not proceed with the transaction. An unavailable guardrail is not implicit permission.
Last updated