The report
Browsers have always held an uncomfortable amount of authority.
Email stays logged in. Cloud storage stays logged in. Exchanges, dashboards and wallet extensions often stay one click away. A normal browser therefore already sits close to identities, secrets and money.
For most of the browser's history, however, the browser itself mostly waited for the person to decide what happened next.
Agentic browsing changes that relationship. An agent can read a page, interpret its contents, navigate somewhere else, use an authenticated session and continue working without asking the user to manually perform every intermediate step.
Once cryptocurrency enters the same environment, the useful question is no longer only whether the agent is intelligent enough to complete the task.
The harder question is what authority it can accidentally inherit.
Five recent cases make that boundary easier to see. They are not all the same kind of evidence, and treating them as one undifferentiated class would be misleading.
- Perplexity Comet and Opera Neon are researcher-controlled browser-agent demonstrations.
- Zscaler observed malicious web infrastructure in the wild, then tested AI-agent susceptibility in a sandbox.
- Silent Swap and Needle Stealer are observed malware campaigns operating against real browser environments.
That distinction matters throughout the article.
One page can contain instructions for two different audiences
Zscaler ThreatLabz documented malicious websites containing instructions that ordinary users would not normally see but an AI system could process.
One campaign presented itself as documentation for a Python library. Behind the visible page, the site used structured JSON-LD data and CSS-hidden material to provide a separate set of instructions to an AI agent. Those instructions described a fake developer-license purchase and a cryptocurrency payment flow.
The malicious page contained code and instructions for sending approximately 0.0012 ETH to a hardcoded wallet and then presenting a fake API key.
The important measurement came from controlled testing rather than observed victim payments. ThreatLabz evaluated 26 LLMs in a sandbox. Four caused the autonomous agent to execute the fraudulent payment action. No real funds were at risk in those tests.
That boundary is essential:
Observed in live infrastructure: malicious websites carrying hidden AI-directed instructions.
Demonstrated in the laboratory: some tested models drove the agent through the fake payment action.
Not established: four real users losing cryptocurrency to the campaign.
The security problem therefore contains two simultaneous interpretations of one page:
- what the person sees;
- what the agent reads and may treat as instructions.
Traditional phishing tries to manipulate the human reading the page. Indirect prompt injection introduces another possible target: software acting with the user's authority.
Evidence: `CASE-2026-ZSCALER-IPI-PAYMENT`, supported by `SRC-2026-ZSCALER-IPI-PAYMENT`.
The assistant can become the bridge between origins
Browser isolation normally assumes that hostile content on one site should not simply obtain authenticated information from another site.
An agent introduces a different path across that boundary. Instead of hostile JavaScript directly breaking the browser's origin rules, the assistant can voluntarily move information between origins because it believes that doing so is part of the task.
Brave researchers demonstrated this against Perplexity Comet.
Their proof of concept embedded malicious instructions in a Reddit comment. The trigger was not merely visiting Reddit: the user invoked Comet's page-summary functionality, causing the assistant to process the hostile content as part of its working context.
From there, Brave demonstrated a chain that crossed several authenticated surfaces:
1. the injected instructions were interpreted from the Reddit page;
2. Comet accessed the victim's Perplexity account information and obtained the account email address;
3. the flow initiated a one-time-password request;
4. Comet accessed the authenticated Gmail session and read the OTP;
5. the email address and OTP were exfiltrated through a Reddit reply.
The striking part of the chain is not a conventional same-origin bypass. The browser agent itself became the bridge between Reddit, Perplexity and Gmail.
The chronology also shows why a simple fixed/not-fixed label can be misleading. Brave reported the issue to Perplexity on 25 July 2025. Perplexity acknowledged it and deployed an initial mitigation on 27 July. Brave's retesting on 28 July found that mitigation incomplete and provided additional details. Brave publicly disclosed the work on 20 August and later stated that further testing showed the broader attack class was still not fully mitigated.
This remains a researcher-controlled proof of concept. The cited evidence does not establish widespread exploitation, victim prevalence or realized financial loss.
Evidence: `CASE-2025-COMET-IPI`, supported by `SRC-2025-BRAVE-COMET-IPI`.
Opera Neon exposed the same trust problem with a different implementation
Brave later disclosed another cross-origin prompt-injection proof of concept affecting Opera Neon while the product was in Early Access.
The initial ingredient was hidden HTML. Brave showed that instructions inside content that was not visually presented to the user, including an opacity-zero element, could still be processed by Neon's AI assistant.
The demonstrated flow then crossed an authentication boundary. Starting from an attacker-controlled page, the assistant accessed the user's authenticated Opera account, recovered the user's email address and leaked it to an attacker-controlled destination.
Opera independently investigated the report rather than relying only on the researcher's demonstration. The company said it could reproduce the proof of concept with approximately a 10% success rate and characterized exploitation complexity as high.
The remediation timeline is unusually concrete:
- 14 October 2025: Brave reported the issue through Bugcrowd.
- 20 October 2025: Opera reported that a production fix was deployed by 22:17:32 UTC.
- 21 October 2025: Opera said the researchers confirmed that their demonstrated PoC no longer worked; Brave likewise reported that follow-up testing indicated the vulnerability appeared patched.
- 23 October 2025: Opera publicly described the issue and its response.
The evidence therefore supports a narrower conclusion than 'Opera Neon was compromised in the wild.' What is established is a reproducible research demonstration, independent vendor reproduction and a verified fix for that demonstrated PoC.
It does not establish exploitation against ordinary users, and fixing the demonstrated technique does not prove that every possible indirect-prompt-injection technique has been eliminated.
Evidence: `CASE-2025-OPERA-NEON-IPI`, supported by `SRC-2025-BRAVE-OPERA-NEON-IPI` and `SRC-2025-OPERA-NEON-IPI-VENDOR`.
AI does not replace the old browser attack surface
The next case barely needs AI at all.
McAfee Labs analyzed Silent Swap, an active cryptocurrency-clipper campaign built around a malicious Chromium extension masquerading as Google Notes.
Its purpose was brutally simple: interfere with the moment when a user transfers a cryptocurrency address from one place to another.
The extension monitored addresses copied by the user. When the copied value matched a supported cryptocurrency format, the malware could obtain an attacker-controlled replacement address and substitute that address before the victim pasted the destination.
That attack is dangerous precisely because long cryptocurrency addresses are difficult to verify visually. A transaction interface can look normal while the destination has changed beneath the workflow.
But Silent Swap was not limited to clipboard logic. McAfee found that the installer targeted Chromium-family browser profiles including Chrome, Edge, Opera and Brave. It modified browser configuration data such as Preferences or Secure Preferences and attempted to update integrity-related values so the unauthorized extension would still load.
In other words, the attack crossed several layers:
1. execution of an untrusted installer;
2. modification of browser configuration;
3. insertion of a malicious extension;
4. monitoring of cryptocurrency-address activity;
5. substitution of the intended destination.
McAfee also reconstructed the campaign's backend behavior and found deterministic mappings between victim-supplied cryptocurrency addresses and attacker-controlled replacement addresses for multiple currencies.
What McAfee could not establish was the campaign's total financial damage. The unknown number of attacker-controlled wallets means that balances from individual observed addresses cannot safely be summed and presented as an aggregate theft figure.
This is useful context for agentic browsing because browsers were already financial attack surfaces before agents arrived. Wallet extensions, authenticated sessions and transaction workflows were already valuable. Adding agent authority does not remove those old risks; it places another trust layer beside them.
Evidence: `CASE-2026-SILENT-SWAP`, supported by `SRC-2026-MCAFEE-SILENT-SWAP`.
Sometimes AI is the lure rather than the weapon
HP Wolf Security documented a different collision between AI and cryptocurrency during Q2 2026.
A website at tradingclaw[.]pro presented itself as an AI-powered cryptocurrency-trading assistant. According to HP, the campaign used search-engine poisoning and paid advertising to push prospective victims toward a ZIP installer carrying Needle Stealer.
The AI story was therefore primarily the lure. The malicious behavior that followed was conventional endpoint and browser-wallet compromise.
HP's documented infection chain used a legitimate Microsoft-signed executable to load a malicious DLL. After execution, the malware checked the browser for hardcoded extension IDs corresponding to seven cryptocurrency wallets:
- Phantom;
- Trust Wallet;
- Atomic Wallet;
- Coinbase Wallet;
- OKX Wallet;
- MetaMask;
- Tonkeeper.
When a targeted wallet extension was present, the malware attempted to replace it with a malicious version.
HP reported that the replacement extension could collect wallet credentials. In the documented behavior, entering a wallet identifier and password into the fake extension could transmit that information to attacker-controlled infrastructure, giving the attacker access to the wallet's funds.
Again, the boundary matters. The report supports the campaign, the targeting logic and the credential-theft mechanism. It does not provide a complete victim count or a defensible aggregate realized-loss figure. Listing seven wallet products also does not mean that every user of those products was compromised.
This case demonstrates a separate security lesson from prompt injection: attackers do not need to exploit an AI model if the phrase 'AI trading assistant' is enough to persuade someone to install hostile software next to their wallet.
Evidence: `CASE-2026-NEEDLE-STEALER`, supported by `SRC-2026-HP-NEEDLE-STEALER`.
Five cases, four different paths to authority
The cases can be reduced to four broad paths without pretending that they are identical.
| Case | Initial lever | Authority crossed or targeted | Evidence setting |
| --- | --- | --- | --- |
| Zscaler IPI payment scam | Hidden instructions in malicious web content | Agent-driven payment workflow | Live malicious sites + sandbox agent testing |
| Perplexity Comet | Indirect prompt injection in Reddit content | Authenticated Perplexity and Gmail data across origins | Research demonstration |
| Opera Neon | Hidden HTML prompt injection | Authenticated Opera account data across origins | Research demonstration with vendor reproduction |
| Silent Swap | Malicious Chromium extension | Cryptocurrency destination integrity | Observed malware campaign |
| Needle Stealer | Fake AI-trading software lure | Browser-wallet credentials and extension integrity | Observed malware campaign |
This table is useful because 'AI browser security' is not one vulnerability category.
One failure begins with untrusted text being mistaken for trusted instruction. Another begins with software installation. Another attacks an extension. Another takes advantage of authenticated browser state. The common factor is that the browser sits at the meeting point of content and authority.
The dangerous transition is from understanding to acting
A useful way to think about these cases is as a sequence of increasingly consequential capabilities.
Read — the browser or agent can observe content.
Interpret — the agent can treat some of that content as relevant to a task.
Navigate — the agent can move to another site or authenticated service.
Carry state — the browser can bring cookies, sessions, account context or extension state with it.
Act — the software can submit forms, send messages, alter configuration or initiate a transaction workflow.
Authorize — the environment can finally expose credentials, wallet approval or another irreversible capability.
Not every browser agent has every capability, and these five cases do not prove that every implementation collapses those boundaries. They show why security changes quickly when several of them are available in one context.
The most important boundary is therefore not merely between 'AI' and 'non-AI.' It is between information and authority.
A system may safely let an agent understand a wallet balance while refusing to let page content authorize a transfer. It may allow navigation across services while prohibiting arbitrary movement of authenticated data between origins. It may let an agent prepare a transaction while reserving final wallet approval for a separate trust boundary.
Those are architectural distinctions, not product rankings.
Three security models now occupy the same browser
These five cases expose three security models that increasingly have to coexist.
1. Browser security tries to isolate hostile sites and origins from each other.
2. Wallet security tries to prevent access to the browser from automatically becoming authority to move assets.
3. Agent security tries to let software act usefully while the content it reads may itself be hostile.
The dangerous shortcut is to collapse those models into one vague permission such as 'use my browser.'
A browser agent may need to understand a transaction without being able to approve it. It may need to read a DeFi interface without inheriting wallet-signing authority. It may need authenticated access to one service without being free to carry data into another origin. And the browser itself still needs protection against malicious extensions and hostile local software.
The cases also suggest a practical set of questions for any architecture that places an agent close to financial authority:
- Can untrusted page content become an instruction source?
- Can the agent cross from one authenticated origin into another?
- Can data retrieved from one origin be written into another origin without a separate authorization boundary?
- Can the agent initiate or complete a payment workflow?
- Is wallet approval distinct from ordinary browser or agent authority?
- Can local software modify or replace the browser's wallet extensions?
- Can the user inspect what information or authority crossed each boundary?
These questions do not produce a universal safe/unsafe label for a browser. They identify where authority actually resides.
The five cases here do not establish that agentic browsers are inherently unsafe around cryptocurrency. They establish something narrower and more useful: browser authority has become part of the security boundary, and systems that combine untrusted content, authenticated state and financial actions need explicit separation between understanding, navigation and irreversible authority.
The useful design target is simple to state even if it is difficult to implement:
> The browser can understand the wallet without becoming the wallet.
As browser agents become better at completing the user's intent, that distinction becomes more important. The consequential question is increasingly not whether the agent understands what the user wants, but exactly which parts of the user's authority it is allowed to inherit.