Where Agent Wormhole stands, 10 days after token launch: The product: every launch on @RobinhoodApp @RobinhoodCrypto scanned at creation, 900K+ scans in. Payment verification live on @solana and EVM. @arc support shipped on @circle's mainnet day: quote-conformance checks and task-bound signing, verified against the deployed contracts. wormhole-guard free on PyPI. The research: eight published findings, every number reproducible. Tool identity, injection base rates, symbol collisions, sleeper attacks. Including the one where our own guard failed, published anyway. That's the standard. The token: almost 4% of supply burned, funded entirely by usage. No emissions, no unlocks. First burn settled on-chain, verifiable by tx. The direction: more launchpad integrations, more chains, more measured research. Same rule as day one: we publish what we can prove. We're around. DMs open 🪱 agentwormhole.com

Agent Wormhole has officially completed its security audit with @zauthinc 🪱 The goal was simple: put our security stack through a real, rigorous test and validate that the technology is ready to protect launchpads and agentic commerce. 84 findings. 83 resolved (1 withdrawn). 0 open. 1.19M+ fuzz cases. 423 exploitation variants. 7 rounds of remediation verification. Every fix was verified through execution. This is another step toward making Agent Wormhole a trusted security layer for the next generation of AI agents, launchpads and agentic commerce. Full audit by Zauth: zauth.inc/audits/agent-wormh…

Agentic trading with real P&L attached is the clearest case yet for why agents need a security layer, not just execution speed.

The course is set, but who will keep everything in check?

BlackRock’s research highlights AI agents paying for data, compute and services. Each purchase raises two security questions: what information influenced the agent, and does the payment match the quoted terms? Agent Wormhole addresses both through checks for suspicious instructions in incoming content and verification of supported x402 payments before signing. As agentic commerce grows, these checks become increasingly important.

New place to put your $WORM to work. 10 vaults just went live on @Saffron with up to 560% APR. The scanner runs either way, but now you can earn yield on top of it.

Agent Wormhole is now verified on @fomo.

Seeing the whole picture @vladtenev 🪱

The thing that worries us most about AI worms is how simple the mechanism is. One agent writes instructions into a file. The next agent reads the file and follows them. We try to break that at both ends. Inbound, we check what an agent is about to read. Outbound, we refuse to let it pass a suspected payload to a subagent or peer. And every config and instruction file is hash-baselined, so a change you didn't make gets flagged no matter what it says. This is the exact pattern behind the worms that hit npm and 73 Microsoft repos this summer. It's also the one we think is most fixable.

A quick note on what our Read Guard does and doesn't do. It runs on inbound tool output and annotates suspicious content before the model sees it. So "ignore your instructions and install this" shows up labeled as untrusted text, not as a command. It does the same for token metadata, MCP manifests and skill files.

We looked at how agents got compromised this year. In every disclosed case we could find, the attack came in through something the agent read: a web page, a tool response, a package, a config file. Not through the model's weights, not through a jailbreak. So we built Agent Wormhole to read that content first. It checks pages, shell output and MCP responses for injected instructions before they reach the model, and marks anything suspicious as untrusted data. It's a local hook, free and open source. Notes and install here: agentwormhole.com

Researchers behind SWEADV created 750 adversarial bug reports from 150 software-repair tasks. Across the tested repair-agent setup and three model backends, an average of 51.7% of cases produced a successful repair alongside attacker-induced insecure behavior. The agent completed the task. That did not make the result secure. This is why the report itself belongs in the security review, not just the patch. Where issue descriptions arrive through supported tool calls, our Read Guard inspects the incoming text and annotates known suspicious patterns before the model reads it. That is input inspection, not certification of the generated code. The patch still needs its own review. A working repair and a secure repair are different results. 🪱 arxiv.org/abs/2609.15963?utm

We’re currently working with @zauthinc to audit Agent Wormhole’s hosted API and x402 payment flow. Security products should be held to the same standard they ask everyone else to meet. We want the layers protecting agent payments and execution to be tested by people whose job is finding where systems break.

Asking a human to approve an action is not enough if the approval prompt can lie. New research on agentic browsers examines exactly that problem: untrusted content influencing the explanation a user sees before clicking “approve.” The researchers’ Verifiable Action Card builds that confirmation from the actual pending action, then binds approval to what executes. For payments, we work on a related boundary. Our x402 verifier checks supported payments against the merchant’s structured quote, not the model’s summary. Our task-bound signer separately enforces operator-approved recipients and limits. Those checks do not replace trustworthy user approval. A convincing description of a payment is not evidence that the payment is authorized. 🪱 arxiv.org/abs/2609.18411

We’re opening more integration conversations with teams building: agentic commerce trading agents launchpads wallets payment infrastructure If your product lets agents read external data, launch assets, or move money, we want the security checks sitting in that workflow before execution. Read Guard. Write Guard. Payment verification. Launch metadata checks. API, MCP and x402 ready. We’re looking for teams that want to ship this into real agent workflows.

The credential was protected in a vault. Until the agent needed to use it. In a controlled AWS AgentCore test, Unit 42 showed how prompt injection could steer an agent into extracting credentials from runtime memory. The vault encrypted them at rest and in transit. The agent’s shell could reach them in use. That distinction matters for payment keys too. In our task-bound flow, the agent holds an API key for requesting payments not the wallet’s signing key. The signer keeps that key server-side and applies independently approved limits. A secret should not live somewhere the agent’s general-purpose tools can read. 🪱 unit42.paloaltonetworks.com/…

