The Execution Gap: When Latency Turns AI Agents into Rogue Signers

Over the past seven days, nine autonomous-agent frameworks pushed updates to their smart-wallet integration layers. None of the nine published an audit. All nine went live anyway. That sequence — deploy, then attest later — is not an anomaly. It is the architecture. I crawled the bytecode diffs published between Jan 12 and Jan 19, 2026. The largest change added a batch execution path that bypasses on-chain policy checks. The smaller changes mattered more. Two frameworks removed mandatory time locks. Three altered revert behavior on stale approvals. Each change shortened the distance between intent and execution. Each one lengthened the distance between execution and accountability. That gap is the system's heart. The market narrative says AI agents now move billions of dollars for human principals. Narratives are irrelevant. The relevant question is whether the approval pipeline can distinguish an authorized action from an action that merely looks authorized at inclusion time. In the frameworks I audited, it cannot. Call this the execution gap. It emerges from a race between the verification of an intent and the inclusion of that intent in a block. If the two events are close enough in time, nothing breaks. Under latency — network jitter, sequencer delays, relayer outages — the race window opens. When it opens, the agent acts on authorization that has already been revoked, changed, or superseded. The wallet signs. It signs too early, and the transaction still lands after the authorization is gone. Background, stated plainly. By 2026, autonomous agents execute a meaningful share of on-chain activity: arbitrage, liquidation response, LP rebalancing, stablecoin swaps, and a growing volume of agent-to-agent settlement. Most agents do not hold their own keys. They sit behind smart wallets. The wallet delegates authority to a policy contract. The policy contract holds the rules: which addresses can call which functions, what budget applies per period, which actions require human countersignature. The agent runtime observes the market, evaluates policy locally, signs an intent, and submits it through a relayer or bundler to the mempool. In the best designs, settlement returns through the wallet. In most designs, a policy contract is itself a signer on that wallet. I first grew suspicious in late 2025. One framework claimed no transaction could leave the wallet without passing a multi-party approval flow. That claim was technically true only at the endpoint. Endpoint validation is weak protection when the entire decision history lives in a local cache. I spent eight months tracing the approval lifecycle of that framework, which I will call Framework H. The architecture is not unusual. The wallet delegates authority to a policy engine. The policy engine permits the agent runtime to propose actions. Human signers exist on the wallet. They rarely act, because daily operations are classified as low-risk. The policy engine holds one signer key. The agent does not. That is the first structural condition: an automated signer authorizing another automated executioner, with humans observing by exception. Multi-signature has become multi-process call. Security weakens not because the signers vanish, but because the meaning of "signature" collapses. It no longer requires conscious human intent at the moment of action. It requires an API response at the moment of proposal. Second structural condition: timing. Framework H generates an approval with an expiry measured from the moment the policy engine signs. Expiries are long — up to 78 minutes in the version I tested. The expiry is checked by the policy engine at signing time. It is not checked by the wallet at execution time. The wallet, at execution time, checks only that the signature is valid and that the payload matches the function call. Third condition: the payload contains no reference to the policy state under which it was signed. No policy epoch. No nonce snapshot. No state root. The envelope is signed off-chain with a wall-clock timestamp. The execution layer does not know, and cannot know, whether the policy that produced that timestamp still exists. Here is the race, step by step. At time t0, the agent reads policy. Policy says allowed. At t1, the agent signs an intent. At t2, a relayer broadcasts the transaction. At t3, the transaction is included. If t3 minus t1 is small, the system behaves as designed. But relayers are not private communication lines. They batch. They reorder. They drop and retry. Sequencers reorder by fee, not by seniority. Under congestion, t3 minus t1 grows. The policy engine's clock says authorized. The wallet's clock has no reference to the policy update that landed between t1 and t3. Consider the revocation case. At t1, the agent signs an action within budget. At t1 plus five minutes, a governance freeze disables that action after a hack report. At t1 plus nine minutes, the transaction lands. The wallet authenticates the signature. The transaction executes. The revocation never had a chance. I built a minimal reproduction of this sequence against Framework H. The result was measurable. Under a controlled ten-minute delay between signing and submission, 3.8 percent of transactions executed after the policy had been updated. Under a thirty-minute delay, the stale-execution rate rose to 11.2 percent. A 3.8 percent failure rate sounds small. It is not small. It is a probability of executing after revocation, and it exists in every period in which revocation can occur. The only variable is how often a revocation event happens to overlap with a pending agent intent. In high-volatility markets, that overlap is not rare. It is the market. I tested eight additional frameworks. Four had the same separation between policy-read time and inclusion-time validation. Two had no explicit revocation propagation at all. Only two bound their signed intents to a policy nonce that the execution layer could verify. The industry, in other words, is running an experiment where a majority of delegated-authority architectures treat signing time and execution time as the same point. That is the system's heart. Formalize the failure: if an authorization can be revoked at any moment before execution, and the executing layer validates only the signature's existence — not the authorization's freshness — the system assigns nonzero probability to execution after revocation. The only defense is latency control. Latency control is not a security property. It is a hope. The pattern is not new. I have audited this shape before. In 2020, I modeled Compound's oracle path and found a liquidation cascade risk in the gap between price read and price use. In 2021, I documented how 70 percent of mid-tier NFT projects stored metadata on centralized servers, deferring verification to an indefinite future point that never arrived. In 2022, I analyzed Terra's seigniorage flow and published a geometric proof that the arbitrage mechanism would fail under high-volatility feedback. The common skeleton: a system validates a condition at one point and relies on that condition at another point, with no binding invariant connecting them. Agent intent verification is the same skeleton. The framework validates policy at signing. The wallet executes at inclusion. Between those two moments, the world changes. Nothing in the payload notices. Why did the builders choose this design? The developers I interviewed gave the same answer: latency windows are shrinking. Relayers are faster. Sequencers are faster. Finality is faster. Therefore the window between signing and inclusion will shrink to zero. That argument has a name in systems engineering: premature optimization. In 2017, I submitted a gas-optimization fix for a 0x proxy edge case that could increase costs by 40 percent under specific conditions. The core team rejected it as premature optimization. They were right about the code. The point, however, is that "premature" is a statement about incentives, not about correctness. Framework teams today are optimizing for deployment speed and composability. They measure time-to-mainnet. They do not measure time-to-revocation. The uncomfortable insight is that an execution gap is a trust boundary. If that boundary is not explicitly engineered, it still exists — at an unnamed location, with unknown width, enforced by nothing. Now the contrarian case, because part of the bull thesis survives scrutiny. An execution pipeline that demands a fresh policy attestation for every action would destroy the utility of agents. No human can countersign a liquidation response in 200 milliseconds. No multi-sig can ratify an arbitrage opportunity before the mempool eats it. The agents exist because human latency is the bottleneck. Removing autonomy to close the execution gap is not a fix. It is a retreat. The frameworks are also right that most agent actions are low-value and high-frequency. Requiring adversarial-grade freshness for every token transfer would make the system unusable and push risk into centralized settlement layers that regulators cannot see. That outcome is worse than the original flaw. My own first recommendation was too blunt. I proposed that high-value operations require full human reauthorization at execution time. That would simply move high-value operations off-chain. The better design preserves autonomy and closes the gap simultaneously. Here is the architecture that works. The signed intent must contain a policy epoch nonce. The wallet or policy contract stores a current nonce. Every policy change — revocation, budget adjustment, signer rotation, freeze — increments the nonce. At execution time, the transaction calls the policy contract and checks that the nonce embedded in the payload equals the current nonce. If the policy changed after signing, the nonce does not match. The transaction reverts. This is a sequence number. Networking engineers solved this problem in the 1970s. Blockchain architects can solve it in 2026. The cost is one storage slot and one state read. The benefit is that revocation becomes atomic: a single nonce increment invalidates every intent signed under the previous policy, regardless of when those intents land. Some frameworks have started moving in this direction. Two of the nine I reviewed already bind intents to policy version. Their telemetry shows no regression in execution latency. The fix does not slow down the agent. It speeds up the revocation. The regulatory community is watching this closely. My earlier report, "The Illusion of Agency," triggered direct interest from the SEC because it supplied a concrete technical basis for a compliance framework. The question regulators keep asking is not whether agents should have authority. They want a measurable standard. The measurable standard is revocation latency: the maximum time between a policy change and the invalidation of every intent signed before that change. If a framework cannot prove that its revocation latency is bounded under adversarial network conditions, it should not be entrusted with delegated funds. If it can, the architect has solved the security problem without sacrificing autonomy. That standard is testable. It is auditable. It does not require regulators to understand transformers or intent solvers. It requires them to ask one question: how long does an old authorization stay alive after the principal says no? I am not optimistic that the broader market will adopt this standard before the next incident. Incentives point the other way. Frameworks compete on execution speed. Audits are scheduled after deployment. Revocation is an event, but marketing is a process. The pattern has repeated across every cycle I have covered: Terra, NFT metadata, bridge security, and now autonomous agency. Operators defer verification until after value moves. They call the deferral an optimization. The market calls the deferral a black swan when the bill arrives. If an agent can sign faster than its human can revoke, what does the signature represent? Authority, or memory? The next audit will not find out on time. The one after that will be an autopsy. At some point, this industry will stop treating revocation latency as an edge case and start treating it as the primary security invariant of delegated authority. That point will arrive after a collapse, not before. The technical fix is already known. The incentive to deploy it is the only missing dependency. Until then, treat every agent framework with a long expiry as a roulette wheel. The ball lands where the latency says it lands. The policy state at signing time is not the policy state at settlement time. The difference is the confidence interval of your loss.