AI Agent Insurance Is Coming — And by 2027, You Won't Be Able to Deploy Without It
Two months ago, Lloyd's of London published something quiet and consequential: the first formal risk framework for autonomous AI agent incidents. Munich Re followed within weeks with a pilot policy. Allianz is reportedly close behind. The underwriters have started circling, and they're not doing it because they're bored.
They're doing it because the actuarial math finally exists. There's enough production agent failure data — from Klarna's chatbot refund cascade, from the Air Canada tribunal ruling, from the half-dozen quieter incidents you've never heard about — to price the risk. And the moment risk can be priced, it gets sold. The moment it gets sold, customers start asking for it. And by the time customers ask for it, the procurement department puts it on the requirements list.
This is how every new technology category ends up with mandatory insurance attached. Cars in the 1920s. Cybersecurity policies in the 2000s. SaaS data-breach coverage in the 2010s. Each one started as a niche product for early adopters. Each one is now a line item nobody questions.
By 2027, agent insurance will be on that list. And the architectural decisions you make today determine whether you'll be insurable at all.
Why this is happening faster than people expect
The traditional logic of cyber insurance was: an organisation gets breached, the policy pays out, the insurer subrogates against whoever was negligent. That model assumes a human chain of custody — an admin who clicked a phishing link, a vendor that shipped a vulnerable library, an engineer who left a port open. Liability flows along human decision points.
Autonomous agents break that model. When a Geta.Team employee, or an OpenAI agent, or an internal LangGraph workflow makes a decision that triggers a customer refund, sends an email, or pushes a configuration change, there is no human in the loop to point at. The agent operated within its sanctioned scope. It made what it thought was a reasonable judgment. The outcome was wrong, or expensive, or both.
Lloyd's framework — which I'd encourage anyone deploying agents to actually read — splits this into three risk classes:
- Capability failures: the agent did something it was never supposed to be able to do (privilege escalation, prompt injection, tool misuse).
- Judgment failures: the agent did exactly what it was supposed to, and the outcome was still harmful.
- Coordination failures: two or more agents produced an outcome neither would have produced alone.
The third class is the one that's keeping underwriters up at night. It's also the one that doesn't fit any existing insurance taxonomy, which is why the policies being drafted right now are essentially a new product line, not a rider on existing E&O coverage.
What the underwriters actually want to see
I've now had three off-the-record conversations with people who are quoting these policies for early customers. Three things come up every time, and they map almost perfectly to what makes an agent deployment defensible after the fact.
Auditable decision provenance. Not logs. Provenance. The difference: a log tells you what the agent did. Provenance tells you what context the agent had when it did it, which tools were available, which it considered, and what it chose to do with the result. Without provenance, the insurer has to assume the worst case for every incident — and price the premium accordingly.
Bounded scope with cryptographic enforcement. "The agent only has access to read-only OAuth tokens" is a sentence. "The agent's credential cannot perform writes because the scope is enforced at the OAuth provider, not at the agent layer" is a control. Underwriters will pay attention to the second one and discount the first.
Identity and continuity. This one surprised me. The underwriters care which specific instance of an agent was involved. If you spin up agents on demand, kill them after a task, and have no way to point at a specific "this agent, with this memory state, at this point in time" — you're harder to insure. The model is closer to "named driver" auto insurance than to general liability.
If you read those three together, you start to see why most current agent stacks aren't insurable yet. Stateless agents with shared credentials, no provenance layer, and ephemeral runtime contexts are essentially uninsurable in the way an anonymous fleet of cars would be uninsurable. Somebody is on the hook, but you can't tell who.
The self-hosted advantage nobody's talking about
There's an interesting asymmetry developing here that I don't think the SaaS-by-default AI industry has internalised yet.
If your agent runs on someone else's infrastructure, the provenance and audit trail live on someone else's infrastructure too. Which means when the insurer asks you to produce them, you're filing a support ticket and hoping. The insurer's underwriting model treats this as third-party risk — and prices it accordingly. Cyber insurance has been doing this for years; the premiums for SaaS-hosted workloads have crept steadily upward as breach data has accumulated.
Self-hosted agents flip this. The decision trail, the memory state, the tool call history, the credentials — they all sit on infrastructure you own and control. From an underwriting standpoint, this looks closer to a self-hosted database than a SaaS dependency. You're the system of record. Subrogation, if it ever comes to it, has somewhere to land.
This is one of the reasons we built Geta.Team self-hosted by default. It wasn't an insurance bet at the time — it was a data privacy and BYOA pricing decision — but the insurability story is going to age well. When the procurement checklist starts asking "where does the agent's audit trail live, and who has custody of it?", "on our own servers" is going to be a much shorter conversation than "let me check with the vendor."
What to do before the requirements show up
I don't think agent insurance becomes mandatory in 2026. I do think it becomes a competitive procurement advantage by mid-2026, and a hard requirement for regulated industries — healthcare, finance, legal, anything touching consumer data — by some point in 2027. That gives you a reasonable runway, but it's not infinite.
Three concrete things worth doing now, in roughly the order they pay off:
- Audit your provenance layer. If you can't reconstruct, six months after the fact, what an agent knew and what it decided when it took a particular action, that's the first thing to fix. This is unglamorous engineering — structured event logs with full context capture — and it's what makes everything else possible.
- Move credentials to scoped, revocable, audited tokens. No shared API keys. No agent operating with credentials broader than the task requires. Scope enforcement at the provider layer, not the application layer. This is also just good security hygiene, but the insurability case makes it a faster sell internally.
- Give your agents stable identities. Whether that's a named instance, a versioned configuration, or a memory checkpoint system, you want to be able to point at "the agent that did this" with the same precision you'd use for an employee. Ephemeral agents are a liability problem.
The pattern across all three is the same: agents are starting to be treated like employees, not like scripts. Employees have HR files. They have credentials. They have audit trails. They have continuity of identity over time. The infrastructure that makes that possible is also the infrastructure that makes them insurable.
The frontier labs are going to figure this out eventually, but they're optimising for the demo and the benchmark. The teams that figure out the boring underwriting-grade architecture first are the ones that get to sell into regulated industries when the buying season starts. Worth thinking about which side of that curve you'd rather be on.
Want to test the most advanced AI employees? Try it here: https://Geta.Team
