How Chelar Secures Your AI Agent: Container Isolation, Encryption & Network Segmentation

Why AI agent security matters

Most hosting providers say "secure" on their landing page. Few explain what that actually means. We're going to show you exactly what Chelar does — real architecture, real configuration.

Real attacks on AI agents — and how we mitigate them

In February 2026, 38 researchers from Northeastern, Harvard, Stanford, MIT, and CMU published Agents of Chaos — a red-team study where they deployed OpenClaw agents in real organizational environments and let people attack them for two weeks. These aren't exploits. They're conversations. Here's what happened and how Chelar's architecture addresses each attack class:

These aren't features we built in response to the paper. They're the same layers described below, designed from day one. The paper just gives them a name.

Defense in depth

Chelar's security model has five layers. Breaching one doesn't compromise the others.

Let's walk through each one.

Layer 1-3: Network segmentation

The three firewalls

Every tenant container sits behind three independent firewalls:

Cloud provider firewall, the outermost perimeter. Only SSH (restricted IPs), HTTP (80), and HTTPS (443) reach the server. Everything else is dropped before it hits the machine.

UFW Host Firewall, default-deny policy on the server itself. Only explicitly allowed ports accept connections.

iptables DOCKER-USER chain, the most important layer. This controls what containers can reach on the host network. Every internal service — orchestrator, reverse proxy admin API, control plane — is explicitly blocked from container access. The cloud metadata endpoint is blocked to prevent SSRF attacks. And the most critical rule: containers cannot talk to each other. Even if an agent is compromised via prompt injection, it can't reach other tenants' containers or any internal infrastructure.

What a container CAN reach

Outbound internet access (HTTP/HTTPS) is allowed, agents need it to call AI APIs, browse the web, and fetch data. The firewall blocks lateral movement within the infrastructure, not external connectivity.

Layer 4: Container hardening

Every tenant container runs with the strictest Docker security configuration we can apply — all capabilities dropped, read-only root filesystem, privilege escalation blocked, and process limits enforced. Here's what each setting does:

cap_drop: ALL

Linux capabilities are fine-grained permissions that replace the old "root or nothing" model. Docker grants containers 14 capabilities by default (NET_BIND_SERVICE, CHOWN, SETUID, etc.). We drop all 41 capabilities. The container process has zero special privileges.

readonly_rootfs: true

The container's root filesystem is mounted read-only. The agent can only write to its dedicated data directory and a tmpfs mount for temporary files. This prevents an attacker from modifying system binaries, installing tools, or persisting malware.

no-new-privileges

Prevents processes inside the container from gaining additional privileges through setuid/setgid binaries or filesystem capabilities. Even if an attacker finds a setuid binary, it won't escalate.

Process limits

Each container has a hard cap on the number of processes it can spawn. This prevents fork bombs and limits the blast radius of any process that tries to spawn excessive children.

Non-root execution

Containers run as a non-root user with a dedicated UID. Neither the OpenClaw nor ZeroClaw runtime runs as root.

Docker's default seccomp profile

On top of all the above, Docker automatically applies a seccomp profile that blocks ~44 dangerous syscalls (including mount, reboot, clock_settime, kexec_load). We don't override it.

Encrypted storage

API keys and credentials

Your API keys and channel credentials are encrypted with AES-256-GCM before they touch the database. Each encryption uses a unique random nonce, so encrypting the same key twice produces different ciphertext. The encryption key is loaded at startup from a secure source — it never appears in code or config files.

What gets encrypted:

• AI provider API keys (Anthropic, OpenAI, Google, Mistral, OpenRouter)
• Telegram bot tokens
• Internal service tokens
• Any credential passed through the setup wizard

Tenant data on disk

Tenant data lives on an encrypted distributed filesystem that provides client-side AES-256-GCM encryption transparent to the application. Data is encrypted before it leaves the application layer, stored encrypted on EU-based object storage, and decrypted only on the host machine. The encryption key is stored with restrictive permissions (root-only readable) and is never accessible to tenant containers.

