How KiloClaw Is Built to Be Secure

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.