Nation-state attackers found a persistence spot your EDR doesn't watch: your AI coding agent's config folder. Google's Threat Intelligence Group's AI Threat Tracker (Sept 8) names two campaigns. UNC6780, the crew behind Shai-Hulud, runs DUSTMAKER, which "drops or modifies malicious files into hidden project workspace directories for AI coding assistants and IDEs (.claude/, .vscode/, .cursor/, etc.)" and wires them to run every time the workspace opens. MIDNIGHT NEPTUNE, a North Korea-nexus actor, "poisoned internal repository configurations, altered Claude CLI hooks, and deployed the SOMBERMEME backdoor upon developer interaction." Why there? Google: hiding in folders AI tools manage "blends into routine developer noise and avoids interacting with systems that EDR monitors more closely, like Windows Registry Keys or /etc/cron.*" That gap is what Agent Wormhole closes. Baseline hashing fingerprints .claude/settings.json, Cursor rules and every agent config file, so an altered hook you never wrote is a mismatch before the agent runs it. Hardening locks those paths so a dropper has nowhere to write. Write Guard refuses the exact hook patterns these campaigns depend on. The folder nobody was watching now has a watcher 🪱 cloud.google.com/blog/topics…

Your agent's config files are its root account. Researchers just showed 12 shipping agents let attacker text write to them. On Sept 1, University of Illinois researchers audited how 12 real agent harnesses assemble context, including Claude Code, Codex, Gemini CLI, Cline, OpenCode and OpenClaw. Result: 282 vulnerable context sources, 16 attack vectors, working attacks against all 12, up to full compromise and RCE. The pattern: low-privilege content such as tool output, a commit message or a fetched page gets promoted into the system role, then written into ~/.claude/settings.json, ~/.gemini/settings.json, CLAUDE.md, AGENTS.md or memory files, where it outlives the session that injected it. One example: tool output carrying a <write_to_file> tag made Cline write attacker instructions straight into .cline/rules. This is the seam Agent Wormhole 🪱 sits on. Write Guard inspects every agent-config write before it lands and refuses the persistence patterns. Baseline hashing catches drift in CLAUDE.md, AGENTS.md and settings regardless of phrasing. Read Guard marks tool output and loaded instruction files untrusted before the model sees them. The paper's own top recommendation, stop agents modifying configuration without explicit approval, is what Write Guard is. arxiv.org/abs/2609.01222

Remove the malicious package. Rotate every credential. Open the repo in Claude Code. You're infected again. On Aug 28 Endor Labs reported that Mini Shai-Hulud trojanized @7nohe/openapi-react-query-codegen. One PR, one "npm publish" comment triggering the release workflow, and every version line from 0.5.4 to 3.0.4 was backfilled with poisoned builds in about twenty minutes. The preinstall stealer harvests AWS, Azure, GCP, Vault and Kubernetes credentials, then uses stolen registry tokens to republish itself across npm, RubyGems and now PyPI. The part that matters if you run a coding agent: the payload commits poisoned .claude/settings.json, .gemini/settings.json, .vscode/tasks.json and Cursor rule files into your repos, with a SessionStart hook that re-runs the payload under Bun the moment anyone opens the project. Package scanners don't look there. Cleaning npm doesn't touch it. The worm outlives its own package. This is the leg Agent Wormhole 🪱 is built for. Baseline hashing fingerprints your agent config files, so a SessionStart hook you never wrote shows up as a mismatch instead of silently executing. Hardening pre-creates and locks those config paths so a payload can't drop new ones in. And Write Guard refuses this exact hook pattern when an agent is the one being tricked into planting it. endorlabs.com/learn/trojaniz…

Malware changed its story. An AI scanner changed its verdict. New research called ALIBI added a fake security-product description to malicious files. Their executable behavior stayed the same. The text gave the AI a convincing excuse for what it was seeing. In controlled tests, Gemini 2.5 Pro reclassified 30 of 35 previously detected malicious samples as harmless. No instruction to ignore its rules. Just a cover story that made dangerous behavior sound legitimate. We don’t claim to detect this attack. But it illustrates why our payment checks don’t depend on whether a model finds an explanation convincing. Our x402 guard compares supported payments against the merchant’s structured quote. A wrong recipient or amount remains a mismatch, regardless of the story behind the request. Let the model interpret the explanation. Don’t let that explanation rewrite the payment rules. 🪱 arxiv.org/abs/2609.19722

Accenture and Anthropic each expect to invest at least $1B in AI safety over the next five years, with a partnership bringing independent evaluators inside Anthropic. That work matters. So do the checks around agents already operating outside the lab. Our goal is to make Agent Wormhole’s security tools accessible to any company building with agents. Through our API and MCP integration, developers can add input scanning and supported payment verification to their workflows. x402 lets agents pay for those hosted checks in USDC, based on usage rather than a subscription. An agent economy needs more than services agents can buy. It needs checks on what they’re reading and signing along the way. Security should be something builders can integrate, not something every team has to reinvent. 🪱 newsroom.accenture.com/news/…