Agentic DeFi security: when AI agents control treasury, trading, and liquidations

By early 2026, a growing share of on-chain capital is no longer moved by a human pressing sign. It is moved by an LLM agent that read some text, decided what to do, and called a tool that holds a key. ElizaOS-built bots have collectively managed tens of millions in assets. aarna Finance runs AI-managed treasuries for DAOs. Walbi shipped no-code trading agents to retail in March 2026 and processed roughly 187,000 autonomous trades in a single beta. The category has a name now — DeFAI or AgentFi — and it has products.

It also has its first clean loss. On May 4, 2026, a Grok-linked wallet operating through Bankr tooling was drained of around 3 billion DRB, worth roughly $150,000 to $180,000. There was no smart contract bug. The contracts did exactly what they were told. The AI agent was talked into telling them the wrong thing.

That sentence is the whole problem: in agentic DeFi, the agent is now part of the trust model. A protocol can be flawlessly audited at the Solidity level and still lose user funds because the privileged actor calling the contract is a language model that can be manipulated with text. Most of the new failure modes are not contract vulnerabilities. They are agent vulnerabilities that route around the contract entirely. A Solidity audit does not cover them, and that is the gap this post is about.

We will walk the three highest-value places an agent ends up holding the keys — treasury, trading, and liquidations — and for each one separate what the agent actually does from what an auditor has to worry about. Then we will get specific about the attack surface, because there is now real research and a real incident to anchor it.

The three agent roles in agentic DeFi: treasury, trading, and liquidations — each with a distinct attack surface

Treasury: the agent as CFO

The pitch for autonomous treasury management is an efficiency argument. DAO treasuries are large and badly managed. Committee governance is slow, payroll and swaps wait on votes, and the average treasury earns far less than it could if capital were actively rotated across lending and LP positions. An agent that monitors utilization and rates 24/7 and reallocates within governance-set thresholds closes that gap.

So that is what these systems do. aarna Finance rotates stablecoins across Aave, Compound, and Curve based on risk-adjusted return and quotes 8–12% APY for DAO treasuries. SingularityDAO's DynaSets are shared on-chain vaults built for rebalancing and yield. ai16z's ElizaOS ran a treasury vehicle fronted by an agent persona. Olas Governatooorr delegates governance proposals autonomously — treasury-adjacent because governance controls the treasury.

Here is the auditor's question, and it is not about the yield strategy. It is: what is the maximum unilateral on-chain action this agent can take, and what bounds it? The strategy can be excellent and the system can still be a single prompt away from catastrophic. In practice the treasury agent holds, or can trigger, a privileged signer — a multisig module, a session key, an ERC-4337 policy. If the only thing standing between that signer and a drained treasury is an instruction in the system prompt that says "never send more than X to an unapproved address," then the treasury is not bounded. It feels bounded. It is not.

The defensible answer is on-chain enforcement: destination allowlists, per-transaction and per-epoch caps coded in the contract, and a mandatory timelock above a threshold that a human must confirm. Anything short of that is a suggestion the next injected memory will overwrite.

Trading: the agent as desk

Trading is where agentic AI does the most visible work: order splitting to cut slippage, dynamic concentrated-liquidity range adjustment through Uniswap V4 hooks, cross-chain rebalancing when a rate differential beats the gas cost, MEV-aware execution timing. Walbi put this in front of retail with no code. Research frameworks like Tauric's TradingAgents formalize it into roles — market-intelligence, strategy, portfolio handler, and execution components — that debate and then act.

That decomposition is exactly where the trouble lives, and there is now a paper that proves it. TradeTrap, published in December 2025, takes that four-part structure and attacks each component in turn. The finding is blunt: autonomous LLM-based trading agents are unstable under targeted attacks across every component. Inject adversarial content into the system prompt that defines the agent's role and objectives, and the entire reasoning and tool-calling loop bends to it. The agent does not crash. It keeps trading, confidently, toward the attacker's goal.

