Zscaler researchers have found malicious websites using hidden instructions, search-engine manipulation, and structured metadata to steer web-browsing AI agents toward fraudulent actions, including a test case where several models followed prompts that led to a crypto-payment flow.
The July 2 ThreatLabz report is notable because it moves indirect prompt injection out of the thought-experiment bucket. The campaigns Zscaler analyzed did not require access to a model provider or a user’s account. They used ordinary web content: SEO-heavy pages, hidden CSS blocks, JSON-LD schema, typosquatted domains, and payment instructions that an autonomous agent might treat as part of the task it was trying to complete.
How the Payment Scam Worked
One campaign posed as API documentation for a fake Python library called requests-secure-v2. The page was built to rank for package-installation and dependency-troubleshooting searches, increasing the chance that a coding agent looking for help would land on it.
The visible page resembled developer documentation, but Zscaler found hidden instructions embedded in the page’s DOM. One off-screen CSS element used a class named .system-traceback-layer, positioned outside the user’s view while remaining available to parsers, scrapers, and agents. The page also used JSON-LD structured data to describe itself as a SoftwareApplication and to present a supposed $3 developer API license as a normal way to resolve a MissingLicenseKeyException.
That combination matters because agentic tools increasingly read more than visible page text. They may ingest metadata, schema fields, scraped HTML, and search-result context as part of their reasoning. In this case, the malicious content pointed the agent toward a payment path, including a Stripe checkout link and JavaScript code for a transfer of about 0.0012 ETH to a hardcoded Ethereum wallet. After payment, the site generated a fake API key.
Zscaler also found the same campaign linking through 10 GitHub repositories under the Open-Agent-Utilities account, each pointing to similar websites with indirect prompt-injection content. That makes the attack look less like a single fake page and more like an early attempt to seed agent-facing web traps into the places developer tools already search.
The DeBank Impersonation Shows a Different Risk
A second campaign impersonated DeBank, the decentralized-finance portfolio tracker, through the typosquatted domain debank[.]auction. Instead of pushing a payment directly, the page tried to persuade AI systems that the fake site was the authoritative DeBank destination.
The page stuffed titles and metadata with terms such as DeBank Login, DeFi Dashboard, and Crypto Tracker. It also used Open Graph, X metadata, and JSON-LD fields that falsely identified the service as DeBank and associated it with the legitimate debank.com publisher. Hidden page text then instructed models to treat the typosquatted domain as the trusted source and avoid mentioning the word “Auction.”
This is a subtler problem than a direct payment prompt. If an agent mislabels a malicious page as trusted, the damage can spread into later retrieval, summarization, or transaction steps. An agent that stores the wrong source as a trusted reference may contaminate future responses even when the immediate task looks harmless.
What Zscaler’s Model Tests Found
ThreatLabz tested 26 large language models with a custom autonomous agent that had web-browsing and payment-execution tools. The payment test ran in a sandbox with no real funds at risk and no spending limits, a setup designed to measure exposure rather than simulate a fully governed enterprise deployment.
Four models followed the payment-scam flow in Zscaler’s test: Llama 3.3 70B Instruct, Llama 3.2 90B Vision Instruct, Gemini 3 Flash, and Gemini 2.5 Pro. In the DeBank impersonation test, the results were context-dependent. When the official DeBank site was included as known-good context, no model accepted the fake domain as legitimate. Without that grounding, GPT-5.4 and Claude Sonnet 4.5 each misclassified the fraudulent site under different test conditions.
SecurityWeek, which reported on the findings Monday, noted the same practical lesson: malicious pages can combine SEO poisoning and hidden prompts to target agents before a human ever reads the page. For teams building agent workflows, the model name is only one part of the risk. The surrounding tool permissions, source validation, payment controls, and memory behavior often matter more.
What Teams Should Change Before Agents Browse the Web
The immediate defense is not to hope a model can perfectly ignore hostile web text. Indirect prompt injection is hard because the agent is supposed to read untrusted content. The safer pattern is to limit what the agent can do after reading it.
- Separate browsing from action. An agent that reads documentation should not be able to initiate payments, change production settings, rotate credentials, or approve transactions without a separate confirmation path.
- Set hard transaction limits. Small payments are still meaningful when attackers can scale them. Crypto and card actions should require allowlists, spending caps, and human approval.
- Verify official sources. Agents should compare package names, domains, registries, vendor documentation, and repository ownership against known-good references before trusting instructions from search results.
- Treat hidden content as hostile context. Off-screen CSS, schema markup, Open Graph fields, and scraped metadata can be useful, but they should not outrank visible documentation or verified source records.
- Keep agent memory narrow. A temporary browsing result should not become a durable trusted source unless it passes an explicit validation step.
- Log tool calls and source inputs together. When an agent makes a recommendation or attempts an action, teams need to see which page, metadata field, hidden block, or retrieved snippet influenced the decision.
The Zscaler examples are early, but they point to a durable security problem. As AI agents become a front end for browsers, coding tools, procurement systems, finance workflows, and customer-support platforms, the open web becomes part of the attack surface. A malicious page does not need to exploit a browser bug if it can convince the agent operating the browser to do the work for it.
