Security Architecture

Coral was designed around the security gaps that caused the 2026 OpenClaw exposure crisis. Most exposed instances failed because they relied solely on the application’s own authentication — which means a single misconfiguration or vulnerability bypasses all protections. Coral’s architecture enforces security at the infrastructure layer, independently of what OpenClaw does internally. This page covers how that works across authentication, isolation, credential storage, and access control.

---

​

Architecture Overview

The diagram below shows how a request travels from your browser to your sandbox. Every path passes through the proxy layer — there is no way to reach your sandbox directly from the internet. What this shows:

• Your browser authenticates once and receives a session token — not a gateway credential
• All HTTP and WebSocket requests pass through the proxy layer, which validates your session before forwarding
• The gateway credential is fetched server-side from an encrypted database and injected by the proxy — it never travels to your browser
• Your sandbox runs in a dedicated VM with no public IP and no exposed ports

---

​

Authentication

How it works: When you sign in, you authenticate through Google and receive a session token stored in an httpOnly cookie. This cookie is validated by the proxy layer on every request — it is never accessible to browser JavaScript and does not travel to your sandbox. For WebSocket connections (real-time chat, terminal, remote desktop), your browser receives a short-lived, single-purpose ticket instead of a persistent credential. The proxy validates this ticket before establishing the WebSocket connection. Tickets are cryptographically protected at rest and automatically expire — they cannot be used indefinitely or replayed after expiration. The session validation happens at the proxy layer, independently of OpenClaw’s own authentication. This matters: if a vulnerability in OpenClaw could bypass its internal auth checks (as some CVEs have demonstrated), the proxy layer remains as an independent enforcement point. Administrator access is verified live on every request — not from a cached session claim. This means role changes take effect immediately without requiring a re-login. Contrast with self-hosted: Authentication is handled entirely inside the OpenClaw application. There is no independent outer enforcement layer. A vulnerability that bypasses OpenClaw’s auth leaves nothing behind it.

---

​

Security Isolation

How it works: Each Coral user gets a dedicated virtual machine — not a shared container or a namespace partition on a shared host. Every sandbox has its own isolated CPU, memory, and filesystem. There is no shared kernel between users. No sandbox has a public IP address. There is no way to reach an individual sandbox directly from the internet. The OpenClaw gateway port is never exposed. Sandboxes are not discoverable by internet scanners. The only path to a sandbox is through Coral’s internal infrastructure, and every request on that path is authenticated. This design addresses two classes of attack that affect self-hosted deployments:

• Network exposure: A scanner cannot find your gateway port because it has no internet-accessible address to scan.
• Cross-user lateral movement: Because each user has a dedicated VM, a compromise of one sandbox has no filesystem or memory path to another user’s sandbox.

Why this matters for ClawJacked (CVE-2026-25253): The ClawJacked attack works by connecting to the gateway WebSocket from a malicious website. That requires the WebSocket endpoint to be reachable directly from a browser. In Coral, there is no directly reachable WebSocket endpoint — all connections pass through the authenticated proxy first. Contrast with self-hosted: A VPS instance receives a dedicated public IP. Unless a firewall is explicitly configured, the gateway port is open by default and discoverable within hours by passive internet scanners.

---

​

Secure Storage

How it works: The gateway credential — the token that grants control of an OpenClaw instance — is stored server-side in an encrypted, row-isolated database. It is never included in any response sent to your browser. Your browser does not have access to it at any point in the session flow. What your browser receives instead: a session token (for HTTP) or a short-lived ticket (for WebSocket). These tokens cannot be used to derive the gateway credential. If a browser session were compromised, the attacker would obtain a session token — not the underlying gateway credential. Your sandbox’s filesystem storage is encrypted per user with a dedicated key. Automated encrypted backups run on a rolling schedule. Contrast with self-hosted: Users typically enter the gateway token directly in the browser, where it lives in browser memory and travels on every request. Local credential files on a VPS are generally unencrypted.

---

​

Access Control

How it works: Every request to a Coral sandbox — HTTP or WebSocket — passes through the proxy layer before reaching OpenClaw. The proxy validates your session regardless of what the sandbox application does internally. This is not a feature of OpenClaw; it is a separate enforcement point in the infrastructure. The proxy layer enforces scope isolation for different connection types. Each ticket is scoped to a specific connection type and sandbox — it cannot be reused across different contexts. The database that stores credentials and user data operates on a deny-by-default model. Every table denies direct access unless explicitly authorized through server-side application paths. There are no open-by-default permissions. Audit logs and operational metrics are shipped off-sandbox to centralized storage, so they remain available even if a sandbox is terminated or compromised. Contrast with self-hosted: There is no independent access control layer outside OpenClaw. The application itself is the only enforcement point.

---

​

Limits of This Architecture

Coral’s infrastructure addresses the attack vectors responsible for the vast majority of OpenClaw security incidents: network exposure, authentication bypass, and credential leakage. There are risks it does not eliminate. Platform dependencies. Our authentication and data infrastructure rely on managed third-party services. If those providers experience a security incident, it could affect us. We monitor their security advisories and have incident response procedures, but the dependency exists. OpenClaw application vulnerabilities. Sandboxes run OpenClaw, which has had 90+ security advisories. We apply patches as quickly as possible after disclosure, but there is a window between disclosure and deployment where a sandbox-level vulnerability could be exploited by someone who already has an authenticated session. Trusted user actions. If you connect an account to your agent and the agent acts on it, Coral’s infrastructure does not override that — the agent operates within the permissions you granted. Our architecture reduces external attack surface; it does not constrain what an authorized agent can do. The right mental model: Treat your agent like a new employee. Don’t connect accounts you can’t afford to lose, start with narrow permissions, and expand access as trust builds.

---

​

Comparison

---

If you are currently running a self-hosted instance and want to assess your exposure, see Harden Your Self-Hosted Instance for a checklist, or Terminate Your Instance for step-by-step shutdown instructions.