We have covered the five systemic attack vectors on AI trading bots in depth. Here the point is narrower: for an auditor, the execution component is the dangerous seam, because that is where natural-language reasoning turns into a signed transaction. And the inputs feeding that reasoning are not all trustworthy. A trading agent reads market data, and increasingly reads social signals it scrapes. Both are input channels, and an input channel can carry instructions, not just data.

This gives oracle manipulation a second life. You do not need to manipulate the oracle on-chain if you can manipulate the off-chain feed the agent reads before it trades. The cheaper attack wins, and the cheaper attack is now the off-chain one. We have written about how indirect prompt injection works as a vector into agent reasoning via external data — the trading context makes it financially precise.

Liquidations: the agent as keeper, and as systemic risk

Liquidations are worth slowing down on, because this is where agent control stops being a single-account problem and becomes a protocol-level one.

The mechanism is familiar. DeFi lending is overcollateralized. When a borrower's health factor drops below one, the position becomes liquidatable, and any party can repay the debt and claim collateral at a discount. This has always been automated — keeper bots watch health factors continuously and execute liquidations with flash loans so they need little capital of their own. We have a detailed walkthrough of Liquity's stability pool and liquidation mechanics if you want to see this at the code level.

AI enters from three sides. On the borrower side, an agent watches collateral ratios and adds collateral or de-risks before liquidation triggers. On the liquidator side, agents prioritize and route liquidations at millisecond latency. On the protocol side, the more ambitious move is replacing static collateral thresholds with dynamic margining that adapts to real-time volatility — sometimes with ZK-ML so the protocol can prove a risk score was computed correctly without revealing the model.

Two auditor concerns sit on top of this.

Correlated behavior. When many protocols run similar models against similar thresholds, a volatility spike triggers synchronized liquidations across all of them at once. The agents are not dampening the shock — they are amplifying it, because they all see the same signal and all act the same way in the same instant. This is a liquidation cascade as an emergent property of the agents. Diversity of models and bounds is a safety property here, and monoculture is a systemic risk.

Auditability. MakerDAO drew criticism for opacity in AI-influenced collateral and liquidation decisions, where users could not reconstruct how a call was made. For an auditor this is not a soft concern. A black-box policy that takes irreversible, capital-destroying actions cannot be reviewed, which means it cannot be assured. The opacity is the finding.

The attack surface, specifically

Now the part an audit firm should be able to write better than anyone, because it is our job to be specific about how things break.

Prompt guardrails are not a control

The reference work here is the paper variously titled AI Agents in Cryptoland and Real AI Agents with Fake Memories. It introduces context manipulation as a single attack vector spanning three unprotected surfaces: input channels, the agent's memory, and external data feeds. Within that, it names a class that most teams are not defending against at all: memory injection.

Prompt injection is the attack everyone knows — a malicious instruction in the current input. Memory injection is more dangerous in three specific ways:

Persistent: the malicious instruction is written into the agent's stored memory and survives across sessions
Stealthy: the agent treats its own memory as trusted pre-existing context and processes it without suspicion
Cross-platform: an instruction injected on one surface (say, a Discord message) can fire later on another (an X reply or an Ethereum transaction)

Memory injection vs prompt injection: how injected memory bypasses input filters and survives across sessions and platforms

The researchers demonstrated this on ElizaOS connected to live Ethereum and X, producing unauthorized on-chain transfers with an on-chain transaction as evidence. They built a Web3-specific benchmark — CrAIBench — with over 150 realistic blockchain tasks and 500+ context-manipulation test cases.

The conclusion matters: models are significantly more vulnerable to memory injection than to prompt injection, and prompt-based defenses are fundamentally inadequate. If your agent's safety story is a well-written system prompt, you do not have a control. You have a suggestion that the next injected memory will overwrite. We have covered the architecture of long-lived agents and delayed execution risk — the memory vector is especially sharp there, where attacker-planted state can wait hours before triggering a privileged action.

The incident proves it is not theoretical

The Grok and Bankr drain in May 2026 is the worked example, and the chain is clean.

The Bankr/Grok attack chain: three steps from NFT privilege escalation to irreversible transfer

