How it fails
The animation steps through one representative failure and the control that stops it. Use the arrow buttons to go at your own pace.
Overview
An agent's connected environment lets an unauthorized party control the person's accounts or recovery mechanisms. The distinctive concern is concentration: email, messages, authenticated browser sessions, and identity-recovery access sit behind one assistant, so one compromise reaches many accounts. Exposure of private content without takeover belongs primarily to PAA03.
Common examples of vulnerability
- Hidden page or email instructions make a browsing agent read a one-time code from the inbox and submit it to an attacker.
- An agent reuses an authenticated session to change a recovery address or phone number.
- A malicious or over-privileged skill, connector, or extension reads stored tokens, keys, or cookies.
- An exposed or poorly authenticated agent gateway gives a stranger the owner's connected accounts.
- A familiar name or thread is accepted as proof of authority to disclose a code or secret.
Example attack scenarios
Documented scenarios generalize a real case listed below. Hypothetical scenarios have no matching public case yet.
Scenario 1: Injected page instructions retrieve a login code Documented
A person asks a browsing agent to summarize a web page. Hidden text on the page tells the agent to trigger a sign-in code for one of the person's accounts, read it from the already-open inbox, and send it to the attacker.
Scenario 2: Malicious skill harvests credentials Documented
A person installs a popular-looking skill from an agent marketplace. It tells the agent to run a command that sends local credentials, keychain data, or keys to the skill author's server.
Scenario 3: One click on a link hands over the agent's gateway Documented
A person who runs a self-hosted agent opens a crafted link. The page steals the agent's stored gateway token and uses it to take control of the agent, even though the gateway only listens on the local machine.
Scenario 4: Trojanized connector copies every outgoing email Documented
A person's agent uses an email-sending connector from a public package registry. An update adds one line that silently copies every message to an attacker's address.
Scenario 5: Crafted link makes the browser agent read memory, mail, and calendar Documented
A person clicks a link whose URL parameters instruct the browser agent to consult its memory and connected services, encode what it finds, and send it to an external endpoint.
Real-world cases
Dated and sourced. Nothing here shows how common the failure is; it shows that it has happened or been demonstrated.
Brave shows Perplexity Comet can be steered into fetching a login one-time code
- What happened
- A hidden instruction in a Reddit comment (behind a spoiler tag) was followed when a user only asked Comet to summarize the page. The agent opened the user's Perplexity account page to read their email address, used a lookalike domain to trigger a one-time password, read the code from the user's already-logged-in Gmail, and posted both values back as a Reddit reply, which would let an attacker take over the account.
- Caveats
- Controlled demonstration. Discovered 25 July 2025; Perplexity shipped a fix on 27 July that Brave found incomplete, and Brave later said the attack class was still not fully mitigated.
- Grounds
- Scenario 1
- Sources
- Brave disclosure
CometJacking: a crafted URL makes Comet read memory, Gmail and Calendar
- What happened
- LayerX showed that instructions placed in the URL's 'collection' parameter made Comet consult its memory and connected services instead of searching, pull Gmail and Calendar data, base64-encode it, and send it to an attacker-controlled endpoint after a single click.
- Caveats
- LayerX reported it on 27-28 August 2025. Perplexity first said it found no security impact, and later said it had independently identified and patched the issue; the two accounts conflict. LayerX's own post was not reviewed.
- Grounds
- Scenario 5
- Sources
- The Hacker News · Schneier on Security
ClawHavoc: hundreds of malicious OpenClaw skills distributing an infostealer
- What happened
- Koi Security audited 2,857 skills on the ClawHub marketplace and flagged 341 as malicious, 335 of them tied to one campaign it named ClawHavoc. The main payload was the Atomic macOS Stealer, which targets keychain data, browser credentials, SSH keys, and crypto wallets. Later counts were higher: Antiy CERT counted 1,184 malicious packages linked to 12 publisher accounts, and Unit 42 reported finding further malicious skills that had passed ClawHub's VirusTotal screening.
- Caveats
- Counts differ by source and over time. Koi's own post could not be opened (the URL redirects), so figures come from The Hacker News, Antiy, and Unit 42 coverage.
- Grounds
- Scenario 2
- Sources
- The Hacker News · Antiy Labs analysis · Unit 42
CVE-2026-25253: one crafted link steals an OpenClaw gateway token
- What happened
- A flaw rated CVSS 8.8 let a crafted link or page steal the stored gateway token and then hijack the local instance over WebSocket, even when it was bound to localhost, leading to code execution on the host. Most detailed sources (Wiz, SentinelOne, runZero) say it was fixed in version 2026.1.29, which added a confirmation prompt before connecting to a new gateway URL from the query string.
- Caveats
- The date is approximated from the fixed release number (2026.1.29), not from a dated advisory. Sources conflict on the fixed version and on the exact component; the best-supported answer is 2026.1.29. Check the official OpenClaw advisory before relying on version numbers.
- Grounds
- Scenario 3
- Sources
- Wiz vulnerability entry · SentinelOne entry · runZero
postmark-mcp: a trojanized email connector BCCs every message to an attacker
- What happened
- The npm package `postmark-mcp`, an MCP server for sending email through Postmark, was modified in versions published around 15-17 September 2025. Snyk's analysis found the only notable change between benign 1.0.15 and malicious 1.0.18 was a `sendEmail` tool that silently added a BCC to an external address, so every outbound email was copied to the attacker. The package was removed from npm after detection, but installed copies kept running until uninstalled. Postmark said it had nothing to do with the package.
- Caveats
- Scale is disputed: Koi's reporting, as summarized elsewhere, cites about 1,643 downloads, and other coverage claims thousands of redirected emails a day. Snyk does not quantify the impact, and those higher figures are unverified.
- Grounds
- Scenario 4
- Sources
- Snyk analysis · Dark Reading
Prevention and mitigation
What you can do
- Keep recovery for email and financial accounts independent of the agent (separate device, hardware key, or trusted contact).
- Review connected apps and active sessions regularly; remove what you do not use.
- Never let the agent forward one-time codes or recovery links to anyone; complete those steps yourself.
What the provider must do
- Keep secrets in a store the model cannot read; give the model handles, not values.
- Require a protected, user-controlled flow for recovery changes and sensitive authentication; a message thread or agent identity is never sufficient.
- Scope and time-limit authenticated sessions; separate agent browser profiles from the person's own profile.
- Sandbox skills and connectors, vet them before listing, and show requested capabilities before install.
- Authenticate gateways and keep them off the public internet by default.
Where a safeguard is unavailable, offer a narrower mode such as read-only access or manual completion rather than rely on an instruction to the model.
See the reference guard controls for PAA02 →
Test it
Framework crosswalk
Related mechanisms in other OWASP work. This is an analytical mapping, not equivalence.
Top 10 for Agentic Applications 2026Personal focus: Concentrated account access and independent recovery.
Improve this entry on GitHub →