
The seatbelt wasn’t invented because cars got faster. It was invented because we finally admitted the driver wasn’t the last line of defense. For two years, every conversation about agent safety has bet on a better driver — better prompts, better guardrails, better evaluations of what the model says. That bet is about to come due, and most agent contracts being signed right now are still writing it.
What isn’t in the procurement template: the model isn’t where the damage happens. The damage happens at the tool call — the moment an agent stops talking and starts doing: sending the wire, mutating the database, kicking off the deploy. There’s a specification for the layer that governs that moment. It’s Autonomous Action Runtime Management — AARM — and if you’re signing agent deals in 2026 and can’t articulate what it is, you are buying infrastructure you have no way to evaluate.
The boundary moved and nobody told procurement
The old security boundary was the model’s output. You watched what it said, filtered what it produced, logged what it generated. That worked when the worst-case outcome was a bad answer. It collapses the instant the worst-case outcome is an irreversible action executed at machine speed.
This isn’t a refinement of the old problem. It’s a different problem in a different place. Prompt injection, confused deputy, goal hijacking, memory poisoning, intent drift — none of these are language failures you can catch by reading the transcript. They’re runtime failures. They detonate in the half-second between the agent deciding to act and the action landing in a production system. Post-hoc logging tells you what happened after the wire cleared. That is not security. That is forensics.
The reason this matters to a buyer and not just a researcher: the category of product you’ve been purchasing — model evals, output filters, red-team reports on generated text — sits entirely on the wrong side of that half-second. It is watching the driver’s hands. It is not the seatbelt. And the gap between AI strategy and AI execution, which is where most organizations already lose, has just relocated to a place your contracts don’t describe.
Five steps that belong in the half-second
What AARM specifies is the loop that should occupy that half-second between decision and action. Five steps, deterministic and inspectable:
Intercept the action before it executes.
Accumulate the session’s context — not just this call, but what led here.
Evaluate it against policy and the agent’s stated intent.
Decide whether to allow it.
Receipt — record a tamper-evident record of what was permitted and why.
Notice what this is and isn’t. It isn’t a smarter model. It isn’t a better prompt. It’s a control plane that sits outside the agent, in front of the system of record, doing deterministic work at exactly the point where probabilistic systems become dangerous. The agent can be wrong, hijacked, confused, drifting — and the action still doesn’t land unless step four says so. That is the seatbelt logic, applied to software: don’t make the driver perfect, make the system survivable when the driver isn’t.
This is no longer a whiteboard idea. Earlier this year AARM crystallized from a research framing into a public specification on arXiv (February) and, in April, a Cloud Security Alliance Agentic Control Plane working group. Microsoft’s Agent Governance Toolkit now maps to all ten OWASP agentic risks at this layer. SAP and NVIDIA’s OpenShell collaboration is co-defining what enterprise-grade agent execution looks like. NVIDIA and ServiceNow are pitching bounded autonomy — sandboxed, policy-governed runtimes — as a recommended enterprise posture. The vendors have already started racing for this layer. The buyers, mostly, have not started asking about it.
The questions across the table are the wrong ones
Every founder I work with who is shipping agents into enterprise customers is fielding the same evaluation script. And it’s almost always pointed at the driver, not the seatbelt.
Buyers ask about model selection. They ask about hallucination rates. They ask for red-team results on the language output. Reasonable questions for 2023. They tell you nothing about whether an autonomous action can be stopped before it executes.
The questions they rarely ask are the ones that actually decide whether you’ve bought a control or a press release:
What intercepts the tool call?
What policy engine sits between the agent’s decision and the system of record?
Who signs the receipt — and is it tamper-evident?
Six months from now, what evidence will I hold that a wire your agent initiated was authorized by mine?
Those are the AARM questions. Map them back onto the five-step loop and you’ll see they aren’t a vendor’s marketing checklist — they’re just the loop, turned into procurement language. “What intercepts the tool call” is step one. “Who signs the receipt” is step five. A vendor who can’t walk you through all five in their own words doesn’t have a runtime control. They have a very good driver and their fingers crossed.
The window is the eight weeks you already missed
Here’s the uncomfortable timing. The category was a research paper eight weeks ago. It will be on every RFP template within a year. The deals signed in between — the ones being papered right now, this quarter — are being written without runtime-control language because the language didn’t exist when the relationship started.
That’s the trap. Leaders aren’t omitting AARM clauses because they decided runtime controls don’t matter. They’re omitting them because the vocabulary arrived after the deal was already in motion. By the time “intercept, evaluate, decide, receipt” is boilerplate, the agentic deployments that mattered most — the ones touching money, infrastructure, and systems of record — will already be in production under contracts that never specified how an autonomous action gets stopped.
This is the same gap that has always separated AI strategy from AI execution, except the failure mode is no longer a disappointing demo. It’s an irreversible action with no one between it and the wire.
So what: the one-quarter audit
Don’t try to understand agents better this quarter. Understand what governs them when they act. Concretely:
Pull every active agent vendor evaluation off the desk. For each one, write a single sentence describing what happens between the agent’s decision to act and the action executing in your environment. Just that span — the half-second.
If the sentence you can write is “the model is really good,” you have a driver and no seatbelt. If it’s “we log everything,” you have forensics — a record of the crash, not a prevention of it. Neither is a runtime control. In both cases the reality is: hope, with a paper trail.
Then require the loop in language, before signature. Intercept → evaluate → decide → receipt isn’t a feature wishlist; it’s the structure the field is converging on, the same structure the CSA working group and the OWASP mapping are formalizing. Your contracts should require it explicitly, in the body of the agreement, not infer it from a confident sales call. That is the work for this quarter — and it’s cheap to do now and expensive to retrofit after the agent is in production.
The seatbelt didn’t make drivers better. It made the system survivable when they weren’t. That is the bet AARM is making about agents: not that the model will always decide correctly, but that the one time it doesn’t, something deterministic stands between the decision and the damage. Your contracts should be making the same bet — and right now, most of them are still betting on the driver.
If you’re in the middle of an agent vendor evaluation, hit reply and tell me what your runtime controls look like. I’m reading every response, and the patterns across the startup portfolio are worth comparing notes on.
— Jason
Operator’s Log · jasonclewis.com