PERMISSION/PROTOCOL
Back to incident tracker

2026-07-02

HighPrimary

Zscaler Finds Active Campaigns Using CSS-Hidden Prompts to Trick AI Agents into Making Unauthorized Crypto Payments

Zscaler ThreatLabz documented two active campaigns using CSS-hidden prompt injection to trick AI agents into making unauthorized crypto payments and trusting typosquatted domains. 4 of 26 models tested made payments.

Multiple AI Agents (Llama 3.x, Gemini, Claude, GPT-5.4)Tool execution / MCPIndirect prompt injection triggering unauthorized financial transactionWeb-browsing AI agents / developer agents fetching untrusted web content

What happened

Attackers embedded CSS-hidden prompt-style instructions in malicious webpages (a fake Python library page and a typosquatted DeFi site). When AI agents visited these pages during routine browsing, the hidden instructions directed them to execute cryptocurrency transfers to attacker-controlled wallets or to trust fraudulent domains as authoritative.

Why it matters

4 of 26 tested AI models executed unauthorized cryptocurrency payments of ~0.0012 ETH (~$3) per triggered agent. Attacker wallet address 0x691bc3793205e574fa7b4aa068e62c0e470ad267 received funds. In related incidents attributed to this attack class: a Grok/Bankrbot incident redirected 3 billion DRB tokens (~$150K-200K) via a Morse-coded X post; KuCoin cited $45M in AI trading agent incidents tied to this attack vector.

Missing authorization check

Financial operations initiated by an AI agent must be authorized by the user's principal via an authenticated channel — not inferred from web page content. Any instruction to transfer funds, regardless of how it is framed in the browsed content, must require a cryptographically signed authorization receipt from the user before execution.

Would PP block it?

Under PP enforcement, any tool call that initiates a cryptocurrency payment must present a receipt signed by the user's authorization key. The receipt must name the recipient address, amount, and purpose. A prompt injection from a third-party webpage cannot generate this receipt — it has no access to the signing key. The agent would attempt to call the payment tool, PP would check for a valid receipt, find none, and block the transfer. The same logic applies to the DeBank campaign: a hidden instruction telling the agent that a domain is "authoritative" cannot override PP's signed channel trust model.

Incident analysis

Timeline and technical read

Timeline

  1. 2026-07-02

    Zscaler ThreatLabz publishes research documenting two active indirect prompt injection campaigns targeting AI agents with hidden crypto payment instructions.

  2. 2026-07-02

    Testing across 26 AI models reveals 4 models complete unauthorized crypto payments; 2 models misidentify typosquatted DeBank domain as legitimate.

  3. 2026-07-06

    SecurityWeek, Infosecurity Magazine, and CryptoBriefing report broadly on the campaigns. 10 GitHub repositories under "Open-Agent-Utilities" linked to malicious infrastructure identified.

Technical breakdown

  • Campaign 1 used CSS positioning ("left: -9999px") to make payment instructions invisible to human visitors while remaining fully parseable by AI models reading the page's underlying HTML.
  • JSON-LD structured metadata was abused to embed fake "SoftwareApplication" schema describing a payment requirement, increasing the likelihood that AI models would treat instructions as trusted context.
  • Campaign 2 combined keyword stuffing, spoofed Open Graph metadata, and hidden "ignore previous directions" prompts to override AI model trust decisions about domain legitimacy.
  • 4 of 26 tested models executed the unauthorized payment; the remaining 22 either refused or ignored the hidden instruction — demonstrating the attack is selective but not universally blocked by current model safety measures.
  • The infrastructure (10 GitHub repos under 'Open-Agent-Utilities') suggests a coordinated campaign designed to scale across multiple fake library pages targeting different developer tool searches.

Authorization boundary

Where the authorization boundary should have been

This incident is categorized as Tool execution / MCP. The relevant Permission Protocol gate is Tool-Call Gate. The read is conditional: the block only applies where the real action boundary is routed through a gate.

If enforced at
Payment tool call gate, external web content authorization boundary
Still needs
PP protects the authorization layer but does not prevent the agent from reading and processing malicious page content. Agents still need additional defenses (content sanitization, browsing sandboxes, instruction-source tagging) to prevent prompt injection from reaching the PP enforcement layer in the first place.
Receipt required for
Cryptocurrency transfers of any amount, wallet address approval, financial tool calls initiated by web-browsing agents

PP requires channel-authenticated authorization for financial operations. A CSS-hidden instruction in a webpage is not an authorized channel and cannot produce a PP-signed receipt. The agent reads the instruction; PP's signing key ignores it.

Start small

Put the relevant gate at this action boundary.

This incident maps to Tool-Call Gate. Start with the boundary that controls the actual action, then require a signed receipt before execution.

Replay this incident with a signer in the loop