AI Pulse · Under the Radar

A developer recently demonstrated on X what happens when an AI agent with wallet-signing permissions runs into a poisoned npm package. The malicious dependency tried to redirect a transaction. A hardware wallet caught the attempt and the human rejected it.

This was a sponsored post, so take the framing with caution. But the mechanics are straightforward and reproducible. An agent pulled in a compromised library from the npm registry. That library injected code to alter transaction details. The hardware signer flagged the mismatch between what the agent said it would do and what the transaction actually contained. The human saw the alert and stopped it.

Why this matters now

We are handing agents real permissions. They book meetings, move files, trigger workflows. Some are starting to handle payments or sign contracts. Every permission is a new surface for supply-chain attacks, and the npm ecosystem has thousands of packages updated daily with minimal review. If an agent can execute code from any dependency, an attacker only needs to compromise one obscure library in the chain.

The fix is not to avoid agents. It is to assume dependencies will be compromised and design accordingly. Run agents in sandboxes. Use hardware or API-level transaction signers that show humans exactly what is about to happen, not what the agent claims it will do. Log every action with enough detail to audit later. This is the kind of guardrail we build into systems like the Omni Command Centre, where agents operate inside defined boundaries and every high-stakes action goes through a verification layer.

The demo was a proof of concept, not a live breach. But supply-chain attacks are common, agents are new, and the combination is predictable. If you are deploying agents with any real authority, treat every dependency as untrusted and put a human or a hardware check between the agent and anything irreversible.