Your AI Agent Has No Seatbelt
Field Guide
Your AI Agent Has No Seatbelt
AI agents are shipping into production faster than safety standards can keep up. Teams deploying autonomous agents need runtime security controls before the first serious incident forces regulation on everyone.
Key takeaway
AI agents are deploying without runtime safety controls, mirroring the 60-year gap between cars shipping and seatbelt mandates.
Key takeaway
Every new capability follows the same cycle: excitement, deployment, incident, regulation. We're between steps 2 and 3.
Key takeaway
A 5-question self-assessment can tell you whether your agent has basic crash protection.
It’s 1965. Ralph Nader publishes Unsafe at Any Speed. The auto industry responds by saying people want speed, not seatbelts. They’re not wrong about the speed part. But they’re catastrophically wrong about what matters.
The car shipped. The seatbelt came 15 years later. And only because people started dying in ways that were too public to ignore.
AI agents are shipping right now without seatbelts. That’s the situation we’re in.
Answer-First Summary
AI agents are entering production without runtime safety controls, repeating the 60-year pattern of new transportation technologies shipping first and getting protected later. Every industry from aviation to finance went through this cycle: excitement, deployment, incident, regulation. We’re currently between deployment and incident. Building safety controls now beats having them mandated after someone gets hurt.
The Excitement Got Here First
We should celebrate what’s happening. Agents that reason across tools, chain decisions, and operate autonomously are genuinely cool. Teams are shipping them because they solve real problems. A logistics agent that optimizes routes and books trucks saves money. A customer service agent that routes, responds, and escalates saves time. Nobody’s wrong to be excited.
But excitement is a terrible advisor on safety. Humans are the same way. We sprint into new things with zero safety net because momentum overrides risk. We don’t wear helmets on new routes. We don’t ask for references on new partners. We assume “it’ll probably be fine.” Then someone gets hurt, and suddenly everyone agrees the seatbelt was obvious all along.
The problem is timing. We’re not at “suddenly everyone agrees.” We’re at “nobody’s talking about it yet.”
What We Know About the Cycle
IBM released deployment data in early 2026 showing agent deployments outpacing security infrastructure 3 to 1. That’s not surprising. It’s also not sustainable. Every technology that reached scale without safety controls eventually got regulated hard. Airlines thought seatbelts were theater. Banks thought encryption was optional. Hospitals thought error-tracking was lawsuit bait.
The pattern is mechanical: excitement phase, deployment phase, incident phase, regulation phase. We’re solidly in phase 2. Phase 3 is inevitable. The question isn’t whether regulation comes. The question is whether you want to define your own safety controls or have regulators define them for you.
Here’s what makes this different from other cycles. Agents are autonomous. A deployed agent can make decisions you didn’t explicitly approve, in combinations you didn’t test, at speeds you can’t interrupt. A human with bad judgment can be trained. A system with bad judgment can cause damage before anyone notices.
Which is exactly why runtime protection matters before the first serious incident, not after.
What “No Seatbelt” Actually Means
Your agent has no seatbelt if:
- It can make tool calls you didn’t enumerate or approve beforehand
- It can escalate its own permissions based on intermediate reasoning
- It has no runtime circuit breaker that stops execution on suspicious behavior
- Credential compromise doesn’t automatically limit what it can access
- You couldn’t answer “what’s the worst thing this agent could do” in under a minute
That’s five questions. If you answer “not sure” or “we’re planning to add that” to more than two of them, your agent is unbelted.
This doesn’t mean your agent is broken. It means it’s operating in the gap between “it works” and “it’s protected.” That gap is where incidents happen.
The Control That Matters
We’re not talking about shutting down agents or making them useless. We’re talking about runtime validation. Agents don’t need to be slower. They need to be bounded. A agent checking “am I allowed to call this tool right now” takes microseconds. An agent that can’t articulate why it needs a permission takes catastrophic risk.
Think of it like a bank teller. The teller can move money fast. But the teller can’t move any money to any place. There are guards. There are limits. There are alarms. The system trusts the teller to do the job. The system doesn’t trust the teller with unlimited authority.
That model scales perfectly to agents. You want your agent fast and autonomous. You don’t want it boundless.
What You Can Do This Week
- Run those five questions above. Write down your honest answers.
- Map what tools your agent actually needs. Not what it might be useful for. What it needs.
- Set execution limits. Token budget, tool call count, decision depth.
- Add a monitoring layer that logs every decision boundary crossing.
- Define what “breach of protocol” looks like, and what happens when it occurs.
This isn’t six months of work. It’s a weekend of thinking and a sprint of implementation.
The Thread
This is the first post in a series on agent security. The next post tackles identity: how your agent proves who it is, what it’s allowed to do, and why most teams are treating agent credentials worse than a shared Netflix password. Read The Identity Problem.