A treasury desk I have worked with since the 2022 unwind pushed an AI agent into production last quarter. The agent runs a Model Context Protocol client against an internal tool server. The tool server holds a signing key. That key can move size across four on-chain venues and one custodial API. When I asked for the authorization document โ the artifact that states in plain language what the agent may do and what it may not โ nobody could produce it. The permission model existed as a comment in a YAML file and a memory inside one engineer's head.
That is the finding. Not a hack. Not a drain. Just an authorization model with no version control, no expiry, and no revocation path.
The same pattern is replicating across crypto-native shops. Agents are moving out of the chat window and into the execution path. Q&A became task execution. Task execution requires credentials. The moment an agent holds a signature-capable credential, it stops being software and becomes a counterparty.
The code does not lie, but it does hide.
Corporates are having the same argument right now, one layer up. The security industry is loudly repositioning around AI agents entering the internal network, with the usual consequence: a new product category, a new acronym, a new budget line. The on-chain version of that story is already live, and it is worse, because on-chain there is no perimeter to defend. Every address is public. Every function is callable by anyone. The agent's key is the only thing standing between a prompt string and settled value.
Let me be precise about what changed, because the hype is obscuring a fairly simple engineering fact.
For two years, LLM deployments in finance were read-only. They summarized, classified, drafted, and scored. The blast radius of a wrong output was a wrong number on a dashboard. Then tool calling matured, then function calling became a commodity, then MCP shipped in November 2024 and gave every tool server a standard interface. Overnight the same model that used to write a memo could call transfer, approve, swap, and withdraw. Agent frameworks followed โ including crypto-native ones with wallet adapters bolted on, where the onboarding flow hands a freshly generated keypair to a language model and calls it autonomy.
That is a category error. Handing a model a private key is not giving it autonomy. It is giving it your capital and calling the arrangement a feature.
Here is the technical reality the marketing skips. An AI agent in a crypto stack has three distinct capabilities, and they fail in three different ways: it can read state โ prices, balances, mempool, calldata; it can decide, meaning plan, rank, and sequence; and it can sign, meaning authorize irreversible state transitions. Only the third has permanent consequences. Almost all of the current security spend is aimed at the second, because the second is where the interesting research lives and where the demos look impressive. The losses will come from the third, because that is where the money is.
The market backdrop makes this worse, not better. Bull markets fund the fastest version of every architecture, and the fastest version of agent custody is the one with the fewest checks. I have watched a nine-figure agent platform raise on a deck whose security section was three slides long and whose wallet integration was two commits old. That is not a crypto-native sin. In 2017 I watched the same thing happen with ICOs and token contracts โ narrative shipped, audits deferred, and everyone convinced themselves the sequencing was fine because the price was going up.
Start with the shape of the delegation, because the shape determines the entire risk profile. There are three deployment patterns in production right now, and they are not equivalent.
Pattern one: the agent inherits a human's credentials. The agent calls a custodial API using a key issued to a person. This is the most common pattern and the least defensible, because there is no separation between human action and agent action in the audit log. If the key leaks โ through prompt injection, a compromised dependency, or a plain log file โ there is nothing to revoke that does not also break the human's access. I have seen this pattern in three separate shops. In each case the API key had a longer half-life than the strategy it was funding.
Pattern two: the agent operates a delegated session key. This is the architecture smart accounts made possible. The treasury holds a master account; the agent receives a scoped signer with an allowlist of target contracts, a spend cap, an expiry, and optionally a paymaster that sponsors gas only for approved calls. ERC-4337 and the modular account standards built around it made this practical; EIP-7702 pushed the same capability down to ordinary externally owned accounts. This is the only pattern where revocation is a transaction rather than an incident response.
Pattern three: the agent is the keyholder. A hot key, generated at deploy time, written to an environment variable, with full signing authority over the balance. This is not a security design. It is a countdown.
The industry is converging on pattern two, and the convergence is real, but the migration is slow because pattern three ships faster. Session keys require you to define scope, and defining scope requires you to know what your agent does. Most teams do not, precisely because they deployed it fast enough that nobody wrote it down.
The second issue is that the chain is an adversarial prompt surface, and almost nobody prices that in.
Consider what an agent ingests when it decides to trade. It reads token names, symbol strings, metadata URIs, NFT descriptions, memo fields on incoming transfers, and decoded calldata from counterparties. Every one of those is attacker-controlled text. A model that treats its context as instructions will treat a token named with an imperative sentence as an instruction. This is the same class of bug as SQL injection wearing new clothes, and the mitigations have the same shape: never let untrusted data reach the control plane, treat all external strings as data and never as commands. The difference is scale. A SQL injection is a bounded query against a bounded schema. A prompt injection against a signing agent is an unbounded capability invocation, and the schema is your entire balance sheet.
I audited a Uniswap v1 fork on testnet in 2017 and found an integer overflow in the liquidity pool math before mainnet. The lesson I took from that was not that math is dangerous. It was that the exploit always lives one layer below where the team is looking. In 2017 everyone was reading whitepapers. In 2026 everyone is reading benchmark scores. The vulnerable layer is the one where a string from an untrusted source becomes a parameter in a state-changing call, and that layer is not measured by any benchmark you can buy.
Now the identity problem, which is where on-chain systems diverge hardest from their enterprise counterparts.
Enterprise identity management assumes rotation. Credentials expire, keys roll, access is re-attested quarterly, and a departed employee's token stops working on a known date. On-chain identity has no rotation primitive. A private key is a bearer instrument with infinite maturity. There is no directory to query, no session to invalidate, no administrator to call. If an agent's key is compromised, the compromise is permanent and the only remediation is to move the assets, which is itself a state-changing operation that the attacker may be able to front-run.
This means the entire non-human identity problem โ the thing enterprise vendors are about to build a category around โ has to be solved at the account layer on-chain, not at the credential layer. Smart accounts with modular validators are the closest thing to a solution. A session key with a hard expiry, a target allowlist, a per-period spend cap, and a guardian that can revoke without a signature from the agent is a rotation primitive by construction. It is not a general-purpose one, but it is the only one that exists, and it is enough if you design for it deliberately instead of bolting it on after the incident.
The third issue is trust propagation across multiple agents, and it is the part I expect to be genuinely novel rather than merely risky.
Real deployments are not one agent. They are an orchestrator that decomposes a goal into subtasks and hands those subtasks to specialists โ a research agent, a quoting agent, a settlement agent. This is the standard multi-agent pattern, and it has a well-known failure mode from the security literature: the confused deputy. The orchestrator has broad authority and narrow judgment. The specialist has narrow authority and no idea who is actually asking. A prompt injection that reaches any leaf agent in the tree can, in the right configuration, be laundered upward into an operation the orchestrator would never have authorized directly โ because the orchestrator sees a legitimate tool call from a trusted child, not the text that produced it.
Permission inheritance in these systems is almost always implicit. The sub-agent runs under the orchestrator's credentials, or under a child session key derived from the parent with the same scope. Nobody writes down the effective permission set of the leaf, because it is not written down anywhere. It emerges from the call graph. That emergent permission set is the real attack surface, and it is invisible to every policy engine that reads config files.
Add machine-to-machine payment rails to the picture and the surface widens again. Once agents can pay each other โ per-request micropayments, x402-style settlement, pay-per-call tool access โ the counterparty set stops being a known list of contracts and becomes an open market of anonymous services, each of which receives data from your agent as part of the request. Now prompt injection is not just an input vector. It is a business model.
The freshness problem is the one I care about most professionally.
An agent's decision is only as good as the timestamp on the data it decided from. Volatility is the tax on uncertainty, and the tax rate is set by your data's staleness, not by your model's intelligence. During the Terra collapse in May 2022 I pulled capital out of Curve pools manually, ahead of the bridge compromise, because the oracle feeds were quoting prices that had already stopped existing. I spent the following week reconstructing the failure in Python. The feeds were not wrong in the sense of being manipulated on-chain. They were wrong in the sense of being late. Stale prices, faithfully retransmitted, are indistinguishable from correct prices until they are not.
Now put an agent on top of that. The agent does not know the feed is stale. It sees a number, ranks it against its context, and signs. In a human workflow, the trader notices the spread looks wrong and picks up the phone. In an agent workflow, the spread looking wrong is the entry signal. Latency in the oracle becomes direction in the order flow, and the agent is on the wrong side of it by construction. Every team deploying an execution agent should be able to answer one question: what is the measured staleness of every feed in the decision path, in milliseconds, at the ninety-ninth percentile? Almost none of them can.
Alpha hides in the friction of liquidity, which is another way of saying the edge belongs to whoever sees the flow first. An autonomous agent executing against a public mempool is not just exposed to MEV โ it is a gift. Intent leaks before settlement lands. Every retry, every reverting simulation, every replacement transaction broadcasts what you are about to do. A human trader obscures intent through order slicing and venue selection. An agent that retries naively is a labeled dataset of its own future.
The fix is architectural, not model-level: private orderflow, deterministic retry logic with jitter, and a mandatory simulation pass that never touches the public mempool. Most agent frameworks ship none of these, because they optimize for whether the agent completes the task โ and the task completes fine while the edge bleeds out through the fee.
Now the audit problem, which is where I think the next real loss originates.
On-chain settlement is the most transparent ledger in financial history, and that transparency is nearly useless for agent attribution. You can see that a given address called withdraw. You cannot see which principal โ human, scheduled job, or model โ constructed the intent. The reasoning trace lives off-chain, in a log that may or may not be retained, in a format that may or may not include the tool call that produced the transaction. When the post-mortem happens, the on-chain evidence tells you what happened and the off-chain evidence is gone. I have done this exercise twice. The second time, the agent's context window had already rotated and the intermediate reasoning was unrecoverable. It was like arriving at a crash site where someone had removed the flight recorder and kept the black box closed.
Check the gas, then check the truth. Cost telemetry is often the only durable record of agent behavior, because it is the one thing that touches the chain. An agent that suddenly triples its transaction count is doing something different, whether or not anyone changed the prompt. Watching gas is a crude behavioral baseline, but it is a baseline, and right now most desks have none.
That brings me to the economics, which is where this whole trend gets mispriced.
In 2020 I ran capital through auto-compounding vaults and hit roughly 400% APY at the peak. I rebalanced manually every week, tracking gas against yield, and the discovery was mundane and total: yield is never free; it is rented, and the rent is paid in transaction costs. Compounding every block looked better on a chart than compounding weekly, and it lost to weekly compounding after fees. The optimum was not more automation. It was automation bounded by a cost function.
Agents are about to relearn this at scale, with two new variables. First, agent-driven execution is high-frequency and low-notional by nature, which is the worst possible gas-to-alpha ratio. Second, and this is the part nobody has priced, agent execution is about to become the dominant consumer of blockspace and blobspace.
Post-Dencun, blob fees collapsed and rollups repriced their economics around cheap data availability. That pricing assumed the demand curve came from human users and a handful of DeFi protocols. It did not account for a fleet of autonomous agents each polling, simulating, and retrying across a dozen venues. Blob consumption is a function of transaction volume, and transaction volume is about to be driven by machines that never sleep and never get bored. The saturation the current fee curve treats as a tail scenario is, on present trajectory, a two-year problem. When it lands, rollup costs reprice upward and every agent strategy whose edge was thinner than its data-availability cost stops working โ not because the model got worse, but because the substrate got expensive.
Backtest the assumption, not just the data.
Everyone is buying the wrong product.
The security industry has responded to agent risk the way it responds to every new surface: with a detection layer. AI firewalls. Prompt-injection classifiers. Agent behavior analytics. These are not worthless, but they address the second capability โ decision โ while the losses come from the third โ signature. You cannot classify your way out of a custody design that grants a language model an unconstrained signing key. The classifier runs in the same trust domain as the thing it is supposed to constrain. That is not a control. That is a suggestion.
The second blind spot is human-in-the-loop. Every architecture deck I have seen this year includes an approval step, and every one of them assumes a human who reads the request. Approval fatigue is not hypothetical. A desk processing a few hundred agent requests a day will, within two weeks, be approving on pattern match, and a prompt injection that produces a transaction in the expected shape will pass. The approval button is a control only if the approver can be wrong and lose something. When volume exceeds human attention, the button becomes a ritual.
There is also a regulatory blind spot that nobody wants to discuss on the record. When an agent signs a transaction that violates a sanctions list or moves client money without authorization, liability does not attach to the model. It attaches to the entity that deployed it, and possibly to the entity that built the signer, and certainly to whoever held the master key. Every architecture decision made today is a liability allocation made in advance. Teams are choosing their legal exposure with the same rigor they apply to choosing a logging library.
The third blind spot is historical and worth naming. In 2017 I watched projects ship tokens on narrative and postpone audits. In 2026 I watch agent platforms ship wallet adapters on narrative and postpone permission models. Precision is the only hedge against chaos, and precision is expensive, slow, and invisible in a demo. That is exactly why it gets deferred โ and exactly why it is where the edge is. The desk that ships a boring, constrained, over-documented signing architecture will look slow for a quarter and be the only one still trading in two years.
Watch three numbers. Session-key adoption, measured as a share of agent-attributed signing volume rather than developer count โ that tells you whether the industry is actually fixing custody or just talking about it. The first publicly attributed agent-triggered loss above eight figures โ that is the event that converts this from a design discussion into a compliance requirement. And sustained blob utilization on the major rollups โ when the fee market starts repricing, every high-frequency agent strategy re-underwrites its own edge, and the strategies that survive will be the ones whose permission model was never the weakest link.
The question is not whether agents will trade. They already do. The question is whether the authorization model survives contact with a nine-figure prompt injection โ and whether anyone can prove, after the fact, which entity was supposed to be in control.
The tape does not care about your model. It only cares who signed.