# 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.

- Source: https://defiloops.com/blog/agentic-wallet-security-what-actually-goes-wrong
- Published: 2026-06-02
- Category: Security
- Tags: agentic-wallet, ai-agents, security, prompt-injection
- Author: DeFiLoops

---
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.

<Quote cite="Reporting on the Step Finance incident">
  The breach did not involve any smart contract vulnerabilities; it stemmed from operational
  weaknesses, including endpoint compromises on executive hardware.
</Quote>

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.

<Callout type="danger" title="So roughly 89% of “lost to agent protocol weaknesses” is not that">
  This is not a small correction. It is the difference between a category with a
  $45 million problem and a category whose largest confirmed loss is three orders of
  magnitude smaller. Anyone sizing this risk from the headline number is sizing the wrong
  thing.
</Callout>

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.

<Callout type="warn" title="You cannot enumerate the encodings">
  Morse worked. So will base64, an image, a homoglyph, or a language the guardrails were
  never evaluated in. Any text passing through a decoding or translation layer should be
  treated as potentially injected, because the layer is the bypass.
</Callout>

This has a name and a number: it is [OWASP LLM01:2025](https://genai.owasp.org/llm-top-10/),
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.

<Compare left="Prompt injection" right="Excessive agency" verdict>
  <Fragment slot="left">
    Nobody has solved this. Assume the model can be fooled, because it can.
  </Fragment>
  <Fragment slot="right">
    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.
  </Fragment>
</Compare>

The first failure gets the headlines. The second decided how much it cost.

### 3. Shared credentials across a fleet

[Surveyed across 900+ practitioners](https://www.gravitee.io/blog/state-of-ai-agent-security-2026-report-when-adoption-outpaces-control),
**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:

<Spec rows={[
  ['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.

<Quote>
  Injection you cannot prevent. Expressiveness you can remove.
</Quote>

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.

<Steps>
  <Step title="Ask what the agent can write down">
    If the answer contains an address, the rest is filtering.
  </Step>
  <Step title="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.
  </Step>
  <Step title="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.
  </Step>
  <Step title="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.
  </Step>
</Steps>

## 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.