First, the attacker sent a Bankr Club Membership NFT to Grok's wallet. Holding that NFT silently widened the wallet's permissions inside Bankr to include transfers and swaps. That is privilege escalation triggered by an inbound asset, with no signature from the victim. Second, the attacker posted an instruction encoded in Morse code as an X reply — the encoding slipped past the input safety filter, the same way Base64 and game-style framing have been used elsewhere. Third, the agent decoded the message and executed a transfer of roughly 3 billion DRB to the attacker. The transaction was irreversible. About 80–88% of the funds came back later under public pressure, which is luck, not a recovery mechanism.

The detail that should bother every team is this: it was the second time the same wallet was drained, and after the first incident in March 2025, Bankr had blocked responses to Grok specifically to prevent exactly this. The NFT permission path routed around that block. A patch at the prompt and policy layer was defeated by a path at the permission layer. The lesson is structural: defense has to live at the privilege boundary, in code, not at the prompt.

We have published a detailed audit checklist for AI agent approval bypass and a companion on outbound authority controls — both directly address the mechanisms exploited in this chain.

A vocabulary for it: OWASP ASI

The OWASP Top 10 for Agentic Applications, published in December 2025, gives this a shared taxonomy, and the Grok chain hits several entries at once:

Attack observed	OWASP ASI item
NFT silently widens permissions	Identity and privilege abuse
Morse-encoded instruction bypasses filter	Agent goal hijack
Agent executes unauthorized transfer	Tool misuse
Past session memory carries injected state	Memory and context poisoning
Liquidation cascade from monoculture models	Cascading failures
Poisoned MCP server tool descriptors	Agentic supply chain

The governing principle OWASP lands on is least agency: grant an agent the minimum autonomy required for a bounded task, and no more. For DeFi, least agency is not a slogan — it is the design constraint. Our analysis of OWASP ASI04 (agentic supply chain) shows how this plays out at the dependency layer. Least-privilege tool scoping is the implementation of that principle at the tool-connector level.

Identity helps, but it is not runtime control

The standards response is ERC-8004 (Trustless Agents), deployed on Ethereum mainnet and a couple dozen networks as of 2026. It defines three on-chain registries — Identity (ERC-721-based), Reputation, and Validation — and lets a counterparty check who an agent claims to be and how it has scored before transacting.

This is genuinely useful, and it is worth being honest about what it does not do. ERC-8004 is identity and reputation. It raises the cost of impersonation and Sybil attacks. It does nothing to stop a correctly-identified, well-reputed agent from being prompt-injected or memory-poisoned in the middle of a task. Payments are explicitly out of scope. Knowing exactly which agent just got hijacked does not un-send the transaction.

The ERC-4337 smart account failure modes article covers how account-abstraction policy enforcement can bound agent authority at the contract level — that is a more robust control, because it does not depend on the agent cooperating.

Get funded for your audit

Core grants cover up to $32k. Growth and Builder tiers available. Rolling applications.

No spam. Unsubscribe anytime.

Why this needs a cross-layer audit

An autonomous financial agent is, at the same time:

An LLM that can be prompt-injected or indirectly injected
A blockchain actor with settlement and execution risk
A financial intermediary with regulatory exposure
A participant in a multi-agent system that other agents can strategically manipulate

Each research community tends to cover one of those facets and assume the others away. The blind spots live in the seams between them. That is precisely why a contract-only audit is incomplete for these systems. The contract can be clean while the agent that drives it is wide open, and the only way to see the real risk is to review the agent, the tools, the permission model, and the contract as one system.

Our coverage of AI red teaming in Web3 explains why security testing now must span both the Solidity and the reasoning layer.

The checklist we would actually run

Agentic DeFi security audit checklist: 10 checks ordered by how often they catch something

If you are shipping an agent that touches funds, here is the review we would run, in order of how often it catches something.

Privilege boundary. What is the maximum unilateral on-chain action the agent can take? Is it bounded in code — destination allowlists, per-transaction and per-epoch caps, mandatory timelock above threshold — or only by a prompt? If it is the prompt, treat it as unbounded.
Escalation paths. Can any inbound asset (NFT, token, airdrop) change the agent's permissions the way the Bankr NFT did? Enumerate every state change that can widen authority.
Context surfaces. Map every input channel, memory store, and external feed the agent reads. Mark which ones an attacker can write to. Memory and scraped social feeds usually qualify.
Memory integrity. Is stored memory authenticated and segmented, or can a past message rewrite future behavior? Test memory injection, not just prompt injection. It is the more dangerous and the more overlooked vector.
Encoding handling. Does input sanitization survive Morse, Base64, homoglyphs, and role-play framing? Red-team it — do not assume it.
Tool supply chain. Are MCP servers and plugin descriptors pinned and verified? Can a tool's output carry instructions back into the agent's loop?
Feed trust. Does the agent treat off-chain market data as data, or can that data carry instructions? Manipulating the feed the agent reads is cheaper than manipulating the on-chain oracle.
Kill switch. Is there a hard, code-level pause that does not depend on the agent cooperating? Above what value must a human co-sign?
Correlated failure. If this agent shares a model or strategy with other protocols, model the synchronized-action scenario — not just the single-account one.
Decision auditability. Can a large allocation or a liquidation be reconstructed and explained after the fact? A black-box policy on irreversible actions is itself a finding.

Where this leaves us

Agentic DeFi is not hype and it is not a toy. Real capital is under agent control today, the products are shipping, and the efficiency argument is real. But the security model has quietly shifted, and most of the industry's tooling has not caught up. The audit that mattered two years ago — a careful read of the Solidity — is now necessary and no longer enough, because the most exploitable actor in the system is a language model that will sign whatever the right text convinces it to sign.

The research is unambiguous that prompt guardrails do not hold. The one public incident proves the attack is practical and irreversible. The standards that exist solve identity rather than runtime safety. The defensible position is least agency enforced in code at the privilege boundary, plus a review that spans the agent and the contract as a single system rather than auditing the contract and trusting the agent.

If you are preparing for an audit of a system with AI components, start with what smart contract audits actually cost and their ROI, then understand how to scope an audit correctly for a system that spans Solidity and an LLM reasoning layer.

Frequently asked questions

What is agentic DeFi (DeFAI) and how does it differ from traditional DeFi?

Agentic DeFi — often called DeFAI or AgentFi — refers to DeFi protocols where large language model agents have direct, autonomous signing authority over on-chain wallets and can execute transactions without human approval for each action. Traditional DeFi relies on deterministic smart contracts that execute exactly their coded logic. Agentic DeFi adds a probabilistic reasoning layer: the LLM decides what to do based on context, and the result is signed and broadcast. This changes the trust model entirely. In traditional DeFi, you audit the Solidity. In agentic DeFi, the agent itself becomes a privileged actor that can be manipulated — and the smart contract faithfully executes whatever the agent sends it, including a malicious transfer triggered by a memory injection attack.

What is memory injection, and why is it more dangerous than prompt injection?

Prompt injection is an attack where a malicious instruction appears in the agent's current input — for example, a user message or an API response that overrides system instructions. Memory injection is a related but structurally different attack: the attacker writes a malicious instruction into the agent's persistent memory store, so it survives across sessions and is treated by the agent as its own trusted prior knowledge, not as external input. This makes it harder to detect, harder to block with input filters, and more dangerous because it can be planted on one platform and trigger on a different one — the Real AI Agents with Fake Memories paper demonstrated cross-platform memory injection on ElizaOS connected to live Ethereum, producing unauthorized on-chain transfers. Prompt-based defenses (well-crafted system prompts, input sanitization) are fundamentally inadequate against memory injection, because the injected state bypasses those defenses entirely.

What happened in the Grok and Bankr drain of May 2026?

On May 4, 2026, a Grok-linked wallet operating through the Bankr platform lost approximately 3 billion DRB, worth roughly $150,000 to $180,000, in a three-step attack. First, the attacker sent a Bankr Club Membership NFT to the wallet — receiving this NFT silently expanded the wallet's permissions inside Bankr to include transfers and swaps, a privilege escalation path triggered by an inbound asset with no action required from the wallet holder. Second, the attacker posted an instruction encoded in Morse code as an X (formerly Twitter) reply, bypassing Bankr's input filter. Third, the agent decoded the message and executed a transfer of the full DRB balance to the attacker's address. This was the second drain of the same wallet — after the first incident in March 2025, Bankr had blocked Grok responses specifically. The NFT permission path routed around that block. About 80–88% of the funds were returned voluntarily under public pressure; this was not a protocol-level recovery mechanism.

