Skip to content

Critical: Default configuration provides zero isolation - users have unrestricted filesystem access and plaintext credentials #7139

Description

@joshyorko

Summary

OpenClaw's default configuration gives an AI agent unrestricted read/write access to the entire filesystem and stores API credentials in plaintext JSON files. The "workspace" is not a sandbox - it is a lie. This is not a misconfiguration edge case. This is the out-of-box experience for every user.

This has been independently verified by multiple security audits. Users are being harmed.


Issue 1: The "Workspace" Is Not a Sandbox

Your own documentation admits this (docs/concepts/agent-workspace.md):

Important: the workspace is the default cwd, not a hard sandbox. Tools resolve relative paths against the workspace, but absolute paths can still reach elsewhere on the host unless sandboxing is enabled.

Code proof (src/agents/pi-tools.ts):

if (tool.name === readTool.name) {
  if (sandboxRoot) {
    return [createSandboxedReadTool(sandboxRoot)];  // Only used when sandbox ON
  }
  const freshReadTool = createReadTool(workspaceRoot);  // Default: NO path restrictions
  return [createOpenClawReadTool(freshReadTool)];
}

What this means in practice:

  • read({ path: "~/.ssh/id_rsa" }) - works
  • read({ path: "~/.aws/credentials" }) - works
  • read({ path: "/etc/shadow" }) - works (if running as root)
  • exec({ command: "rm -rf ~" }) - works

The default configuration provides zero filesystem isolation.


Issue 2: Sandbox Disabled by Default

Code proof (src/agents/sandbox/config.ts:137):

return {
  mode: agentSandbox?.mode ?? agent?.mode ?? "off",  // DEFAULT IS "off"
  // ...
}

A Docker sandbox implementation exists with proper isolation (--network none, --cap-drop ALL, --read-only, --security-opt no-new-privileges). It is well-designed. But it is opt-in and disabled by default.

Users must explicitly know to configure sandbox.mode: "docker" to get any protection. Most users do not know this.


Issue 3: Plaintext Credential Storage

Code proof (src/agents/auth-profiles/store.ts:283-291):

export function saveAuthProfileStore(store: AuthProfileStore, agentDir?: string): void {
  const authPath = resolveAuthStorePath(agentDir);
  const payload = {
    version: AUTH_STORE_VERSION,
    profiles: store.profiles,  // Contains raw API keys
    // ...
  };
  saveJsonFile(authPath, payload);  // Plaintext JSON
}

API keys for Anthropic, OpenAI, and other providers are stored in ~/.openclaw/agents/*/agent/auth-profiles.json as plaintext. Any malware, malicious browser extension, or compromised process can read these files and exfiltrate credentials.

The iOS app uses proper Keychain storage (apps/ios/Sources/Gateway/KeychainStore.swift). The CLI/server does not.


Issue 4: Per-Route Authentication (Fragile Pattern)

There is no global authentication middleware. Each route implements its own auth check. This is a classic "vibe coding" anti-pattern where:

  • New routes can be added without auth and nobody notices
  • Auth logic is duplicated and inconsistent
  • One missed check exposes a vulnerability

Issue 5: No CORS Protection

No Access-Control-Allow-Origin headers are set. While token-based auth provides some protection, defense-in-depth requires explicit CORS denial for cross-origin requests to a local agent.


The Core Problem

This application was built by an experienced engineer (founder of PSPDFKit) using "vibe coding" methodology. The result is software that looks functional but has fundamental security architecture problems:

  1. Security features exist but are opt-in rather than opt-out
  2. The path of least resistance leaves users completely exposed
  3. Documentation buries warnings about lack of isolation instead of making secure defaults
  4. Battle-tested solutions (OS keychain, container isolation) were skipped in favor of shipping fast

A user who downloads OpenClaw and runs it with default settings is giving an AI agent:

  • Full filesystem access to their machine
  • Credentials stored where any malware can read them
  • Direct shell execution with no sandboxing
  • No network isolation

This is unacceptable for software that markets itself as a personal AI assistant.


Required Changes

  1. Sandbox enabled by default - Change mode default from "off" to "docker" (or require explicit user acknowledgment of risks)
  2. OS keychain integration - Store credentials in platform-native secure storage
  3. Global auth middleware - Replace per-route auth with middleware pattern
  4. CORS headers - Explicitly deny cross-origin requests
  5. Startup warning - Display clear warning when running without sandbox

References

  • Commit analyzed: 57d008a33d4208c81183384d47f938d69b7c7044
  • Independent verification: GitHub Copilot code analysis, Gemini security audit
  • Related documentation: docs/concepts/agent-workspace.md (admits workspace is not a sandbox)

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingstaleMarked as stale due to inactivity

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions