OpenClaw has taken the world by storm and brought autonomous AI agents into the mainstream.
However, when an agent can execute code, browse the web, and connect to Slack, Discord, or Telegram on your behalf, security stops being a footnote and starts being the whole plot.
This also raises an obvious question:
How do I know my data, accounts, and API keys are safe?
That question sits at the center of how KiloClaw is built.
KiloClaw is a managed compute platform for OpenClaw built with security at its core, and we just published a detailed white paper describing the platform's security architecture and independent assessment.
This post summarizes the key points from KiloClaw's February 2026 security white paper. Let's dive in.
What makes KiloClaw different from your "typical OpenClaw hosting SaaS"
KiloClaw was designed from the ground up with defense in depth: multiple layers of isolation, strong authentication, encrypted storage, and strict handling of customer secrets.
And in February 2026, KiloClaw brought in an independent security assessor, Andrew Storms, for a 10 day review that included threat modeling, code review, adversarial testing, and live infrastructure testing. The conclusion: KiloClaw's security architecture is sound, with tenant isolation enforced at multiple independent layers.
Each instance is an isolated virtual machine
Most SaaS products store customer data in shared infrastructure and rely on application logic to keep accounts separated.
KiloClaw is different because your AI agent actually runs code on your behalf. That means the isolation between customers has to be much stronger.
A simple way to think about it is this:
Many platforms give you an apartment in a larger building.
KiloClaw gives you your own house, on your own lot, with your own fence.
When you create a KiloClaw instance, we spin up a dedicated virtual machine just for you.
Not a shared container. Not a small slice of someone else's runtime. A full virtual machine with its own kernel.
KiloClaw uses Firecracker microVMs, the same virtualization technology used by AWS Lambda and AWS Fargate. That matters because Firecracker provides isolation between workloads based on hardware virtualization.
In practical terms, that means if something goes wrong inside your AI agent's environment, the impact is contained to your environment. There is no shared kernel, no shared filesystem, and no shared process space with other customers.
Five layers of isolation
KiloClaw does not depend on one security layer. It uses five independent layers of tenant isolation.
For one customer to access another customer's data, all five layers would have to fail at the same time.
1. Identity-based routing
Every request is authenticated before it reaches a customer machine.
KiloClaw does not route requests based on user-controlled input. Instead, it derives the destination from the authenticated user identity stored server-side.
In plain English: you cannot trick the platform into sending you to someone else's machine.
2. A dedicated application environment
Each customer's VM runs inside a dedicated Fly.io application.
That matters because KiloClaw keeps each customer's machines, storage, and internal network isolated from other customers.
In practice, that means one customer's storage cannot be attached to another customer's machine, and one customer's machines cannot be discovered through another customer's internal network.
3. Network isolation
Each customer environment is placed on its own isolated WireGuard network mesh.
During the independent assessment, live cross-tenant tests confirmed that customers could not discover one another's machines, could not connect directly across applications, and could only perform self-referencing network operations.
So the separation exists at the network layer too, not just inside the app.
4. The Firecracker VM boundary
Each customer workload runs inside its own Firecracker microVM.
This is a hard isolation boundary based on hardware virtualization. Even if an AI agent were manipulated through prompt injection or malicious tool usage, the blast radius would still be limited to that customer's own VM.
To escape that boundary would require a vulnerability in the Firecracker hypervisor itself.
5. Dedicated encrypted storage
Each customer gets a dedicated persistent storage volume, and that volume is encrypted at rest.
That storage can only be mounted inside the customer's own application environment. There is no path for another customer's machine to access it.
What about my API keys?
This is one of the most common questions for a good reason.
Customer API keys and chat tokens are encrypted in the platform database using RSA-OAEP with AES-256-GCM and are decrypted only when the customer's VM starts, where they are available inside that customer's isolated environment.
In other words, your keys are stored in encrypted form by the platform and only become readable inside your own isolated environment when needed.
There is also more work planned here over time, including short-lived token exchange and in-memory secret stores to reduce the exposure window even further.
Your data is protected in transit and while stored
KiloClaw protects data both while it is moving and while it is stored.
All external traffic uses TLS, including communication between the browser and the platform, as well as API calls to model providers.
At rest, customer storage volumes are encrypted using disk encryption at the infrastructure level, and secrets stored in the database are encrypted separately using modern cryptography.
In practical terms, that covers things like:
API keys
Chat tokens
Session transcripts
Workspace files
Authentication-related secrets
What happens when I delete my instance?
When you destroy your KiloClaw instance, the platform runs a two-phase cleanup process designed to complete safely even if something fails midway.
First, it shuts down and destroys the virtual machine. Then it deletes the storage volume and removes runtime secrets.
Deleting the volume also destroys the underlying encryption keys, making the stored data unrecoverable.
The deletion flow was reviewed independently and confirmed to clean up sensitive data reliably, even if part of the process fails temporarily and has to retry.
No secrets persist after instance destruction.
Some metadata that is not sensitive, such as user identifiers or timestamps needed for operational auditing, may remain in records or logs that have been soft deleted. That is standard practice and separate from customer secrets or workspace data.
What about prompt injection?
If you follow AI security, you have probably heard of prompt injection: a malicious message or webpage tries to trick an AI agent into doing something it should not do.
KiloClaw addresses this in two important ways.
First, the agent's exec tool, the capability that lets it run shell commands, requires explicit user approval before execution by default. That setting is enforced by the platform itself and cannot be overridden by the agent, by prompt injection, or through a connected chat channel.
Second, even in a worst-case scenario where prompt injection changes the agent's behavior, the blast radius is still contained to your own VM. It cannot access another customer's resources or move sideways across tenants.
Authentication is designed to reject uncertainty
KiloClaw's authentication model includes several protections that matter in practice:
Secure JWT cookie handling
Server-side session revocation
Constant-time secret comparison
Behavior that rejects requests when required systems are unavailable
That last one is especially important.
If a required backend dependency is unavailable, KiloClaw rejects the request rather than falling back to weaker behavior. That is a strong security property and one of the details security teams look for.
What we tested with an independent security assessor
In February 2026, independent assessor Andrew Storms conducted a 10-day security assessment of KiloClaw.
That work included:
Threat modeling using the PASTA framework, covering 30 threats across 13 assets
Code review of routing, authentication, secret handling, and lifecycle management
35 adversarial tenant-isolation tests, including Unicode edge cases, zero-width characters, null bytes, and injection payloads
8 live cross-tenant network tests across separate customer environments
Dozens of adversarial command-injection payloads
Review of the build pipeline, machine images, and runtime environment
The results were strong:
No cross-tenant access path was found
No SQL injection findings
No XSS findings
No command injection findings
No path traversal findings
No open redirect findings
The assessment also produced 17 merged pull requests: 10 security fixes and 7 hardening improvements.
Security is an ongoing practice
One thing worth saying clearly: strong security does not mean pretending the work is done.
The independent review found KiloClaw's architecture to be fundamentally sound, while also identifying areas for continued investment, especially around hardening the software supply chain and improving operational maturity.
That roadmap includes:
Pinning base images to SHA-256 digests
Image signing with Sigstore and cosign
SBOM generation
Automated vulnerability scanning in CI/CD
Egress monitoring and interactive approval controls for outbound agent activity
The bottom line
KiloClaw was built with the understanding that managed compute for AI agents is a product category that demands a high level of trust and security.
That is why each customer gets:
A dedicated virtual machine
A dedicated application environment
An isolated network
Dedicated encrypted storage (volume isolation)
Strong authentication and access controls
Encrypted secret handling
Multiple independent layers of tenant isolation
For nontechnical readers, the simplest takeaway is this:
Your agent is not running in the same place as everyone else's. Your environment is isolated by design.
For technical buyers, the important point is that this was not just claimed. It was independently reviewed, tested against adversarial scenarios, and validated in live infrastructure testing.
If you have questions about KiloClaw's security architecture or want additional documentation, reach out to the Kilo security team at security at kilocode dot ai.
Top comments (0)