Agentic wallet security: what actually goes wrong
The failure modes with evidence behind them, separated from the ones that only have a statistic. One widely quoted figure does not survive.
Search for agentic wallet security and you get the same numbers repeated across a dozen pages, usually without a link to where they came from. Some of them are solid. At least one falls apart the moment you check it.
This is what the evidence actually supports, and where it does not.
Start with the number that does not survive
The most-quoted figure in this category is that over $45 million was lost to AI agent protocol weaknesses in the first quarter of 2026. We quoted it ourselves until we traced it.
About $40 million of that total is a single incident: the January 2026 breach of Step Finance, a Solana portfolio manager. In the agent-security write-ups this appears as agents executing unauthorised transfers because their permissions were too broad.
The primary reporting says something different.
The breach did not involve any smart contract vulnerabilities; it stemmed from operational weaknesses, including endpoint compromises on executive hardware.
Attackers compromised devices belonging to members of the executive team and reached treasury and fee wallets. That is a laptop-and-phishing story, and it would have happened to a company with no agents at all.
Two things follow. The first is that you should check the citation on any number in this space, including ours. The second is that the real failure modes are more specific and more interesting than the total suggests.
The failures with evidence behind them
1. Prompt injection, in an encoding nobody thought to distrust
The clearest documented case cost $150,000 in May 2026. An attacker sent a membership NFT to an AI-integrated wallet, which silently moved it into a higher permission tier, then posted a reply on X with an instruction hidden inside Morse code. The agent decoded it, treated it as a legitimate command, and authorised the transfer.
No exploit. No stolen key. The model was asked nicely, in a format nobody had thought to filter.
This has a name and a number: it is OWASP LLM01:2025, the first entry in the standard list of ways language-model applications fail.
2. Excessive agency — the half that decides the cost
The same incident is also LLM06:2025. Being persuaded and being able to act were the same event: once the model believed the instruction, nothing stood between that belief and a transfer to an attacker’s address.
Nobody has solved this. Assume the model can be fooled, because it can.
This one is not a model problem. It is a question about what the surrounding system permits to be written down — and that is a design decision, not a research problem.
The first failure gets the headlines. The second decided how much it cost.
3. Shared credentials across a fleet
Surveyed across 900+ practitioners, 45.6% of teams still use a shared API key for agent-to-agent authentication, and 27.2% use hand-rolled authorisation logic.
When every agent presents the same credential, you cannot attribute an action to one of them, which means you cannot stop one of them. Compromise is all-or-nothing by construction.
4. The tool protocol, not the model
The attack surface in most reported incidents was not the model’s reasoning. It was the plumbing: the protocols agents use to call external tools, and the memory they carry between turns. Poison what an agent reads and you do not need to defeat what it thinks.
This is the least discussed and probably the most important, because it is the part teams treat as infrastructure rather than as attack surface.
What none of this is
It is worth naming the failures that get attributed to agentic wallets and are not about agents at all:
- Endpoint compromise
- Someone’s laptop. Would have happened without agents. The largest loss in the category so far
- Phishing an operator
- Same category. An agent in the stack changes nothing about it
- Ordinary contract bugs
- A vulnerability in a protocol the agent happened to call is a vulnerability in that protocol
Lumping these together inflates the category’s risk while making the specific, tractable failures harder to see.
What actually reduces the risk
Not more filtering. Less expressiveness.
Injection you cannot prevent. Expressiveness you can remove.
If an agent can compose an arbitrary transaction, every control is a filter judged against attacks somebody already imagined. If the agent can only fill in labelled boxes drawn from a closed list — with no box for a destination address and no box for a payload — then the instruction “send it to me” has nowhere to be written, and nothing has to catch it.
- Ask what the agent can write down
If the answer contains an address, the rest is filtering.
- Ask where the spending cap is enforced
A cap in the operator’s backend is a policy. A cap in an account only you control is not something they can raise.
- Ask what a compromised agent costs, as a number
A good answer is a figure you set. A vague answer means nobody has computed it.
- Ask what has been proven, and by whom
Self-testing is worth something. It is not an audit, and anyone conflating the two is telling you something.
Our own answer, including the uncomfortable half
The agent here holds no key and cannot name a destination. Caps live in your account and nothing on our side can raise them. The agent’s appointment is one-way: your account can never be re-pointed at a different agent, only at none.
And: the guard works as a list of banned actions rather than a list of permitted ones. It completely blocks a takeover, but it does not block every way value could move through an action nobody thought to ban. We have proven four such attacks against ourselves, on a copy of the real Base network. There has been no external audit. The service holding our keeper key refuses to start in a production setting, deliberately, because it currently keeps that key in memory.
If a vendor’s security page has no section that reads like that paragraph, the section exists anyway — it just has not been written down.