Per-tenant isolation on disk

Each tenant gets its own directory with strict POSIX permissions — directories are owner-only (read+write+execute), files are owner-only (read+write), and ownership is set to the tenant's dedicated container UID. One tenant's container cannot read another tenant's files — the kernel enforces it at the filesystem level. Even if a container somehow bypassed network isolation, POSIX permissions prevent cross-tenant data access.

Each tenant also has a storage quota to prevent any single agent from filling the disk.

Layer 5: Authentication and access control

Reverse proxy forward_auth

Every tenant's dashboard is protected by the reverse proxy's forward_auth directive. Here's the flow:

1. Browser requests the tenant's subdomain
2. The reverse proxy intercepts and sends an auth subrequest to the control plane
3. The control plane extracts and validates the JWT token
4. Looks up the tenant and verifies ownership: does this user own this agent?
5. On success: returns 200, the proxy forwards the request to the container
6. On failure: returns 401, the container is never reached

The container itself never handles authentication — the reverse proxy gates all traffic before it arrives.

Read-only API scope

The control plane queries tenant containers for health and status information, but it uses a read-only operator scope. It can check if your agent is running, read health metrics, and list cron jobs. It cannot:

• Read your chat history or conversation sessions
• Access your AI API keys (they're encrypted in the database, injected at container start)
• Modify your agent's configuration
• Execute commands in your container

What we don't do

Compared to self-hosting

Most people who self-host OpenClaw skip security hardening entirely. A typical self-hosted setup has:

This isn't a criticism of self-hosting — it's a description of what most people actually configure. Security hardening takes time and expertise. Chelar gives you all of this out of the box, so you can focus on what your agent actually does.

Data deletion

When you delete your account or remove a tenant, we purge everything:

1. Container deregistered — stopped and permanently removed from the orchestrator
2. Reverse proxy route deleted — domain no longer reachable
3. Storage destroyed — tenant directory removed recursively (data, config, credentials)
4. Database rows deleted — tenant record, encrypted secrets, all metadata

The cleanup runs as a chain — if one step fails, it continues to the next, cleaning up as much as possible. Your active data is protected by encrypted storage with redundancy, but once you request deletion, it's gone.

FAQ

Is Chelar SOC 2 certified?

Not yet. We're a bootstrapped company and we'd rather invest in actual security controls than compliance paperwork. Everything in this post is our real production configuration — you can verify it. Third-party audits are on the roadmap as we scale.

Can Chelar staff access my agent's data?

Our control plane queries your container with a read-only operator scope — it can check health and status, nothing else. It cannot read your conversations, access your API keys in plaintext, or execute commands in your container. API keys are AES-256-GCM encrypted at rest and only decrypted to inject them as environment variables at container startup. This is the same trust model as any managed hosting provider, but we document exactly what we access and what we don't.

How does this compare to OpenClaw Cloud's security?

Different approach, different tradeoffs. OpenClaw Cloud uses per-user VMs on their Pro plan. Chelar uses hardened containers with five independent security layers: three firewalls, container hardening (cap_drop ALL, readonly rootfs, no-new-privileges), per-tenant filesystem isolation, AES-256-GCM encryption, and reverse proxy authentication. We also enforce network segmentation that blocks container-to-container communication entirely — something that's harder to get wrong than VM networking.

What if a prompt injection attack compromises my agent?

The blast radius is limited to your own container. An attacker who hijacks your agent via prompt injection cannot: reach other tenants' containers (blocked by iptables), access internal APIs (blocked by firewall), escalate to root (blocked by no-new-privileges + cap_drop ALL), or modify the container image (blocked by readonly rootfs). On the ZeroClaw runtime, Landlock filesystem sandboxing and tool exclusions add further constraints on what a compromised agent can do.

Ready to run your AI agent without worrying about security?

Chelar gives you five layers of defense, encrypted storage, and per-tenant isolation — all configured out of the box. No Docker hardening guides to follow, no firewall rules to write, no encryption to set up yourself.

Get started with Chelar and have your agent running in under five minutes.