The Agent Signed It
The transaction was valid. That is the part nobody wants to hear.
Block 21,847,332. A session key delegated by a treasury multisig called transferFrom on a USDC vault, moved 1,411,208 USDC to an address with no prior history, then called revoke on itself. Gas paid: 0.00041 ETH. Total elapsed time from injection to settlement: 38 minutes.
The incident report called it an "AI agent compromise." I called it a Tuesday.
I have spent the last fourteen months auditing systems where language models hold signing authority — some on-chain, some in enterprise networks that will never touch a chain. The pattern in every one of these engagements is identical, and it has nothing to do with the model. The agent had a valid credential. The agent had a scoped permission. The agent did exactly what its permission set allowed it to do. Somewhere upstream, a human pasted a document into a context window, and the document contained a sentence the model interpreted as an instruction.
The exploit was in the trust, not the contract. The contract did what contracts do. It executed.
That distinction matters more than the $1.4M. Because every security budget in this cycle is being allocated against the wrong layer.
Context: From Answering to Signing
Let me state the industry shift in the least dramatic terms possible, because the marketing version of this story is already dense enough to hide in.
For roughly three years, enterprise AI was a read-only technology. A model read documents, summarized tickets, answered questions, drafted emails a human sent. The blast radius of a mistake was embarrassment. The security control that mattered was data leakage — does the model memorize my source code, does the vendor train on my prompts, does the context window cross a jurisdiction. Those were real questions. They were also the wrong ones for what came next.
That era ended quietly, in integration tickets, not in press releases. Agents got tools. Tool calling turned into function calling, function calling turned into API connectors, connectors turned into credential vaults, and credential vaults turned into write access. The Model Context Protocol standardized the plumbing so that a single JSON manifest could hand an agent a filesystem, a database, an email account, and a payment rail in the same session.
Nobody shipped a headline about this. They shipped changelogs.
The crypto side moved faster, because crypto has no procurement committee. Agent frameworks with embedded wallets. Agent marketplaces where you hire a bot to rebalance a position. "Autonomous" vaults that route capital based on model output. A wallet is just a key. Give a model a key and you have given it a signature. Give it a session key with a scoped allowance and you have given it a signature with a leash — which feels safer and is not, because the leash is defined in code that was written by someone optimizing for throughput, not for revocation.
In the twelve months I have been tracking these deployments, the failure mode has not drifted. It is always one of four things: an over-broad delegation, a tool registry that trusts unsigned manifests, a permission revocation path that nobody tested, or an audit trail that records the HTTP request but not the reasoning that produced it.
Note what is missing from that list. The model. The model is almost never the root cause.
That is the uncomfortable finding. Security teams are buying model guardrails while the exposure sits in the identity graph.
Core
1. The Delegation Chain Is the New Kill Chain
Traditional intrusion analysis follows a kill chain: reconnaissance, initial access, execution, persistence, lateral movement, exfiltration. On-chain, that framework collapses. There is no lateral movement. There is only authorization.
When an agent acts on behalf of a human, the authority flows through a chain: human → application → service account → agent identity → session key → target contract. Every hop is a place where scope can widen. Every hop is a place where a revocation can fail silently. Every hop is a place where a policy document says one thing and a storage slot enforces another.
I have a habit in audits. I do not read the permissions. I read the reverts.
Permission documents describe intent. Revert strings describe enforcement. When I traced the treasury incident above, the permission manifest said the agent could move "up to 2% of vault TVL per day, whitelisted destinations only." Good policy. Clean. The manifest was correct. The enforcement was not.
The session key had been issued with an allowance parameter that the issuing module read as an absolute value, not a rate. Two percent of TVL was the intended cap. The enforced cap was a flat number that happened to equal two percent at issuance. TVL grew. The cap did not. The manifest kept claiming a percentage. The code kept applying a constant.
That is not an AI vulnerability. That is a units bug with an LLM attached.
But here is what the LLM changed: it converted a latent bug into a live exploit vector. Before agents, that allowance parameter needed a human to press a button. The misconfiguration would have sat there, harmless, until an auditor found it and wrote a ticket. With an agent holding the key, the misconfiguration is a loaded weapon sitting in a room where anyone who can write convincing text has a hand on the trigger.
Code does not lie, but incentives do. The incentive here was convenience. The agent needed a key that worked without a human in the loop, because a human in the loop defeats the purpose of the agent. Every convenience parameter added to make the agent useful is a parameter that widened the chain. Autonomy and least privilege are not friends. They are negotiating.
The leashes are always looser than the documentation.
2. Prompt Injection Is a Signing Primitive
I need to be precise about what changed, because "prompt injection" has become a phrase that means everything and therefore nothing.
Injection in a read-only system is an information disclosure risk. An attacker who controls text that reaches the context window can influence output. Consequences: misinformation, data exfiltration through the response, reputational damage. Serious, contained, bounded.
Injection in a write-capable system is a control-plane attack. The attacker is not asking the model for information. The attacker is asking the model to construct and submit a payload. The model is the execution engine. The context window is the attack surface. The signature is the exfiltration channel.
The second case has no clean mitigation in current architecture, and anyone selling you one is selling you something else. Here is why. The model's job is to interpret natural language and map it to tool calls. That is the feature. An injected instruction is natural language that maps to a tool call. The attack and the function are the same mechanism. You cannot build a filter that separates "legitimate instruction the user intended" from "illegitimate instruction an attacker embedded," because intent is not a property of the text. It is a property of the principal, and the model has no reliable way to see the principal. It sees a token stream. Both instructions live in the same stream.
In the on-chain case, this gets worse in a specific and underdiscussed way. The model's output is not advisory. It is a transaction. Once signed, it is final in the strongest sense any computing system offers. There is no rollback. There is no incident response that reverses the ledger. There is only the next block.
I pulled the calldata from three separate agent platforms during a 2026 review of their payment routing logic. What I found was not exotic. The agent constructed a batched call: approve, swap, transfer. Standard. The routing logic checked the destination against a whitelist held in a mutable storage slot. The slot was writable by the same key the agent held. So the "whitelist" was a suggestion the agent could update on its own authority.
If an injected instruction told the agent to add an address to the whitelist and then route funds to it, the contract would accept both steps as authorized. No reentrancy. No overflow. No compiler bug. No oracle manipulation. Just a permission model that assumed the principal and the executor were different entities, when in this deployment they were the same key wearing two hats.
Reentrancy was still the bug I reported, incidentally — a delayed model response created a window where the routing function could be re-entered before state settled. But the reentrancy was the symptom. The disease was that the agent could edit its own guardrails. Nothing in the deployment prevented the executor from rewriting the rules under which it executed.
3. Latency Is Where the Money Dies
Oracle latency gets attention because it has a body count. Chainlink feed delays, stale prices during volatility, liquidation cascades that liquidate solvent positions because the last update was ninety seconds ago. I have written about this before and I will keep writing about it, because replacing decentralized feeds with a consortium of permissioned nodes and calling it a solution is an alibi, not an architecture. Decentralization purchased by re-centralizing the signers is a currency that does not survive its first stress test.
Agent latency is the same disease with a new patient.
An autonomous agent does not act instantaneously. It calls a model, the model reasons for somewhere between 400 milliseconds and 40 seconds, the tool call executes, the response comes back, and the model decides the next step. Every step is a round trip. Every round trip is a window. A window is where a state assumption goes stale.
My stress model for the treasury engagement simulated a 12-step agent workflow under three conditions: normal load, degraded inference (model endpoint at 3x latency), and partial failure (one tool returning a truncated response). The guardrails were straightforward — 2% daily cap, whitelisted destinations, sequential execution, one retry on failure.
Under normal load, the workflow completed in 9.4 seconds and the cap held. Under degraded inference, the workflow completed in 31 seconds and the cap held. Under partial failure, the agent received a truncated response, interpreted the missing fields as either zero or null depending on how the client deserialized the payload, and re-initiated the workflow. It re-initiated it three times before the idempotency check caught it.
The idempotency check caught it because I had flagged it in the prior review. In the version shipped to production three months earlier, the check was keyed on the request hash, and the truncated response produced a different hash.
Three attempts, each within the cap, each authorized. The aggregate was three times the cap.
The logic held until the liquidity dried up. In this case the liquidity did not dry up, because the destination was a cold wallet with a rate limiter. In the next deployment, it will not be.
This is the class of failure that traditional audit does not catch, because traditional audit assumes deterministic execution. An agent that behaves correctly 99.7% of the time is not a system with a 0.3% defect rate. It is a system whose defect rate is amplified by the number of decisions it makes per hour, and whose failures cluster in exactly the conditions where you need it most: high volatility, degraded infrastructure, partial outages, and the moment when a human is least available to intervene.
Probabilistic systems do not fail gracefully. They fail competently.
4. Non-Human Identity Has No Legal Person
Here is the part that will matter in a courtroom in 2027 and is being ignored in 2026.
A DAO has the legal status of a group chat. That has been true since the first multisig, and the industry has papered over it with foundation wrappers, legal opinions nobody reads, and the quiet hope that no one sues. When members vote, they are not exercising a shareholder right. They are issuing an instruction to code with no corporate veil behind it. When things go wrong, unlimited personal liability is not a theoretical risk. It is the default outcome of the structure.
Now put an agent in that structure.
Who is liable when an agent, holding a session key delegated by a treasury controlled by a DAO whose legal existence is a Marshall Islands entity that may or may not have standing, executes a transaction that drains a user's funds because a vendor's PDF contained an injected instruction?
The model provider? Their terms say the output is not advice and not guaranteed. Read them once, carefully, and you will never sleep well again about a deployment.
The agent platform? Their terms say the operator is responsible for configuring permissions.
The DAO? It has no officers, no board, no registered agent in most jurisdictions, and by the time the litigation starts, no treasury left to sue.
The human who pasted the PDF? Good luck. That person will say the agent had authority and they were doing their job. They may even be right.
I read the reverts before the headlines, and the reverts here say AccessControl: unauthorized. That is a technical statement. It is not a legal one. The chain will tell you who signed. It will not tell you who is accountable, and those are becoming different questions for the first time in the history of this industry.
Every agent deployment I have reviewed has the same gap: a technical identity with a cryptographic signature, and no corresponding legal identity with a name attached. The signature is verifiable. The responsibility is not. That asymmetry is the actual systemic risk — not the model, not the injection, not the latency. The system was built to prove what happened and structured so that no one has to answer for it.
The fix is unglamorous and nobody is selling it. Human-in-the-loop for irreversible actions above a threshold. Explicit named ownership for every agent identity. Delegation records with expiration times enforced on-chain, not in policy documents. A legal wrapper that actually exists and actually accepts liability.
None of this is novel. Companies have had approved signers and expense limits for a century. What is novel is that we deployed the automation before the controls, and the automation holds a private key.
5. Tool Registries Are npm in 2015
The supply chain layer deserves its own section because it is the least examined and the most re-usable attack surface.
An agent is only as capable as its tools. Tools are distributed as manifests, servers, plugins, connectors. The most consequential standard here — MCP — operates on the premise that a client can discover and invoke tools exposed by a server, with the manifest describing what the tool does.
That description is written in natural language. It is consumed by a model. It is not verified against behavior.
Stop and notice what that means. Silence is just uncompiled potential energy. A manifest that says "reads files from the project directory" and actually exfiltrates the contents of the SSH agent socket will be invoked by the model, because the model reads the description, not the code. This is not a hypothetical. It is the mechanism. The description is the interface the model reasons about, and the model has no independent way to confirm the description matches the implementation.
In 2015, npm's problem was that installing a package ran arbitrary code from a maintainer you had never met. The industry response took years and produced lockfiles, provenance, signing, and dependency review. The agent tool ecosystem in 2026 is where npm was in 2015, with one critical difference: a malicious npm package needed a developer to install it and a build to execute it. A malicious MCP server needs a model to read its description.
The blast radius is also structurally different. A compromised tool does not just run code. It runs code inside the agent's authority, which means inside the credential scope the operator granted. The tool inherits the leash. And the leash is the longest one in the building.
I have started refusing to certify deployments where tools are loaded from unverified registries, regardless of what the rest of the architecture looks like. It is not a defensible posture. You cannot sandbox your way out of a trust problem in the descriptor layer, because the descriptor is what the model uses to decide whether to call the tool. Sandboxing constrains execution. It does not constrain selection.
Signed manifests help. Behavior-based tool policing helps more: allowlisting the actual syscalls and network destinations a tool may touch, not the ones it claims. That is expensive, it is slow to operate, and it is the only thing that has held in every deployment I have reviewed. Expensive and boring has a better track record than clever.
6. The Regulatory Trap Waiting for Tool Authors
One more piece, because it is coming and the industry is not ready.
In 2022, sanctions were applied to a set of smart contracts, and a category error was baked into law: writing and publishing code became an action that could be attributed to a person as participation in a transaction. The precedent has not been overturned. It has been quietly extended in enforcement posture, even where the letter of it was challenged. Every developer who has ever shipped a public repository has been living with that precedent whether they noticed or not.
Now apply that framework to agents.
An agent toolkit that executes transactions is, functionally, a transaction execution service. If an agent built with a developer's tooling is used to launder funds or evade sanctions, the liability question will not stop at the operator. It will reach the tool author, because the tool author is the closest identifiable person in the chain. The operator will be an anonymous wallet. The tool author will have a GitHub handle tied to a real name.
I am not predicting this. I am reading the pattern. The same logic that made a privacy mixer's developers a target makes an agent framework's developers a target. The difference is that agents will be used at scale by enterprises that have nothing to do with illicit finance, which means the legal exposure will touch a much larger population of ordinary developers — people who wrote a payment-routing module for a hackathon.
There is no clean defense. Severability clauses and open-source licenses are not shields against sanctions enforcement, and anyone who tells you otherwise has not read an enforcement action recently.
The only posture that has any chance is architectural: tools that cannot perform the harmful action without an explicit, logged, human-authorized escalation. Make the dangerous capability require a human, and the developer's code is no longer the instrument. It is the plumbing.
That is a design constraint, not a legal strategy. It is also the only one that scales.
Contrarian
Now the part where I have to be fair to the other side, because the other side has a real point and dismissing it would make this analysis useless.
The bulls are right that the perimeter moved. They are also right that a lot of the fear is repackaged. I have watched three security vendors launch "AI firewall" products in nine months, each of them a prompt filter with a management console, each of them priced against a budget line that did not exist two years ago. Some of them are selling a threat model they have not measured against a single production incident. That is worth saying plainly, because fear is a sales channel and the industry has never once declined to use it.
Entropy always wins if you stop watching. But that is true of every perimeter we have ever built, and it does not mean the new perimeter is fictional.
Here is what the bears get wrong. The claim that "this is just IAM with a new logo" is technically correct and strategically useless. Yes, the failures are identity failures. But identity failures at this decision frequency are a different problem class. A human approves six transactions an hour. An agent approves six hundred. The controls designed for the first case do not degrade gracefully into the second. They fail open, at speed, in the exact conditions where your monitoring is under load and your on-call engineer is asleep.
And the genuinely underrated bull point: agent-driven security operations are working. In two of my engagements, agent-assisted triage cut the time from alert to initial containment by more than half. Not because the agents are brilliant, but because they do not get tired at 3 a.m. and they do not skip steps when the queue is long. The same capability that widens the attack surface also compresses response time, and pretending otherwise is how analysts lose credibility with the teams actually running these systems.
So the honest position is neither. The perimeter moved to identity, the risk is real, the products are half-real, and the budgets are being allocated by fear rather than by measurement. That has been true of every security cycle since firewalls. It is not a reason to ignore this one. It is a reason to buy differently.
Takeaway
The question is not whether agents will hold signing authority. They already do, in treasuries, in payroll systems, in vaults, in governance modules, in the payment routing logic of platforms that shipped before anyone wrote a threat model for them. The question is whether we build revocation scoping, delegation expiry, and reasoning-level audit trails before the aggregate value under agent control is large enough to make the failure systemic instead of embarrassing.
Trace the gas, find the truth. The chain will show you what was signed. It will not show you who decided it should be signed, which is the only question that will matter when the first nine-figure agent failure gets a name attached to it.
Who is on the hook when the agent had authority, the model had a disclaimer, the DAO had no legal person, and the human had a deadline?
