Five Slices of Swiss Cheese Between Your Agent and Everyone Else
How KiloClaw’s security architecture borrows from aviation safety engineering to isolate AI agents
In 1990, psychologist James Reason published a model for understanding how catastrophic failures happen in complex systems. He’d been studying aviation disasters and hospital errors — situations where multiple safeguards existed but people still died. No single safety layer is perfect. Every defense has holes in it. The dangerous moment is when the holes in every layer happen to line up at the same time.
He called it the Swiss Cheese model. Each defensive layer is a slice of Swiss cheese. Each slice has holes — weaknesses, gaps, edge cases. Stack enough slices together and the odds of a threat passing through every hole simultaneously become vanishingly small.
The model transformed how the aviation industry thinks about safety. It changed healthcare protocols. And it turns out to be a useful way to think about securing AI agents that can execute arbitrary code on your behalf.
Why AI Agents Need More Than One Layer
Most SaaS platforms keep customer data in shared infrastructure. A single database, shared compute, application-level logic deciding who sees what. If the application logic has a bug, that’s your one layer of defense — and it just failed.
That’s manageable when your SaaS product is a project management tool or a CRM. The blast radius of a tenant isolation failure is data exposure.
AI agents are different. An OpenClaw agent can run shell commands, browse the web, read and write files, connect to your Slack, Telegram, or Discord and has API keys for all of those and more. If tenant isolation fails for an AI agent platform, the attacker doesn’t just see your data — they potentially have access to everything your agent can do.
A single-layer approach isn’t enough. You need defense in depth — Swiss cheese, in safety engineering terms.
KiloClaw’s Five Slices
Darko wrote a detailed post on the Kilo blog covering KiloClaw’s security architecture, and it maps cleanly to the Swiss Cheese model. There are five independent layers of tenant isolation. For one customer to access another’s data, all five would have to fail simultaneously.
Here’s what those layers look like:
Slice 1: Authentication & Access Control
Every request is authenticated before it reaches a customer’s machine. The routing destination comes from the authenticated user identity stored server-side, not from anything the user controls in the request.
This matters because the most common class of tenant isolation bugs in SaaS products is Insecure Direct Object Reference — where you change an ID in a URL or API call and access someone else’s stuff. KiloClaw sidesteps this entirely by never letting the user specify the destination.
Slice 2: Application Isolation
Each customer’s VM runs inside a dedicated Fly.io application. Not a shared app with per-user containers — a separate application entirely. One customer’s storage can’t be attached to another customer’s machine. Internal networks are isolated at the application boundary.
Slice 3: Network Isolation
Each customer environment sits on its own isolated WireGuard network mesh. During the independent security assessment, cross-tenant network tests confirmed that customers can’t discover each other’s machines and can’t connect directly across applications.
This is the kind of claim that’s easy to make and hard to verify. Which is why it was tested by a third party, not just asserted.
Slice 4: Process Isolation
Each workload runs inside its own Firecracker microVM — the same virtualization technology that powers AWS Lambda and AWS Fargate. Firecracker provides hardware-level virtualization, not just container isolation. Each VM has its own kernel.
This is the layer that matters most for AI agents specifically. If an agent gets manipulated through prompt injection — a malicious webpage or message tricks it into running something it shouldn’t — the blast radius is limited to that customer’s own VM. There’s no shared kernel, no shared filesystem, no shared process space with other customers.
To escape that boundary, you’d need a vulnerability in the Firecracker hypervisor itself. Possible in theory, but Firecracker is also what Amazon trusts to isolate millions of Lambda functions from each other.
Slice 5: Storage Isolation
Each customer gets a dedicated encrypted persistent storage volume. That volume can only be mounted inside the customer’s own application environment. There’s no API, no configuration option, no path by which another customer’s machine can access it.
When you destroy a KiloClaw instance, a two-phase cleanup process destroys the encryption keys, making the stored data unrecoverable. Not “deleted and maybe recoverable with forensics” — the keys are gone.
What Happens to Your Secrets
API keys and chat tokens — the things that would be most damaging if exposed — are encrypted with RSA-OAEP and AES-256-GCM in the platform database. They’re decrypted only when your VM starts, and they’re only available inside your isolated environment.
All external traffic uses TLS. Storage is encrypted at rest. The encryption isn’t optional or configurable — it’s how the platform works.
The Exec Problem
One thing unique to AI agent platforms: the exec tool. OpenClaw agents can run shell commands, which is the whole reason they’re useful — and the whole reason security matters.
KiloClaw’s approach is to require explicit user approval before the exec tool runs anything, by default. The approval requirement is enforced by the platform itself — not by the agent, not by the prompt, not by configuration that could be overridden through prompt injection. The agent literally cannot bypass it.
This is worth calling out because in the Swiss Cheese model, the most dangerous failures are the ones where a safety layer can be disabled by the thing it’s supposed to protect against. A prompt injection attack that can turn off exec approval would collapse two layers into zero. KiloClaw prevents that by putting the control outside the agent’s reach.
Independent Testing
In February 2026, Andrew Storms conducted a 10-day security assessment of KiloClaw. The work included threat modeling using the PASTA framework across 30 threats and 13 assets, code review, and adversarial testing — 35 tests targeting tenant isolation specifically, including Unicode edge cases, zero-width characters, null bytes, and injection payloads. Eight live cross-tenant network tests were run across separate customer environments.
Results:
No cross-tenant access path found
No SQL injection
No XSS
No command injection
No path traversal
No open redirect
The assessment also produced 17 merged pull requests — 10 security fixes and 7 hardening improvements. Finding things to improve is a sign of a good assessment, not a bad product.
No Layer Is Perfect
The Swiss Cheese model is honest about something that security marketing usually isn’t: every layer has holes, and they all rely on understanding below the
James Reason developed this model because the aviation industry kept making the same mistake: assuming one really good safety system was enough. It never was. What worked was redundancy across independent systems that fail in different ways.
KiloClaw’s five layers — authentication, application isolation, network isolation, process isolation, and storage isolation — are enforced by different technology at different levels of the stack. A bug in one doesn’t compromise the others. An attacker who gets past one still faces four more.
For a platform where AI agents run arbitrary code with access to your API keys and communication channels, that kind of redundancy isn’t optional.
The KiloClaw security white paper has the full technical details. Darko’s blog post is a good summary if you want the overview without the PDF.