The campaign supplied one presentation for people and another for automated readers. A page resembling software documentation contained structured or hidden instructions that tried to turn an agent’s need to finish a task into a reason to make a cryptocurrency payment. The requested action was not authorized simply because the page described it as a…
Inspect the ClaimsCase · DiggingBeagle record
Hidden web instructions induced AI agents to execute a fake crypto payment flow
Zscaler found live scam pages carrying hidden instructions for AI agents, then tested a fake payment flow in a sandbox. Four of 26 tested models triggered the payment action, but the experiment used no real funds.
Public disclosure: Jul 2, 2026
Scope
ThreatLabz observed malicious IPI-enabled websites operating as real scam infrastructure. The specific result in which four of 26 LLMs executed cryptocurrency payments was produced in ThreatLabz's controlled sandbox with no real funds at risk and must not be represented as four real-world victim payments.
Assessment profile
Assessment method- Setting
- evaluation
- Exploitation
- demonstrated
- Impact
- Band 2 of 4
- Evidence
- Grade B
- Remediation
- mitigation available
- AI role
- AGAINST AI
Basis and provenance
The assessment refers to ThreatLabz’s controlled experiment. Live scam infrastructure and the four-of-26 mock-payment measurement have different scopes; no production payment victim count is established.
Impact basis: A sandboxed agent crossed into a fraudulent payment action under the tested permissions. No real funds were used, so this band does not represent a confirmed monetary loss.
Assessed Oct 1, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-ZSCALER-IPI-FOUR-OF-26 · CLM-ZSCALER-IPI-ETH-PAYMENT · CLM-ZSCALER-IPI-HIDDEN-INSTRUCTIONS · Indirect Prompt Injection in Web Content Targets AI Agents
At a glance
## Related mechanisms Comet and Opera Neon demonstrated account-data actions after hostile page instructions. This experiment changes the target action to a mock payment. The common pattern is instruction-driven use of delegated authority, while the different tools and setups prevent merging their outcomes into a single prevalence figure. ## Web3 context…
Read the implicationsThe Source does not establish how many users or autonomous agents encountered the malicious websites outside ThreatLabz testing. The four successful AI-agent payment executions occurred in a fully sandboxed environment with no real funds at risk. The cited wallet had received other payments, but the Source does not establish which payments, if any, were…
Limits and uncertaintyFull account
The campaign supplied one presentation for people and another for automated readers. A page resembling software documentation contained structured or hidden instructions that tried to turn an agent’s need to finish a task into a reason to make a cryptocurrency payment. The requested action was not authorized simply because the page described it as a prerequisite.
What the research observed
ThreatLabz reported malicious infrastructure operating on the public web. It then evaluated the instructions using an agent setup with browser and payment capabilities and deliberately no spending limits. That permission choice is part of the result, alongside the absence of real funds. The record must keep those two evidentiary settings separate: finding a live page establishes distribution of the lure, while a sandbox run establishes a result under the tested tool permissions and prompts.
From documentation to a payment instruction
The lure described a supposed developer-license requirement and supplied a cryptocurrency payment flow followed by a fake API key. That structure attempted to make a financial action appear necessary to complete an ordinary technical task. The authority transition was therefore from reading untrusted documentation to using a payment-capable tool, rather than a documented exploit of a blockchain consensus mechanism or a wallet’s cryptography.
What the numbers mean
The four-of-26 result describes models that caused the test agent to execute the fraudulent payment action. No real funds were at risk in that experiment. The denominator is not the number of ordinary users exposed to the live sites, and it is not an estimate of successful theft across all agents. Other activity involving a campaign wallet cannot be attributed to this agent flow without additional evidence.
Why the wallet boundary matters
A spending limit would constrain maximum loss in a real deployment but would not establish that the destination was legitimate. A separate authorizer needs the intended recipient, asset, amount, network and purpose rather than a generic instruction to proceed. An agent that can approve its own interpretation of hostile documentation has not created an independent check.
Practical interpretation
The demonstrated failure combines untrusted task instructions with a powerful tool. Reducing one model’s susceptibility is useful, but a durable control must also limit when the payment tool can be called and what the call can authorize. This is a proposed architecture lesson; the experiment does not prove a universal bypass of all payment approvals.
Mechanism and trust boundary
- 01
Encounter a convincing technical page
Live scam infrastructure presents material to users and automated readers.
- 02
Treat a payment as a task prerequisite
Hidden or structured instructions describe a fake developer-license flow.
Boundary: untrusted documentation / task instructions
- 03
Reach the payment-capable tool
The sandbox tests whether the agent turns the page’s request into an action.
Boundary: model plan / spending authority
- 04
Record a simulated outcome
Four of 26 tested models triggered the action; this was not four real victim payments.
Claims & evidence
CLM-ZSCALER-IPI-FOUR-OF-26In ThreatLabz's sandboxed evaluation, four of 26 tested LLMs caused the autonomous agent to execute the fraudulent payment action; the test used no real funds.supported
Basis: reported finding
- supportsIndirect Prompt Injection in Web Content Targets AI Agentsprimary disclosure
Assessing the IPI Threat, Campaign 1, paragraphs describing the sandbox configuration and 26-model evaluation including Figure 16
CLM-ZSCALER-IPI-ETH-PAYMENTThe malicious site contained instructions and JavaScript for transferring approximately 0.0012 ETH to a hardcoded wallet and then generating a fake API key.supported
Basis: reported finding
- supportsIndirect Prompt Injection in Web Content Targets AI Agentsprimary disclosure
Campaign 1: IPI Payment Scam, Figure 7 and paragraph describing the approximately 0.0012 ETH transfer and fake API-key generation
CLM-ZSCALER-IPI-HIDDEN-INSTRUCTIONSThreatLabz observed a fake Python-library documentation site using JSON-LD and CSS-hidden content to present payment instructions to AI agents while keeping the injected instructions hidden from ordinary visual presentation.supported
Basis: reported finding
- supportsIndirect Prompt Injection in Web Content Targets AI Agentsprimary disclosure
Campaign 1: IPI Payment Scam, Figures 4-6 and surrounding paragraphs describing JSON-LD and CSS-hidden instructions
Implications
Related mechanisms
Comet and Opera Neon demonstrated account-data actions after hostile page instructions. This experiment changes the target action to a mock payment. The common pattern is instruction-driven use of delegated authority, while the different tools and setups prevent merging their outcomes into a single prevalence figure.
Web3 context and conclusion
EIP-1193 distinguishes a page-exposed Provider from wallet key and account management. A request reaching a provider is not evidence that the user intended it or that a wallet should approve it. Keep message interpretation, permission to request, and final transaction authorization separate. A real deployment that combines untrusted browsing and unattended spending would make this boundary more consequential; the cited sandbox did not establish real transfers.
Controls and mitigations
- DiggingBeagle recommendation: do not give an ordinary documentation-reading task unrestricted payment capability; require a separate approval describing the precise transaction.
- DiggingBeagle recommendation: enforce recipient and spending policies outside the model and test hidden as well as visible page instructions. A spending cap limits magnitude but does not validate purpose.
- Preserve the exact test harness and permission configuration when comparing model outcomes; do not turn the reported sample into a general attack success rate.
Unknowns and contradictions
- The Source does not establish how many users or autonomous agents encountered the malicious websites outside ThreatLabz testing.
- The four successful AI-agent payment executions occurred in a fully sandboxed environment with no real funds at risk.
- The cited wallet had received other payments, but the Source does not establish which payments, if any, were caused by this specific IPI campaign.
- The controlled payment result does not establish attributable real-world crypto losses, a victim count or susceptibility under a different authorization policy.
Sources and citation
Material revision history
- Sep 25, 2026 · Published version · first publication · revision 50
- Oct 1, 2026 · Published version · material revision · revision 65Public fields changed: assessment_profile, attack_path, implications, links, mitigations, narrative, references, summary, unknowns
- Oct 8, 2026 · Published version · material revision · revision 100Public fields changed: ai_roles, concepts, narrative