What is the OWASP Top 10 for agentic applications?

The OWASP Top 10 for Agentic Applications was published in December 2025 as a framework for classifying the primary risk categories in AI systems that take autonomous actions. It covers: Agent Goal Hijack (prompt and instruction manipulation), Tool Misuse and Exploitation, Identity and Privilege Abuse, Agentic Supply Chain Vulnerabilities (covered in our OWASP ASI04 analysis), Memory and Context Poisoning, Cascading Failures (correlated agent behavior), Excessive Agency (agents with more authority than tasks require), and others. The governing principle across all items is least agency — the agent should hold the minimum authority required for the task it is performing, bounded in code rather than in natural language. The OWASP list provides a shared taxonomy that audit teams and security researchers can use to classify findings in agentic systems, where the attack surface spans both the software layer and the reasoning layer.

Does ERC-8004 protect agents from being hijacked or manipulated?

No — not directly. ERC-8004 (Trustless Agents), deployed on Ethereum mainnet as of 2026, defines three on-chain registries for AI agent Identity (built on ERC-721), Reputation, and Validation. It allows counterparties to verify which agent they are dealing with and what its historical behavior score is before transacting. This raises the cost of impersonation and Sybil attacks, and the Validation Registry can layer stake-secured re-execution or ZK-ML checks for high-value interactions. What it does not address is runtime safety: a correctly-identified, high-reputation agent that gets memory-injected mid-task will still execute the attacker's instructions, and ERC-8004 provides no mechanism to intercept that. Payments are explicitly out of scope of the standard. Identity is necessary — but the Bankr incident involved a correctly-operating, identifiable agent that was manipulated through a permission path, not an impersonation. Identity infrastructure does not defend against that class of attack.

What does "least agency" mean in practice for a DeFi agent deployment?

Least agency is the principle that an AI agent should hold the minimum on-chain authority required for the specific task it is performing — and that this authority should be enforced in code, not in the system prompt. In practice this means: the agent's signing key or session key is constrained by a smart contract policy that hard-limits destination addresses (allowlist), per-transaction size, per-epoch total movement, and asset types. Transactions above a defined value threshold require multisig co-signature from a human. The agent cannot modify its own policy. There is a code-level kill switch that does not depend on the agent cooperating. Least-privilege tool scoping extends this to the tool-connector layer: each external tool the agent can call is granted only the data access or action scope required for that tool's function, not the maximum scope the connector technically supports. The goal is to ensure that even a fully-compromised agent — one whose reasoning layer is completely under attacker control — can cause bounded, recoverable harm rather than catastrophic, irreversible loss.

Get in touch

If your protocol is deploying AI agents with on-chain signing authority — or planning to — the attack surface described in this article is already part of your threat model, whether you have accounted for it or not.

At Zealynx, we combine smart contract auditing with AI security testing. Our team conducts security assessments specifically designed to stress-test autonomous agentic AI systems against prompt injection, memory injection, privilege escalation via inbound assets, and cross-platform attack chains — alongside the Solidity contracts those agents call.

What we can help with:

Agentic DeFi security assessments — end-to-end review of your agent's architecture, from input layer to signing policy to smart contract
Memory and prompt injection testing — adversarial simulation across direct, indirect, cross-session, and cross-platform attack chains
Privilege boundary review — audit of every path that can widen an agent's on-chain authority, including inbound assets and tool descriptors
Smart contract audits — comprehensive Solidity and cross-chain security reviews, including ERC-4337 session key policies
Correlated failure modeling — multi-agent cascade scenario analysis for protocols that share models or thresholds

Book a free consultation to discuss your protocol's agentic security posture, or explore our audit process to understand how we work.

Get funded for your audit

Core grants cover up to $32k. Growth and Builder tiers available. Rolling applications.

No spam. Unsubscribe anytime.