Safety in Continua

🎯 Threat model & the Betrayal paper

In February 2026, researchers from Northeastern, Harvard, MIT, CMU, Stanford, and others published Agents of Chaos (Shapira et al., 2026) — a red-team study of autonomous LLM agents deployed on OpenClaw, an open-source personal AI framework. Over two weeks, twenty AI researchers interacted with the agents under adversarial conditions.

They documented 11 case studies spanning:

📊 Mitigation strength classification

Not all mitigations are created equal. We classify each one by how it can be bypassed, so you can reason about the actual security boundary.

⚖️ Side-by-side: Continua vs. OpenClaw

The "Agents of Chaos" study used OpenClaw with Claude Opus and Kimi K2.5. Here is a point-by-point comparison of how each attack surface is handled.

🔒 The 10 mitigations (M1–M10)

Each mitigation is a pure-Go policy function applied in the tool execution pipeline. Policies are composable, zero-allocation on the hot path, and add microsecond-scale latency relative to LLM call latency (500 ms – 3 s).

M1: Owner-Only Policy

Paper reference: Case Study #2 (Compliance with Non-Owner), Case Study #8 (Identity Spoofing)

Every tool call carries a requester identity in the Go context. OwnerOnlyPolicy extracts this identity and compares it to the workspace owner. Non-owner requests are rejected before the tool executes. This is enforced at the infrastructure level — the LLM cannot override it, and prompt injection cannot bypass it.

// Simplified — actual implementation in tools/policy.go
func OwnerOnlyPolicy() Policy {
    return Policy{
        Name: "owner-only",
        Pre: func(ctx context.Context, tool string, args map[string]any) error {
            requester := RequesterFromContext(ctx)
            owner := OwnerFromContext(ctx)
            if requester != "" && owner != "" && requester != owner {
                return fmt.Errorf("only the workspace owner can use this tool")
            }
            return nil
        },
    }
}

M2: DNS Rebinding Protection

Attack: Attacker controls a domain that resolves to 169.254.169.254 (cloud metadata) or 127.0.0.1 (local services). Agent fetches the URL, believing it's an external site.

Defense: Post-DNS-resolution IP validation. After the DNS lookup but before the HTTP connection, we check if the resolved IP is in a private/loopback/link-local range. If so, the request is blocked. Combined with NoPrivateNetworkAccess (blocks curl 169.254.* in exec) and the safe proxy (transparent HTTP proxy that checks all subprocess traffic).

M3: Sensitive Path Blocking + Credential Scoping

Paper reference: Case Study #3 (Disclosure of Sensitive Information)

Compiled regex patterns match credential files: .env, .env.local, id_rsa, id_ed25519, *.pem, .aws/credentials, .ssh/config, .netrc, .pgpass, and more. NoSensitivePathAccess is applied on the filesystem tool, forcing credential access through the dedicated credential tool.

Credential scoping (CON-1885): The credential tool is further scoped by OnlyOwnedCredentials — it only allows access to services the user has actually connected (e.g., Gmail, Google Calendar). If you haven't connected GitHub, the agent can't retrieve GitHub credentials even via the credential tool. The connected services list is looked up from the connection store at request time.

M4: Credential/Secret Redaction

Response-path filter for credential and secret patterns. Controllable via dynamic config (pii_filter_enabled). Regex patterns detect and redact:

• SSNs: XXX-XX-XXXX patterns → [SSN REDACTED]
• Credit cards: Visa, Mastercard, Amex formats → [CARD NUMBER REDACTED]
• API keys: Common prefixes (sk-ant-, sk-, AIza, ghp_, gho_, glpat-) → [API KEY REDACTED]
• AWS keys: AKIA / ASIA prefixes → [AWS KEY REDACTED]
• JWTs: eyJ... three-part dot-separated tokens → [BEARER TOKEN REDACTED]
• Private keys: PEM blocks (BEGIN RSA PRIVATE KEY, etc.) → [PRIVATE KEY REDACTED]

M5: Content Trust Tagging

Paper reference: Case Study #10 (Agent Corruption via external content)

All web_fetch results are wrapped with provenance tags. Content from user-generated content platforms (Reddit, Hacker News, Pastebin, Stack Overflow, GitHub Gists, etc.) receives an additional ⚠ UGC platform warning. This gives the LLM signal to treat fetched content as potentially adversarial — reducing the effectiveness of indirect prompt injection.

M6: Skill Write Validation

Paper reference: Case Study #10 (Agent Corruption — attacker modified agent configuration)

When the filesystem tool writes a SKILL.md file, validation runs in two layers: deterministic scanning for known-dangerous patterns (shell injection, credential harvesting, exfiltration URLs, prompt-injection markers, disallowed tool usage) and a semantic intent classifier for ambiguous poisoning attempts that evade regexes. The semantic path returns allow|deny|escalate; deny/escalate block the write and require explicit owner review. Classifier verdicts are cached and micro-batched to keep added latency and model cost bounded.

M7: Loop Detection

Paper reference: Case Study #4 (Waste of Resources — 9+ hour loop)

Per-thread sliding window rate limiter. If the same tool is called with the same arguments more than 5 times within 10 minutes, the call is blocked. Hard cap of 20 total repetitions for any tool+args pair per thread. This catches both conversational loops (agent calling the same API repeatedly) and automation loops (cron jobs, background processes).

M8: Automation Cap

Paper reference: Case Study #5 (Denial of Service)

Per-user daily limit of 10 automation scripts (cron jobs, scheduled tasks, background processes). Plus a full script audit: ScriptAudit() function that scans exec commands for script creation patterns and counts them against the user's daily budget.

M9: Claim Source Tracking

Paper reference: Case Study #9 (Cross-agent knowledge sharing), Case Study #11 (Libelous claims)

Every memory claim is tagged with its source and a trust level: TrustOwner (from the authenticated owner) or TrustNonOwner (from agents, emails, web content, or non-owner humans). When the agent uses claims for reasoning, it can weight owner claims more heavily and treat non-owner claims with appropriate skepticism.

M10: Proportionality Prompt SOFT

Paper reference: Case Study #1 (Disproportionate Response — agent disabled its own email)

System prompt instruction that instructs the agent to prefer minimal, reversible actions. Key rules: never disable your own capabilities, never delete configuration files, prefer the least-destructive path, and escalate to the owner when uncertain.

📊 Production observability & alerting

CON-1883: All 10 safety policies were invisible in production — no metrics, no alerting, no way to know if PII redaction was firing or loops were being detected. Now every safety event emits a structured JSON log line that Cloud Logging ingests and Cloud Monitoring turns into real-time metrics and alerts.

Structured safety events

Every policy block, PII redaction, loop detection, automation cap hit, sandbox fallback, and semantic-classifier batch/cache event emits a safety_event JSON entry:

{"safety_event": {
  "kind": "policy_block",
  "policy": "no-destructive-commands",
  "tool": "exec",
  "user_id": "user-abc",
  "detail": "command contains blocked pattern \"rm -rf /\"",
  "timestamp": "2026-02-24T20:57:24Z"
}}

Event kinds:

Cloud Monitoring alerts

Core safety metrics feed three alert policies:

Dashboard

Safety dashboard widgets now include both enforcement and semantic-classifier economics:

• Safety: Policy Blocks — time series by policy name (which policies are firing most)
• Safety: PII Redactions — time series by pattern (SSN, credit card, API key, etc.)
• Safety: Loop Detections + Automation Caps — combined time series
• Safety: Semantic Classifier Cache Hit Rate — policy/content cache effectiveness
• Safety: Semantic Classifier Latency + Cost — p50/p95 added latency and estimated USD burn

Live debugging endpoint

GET /admin/safety-metrics returns a real-time JSON snapshot of all safety counters:

{
  "total_blocks": 42,
  "pii_redactions": 7,
  "loop_detections": 2,
  "rate_limit_hits": 15,
  "automation_cap_hits": 1,
  "sandbox_fallbacks": 0,
  "workspace_limit_hits": 3,
  "semantic_classifier_calls": 19,
  "semantic_classifier_classified_items": 44,
  "semantic_classifier_cache_hits": 61,
  "semantic_classifier_policy_cache_hits": 35,
  "semantic_classifier_content_cache_hits": 26,
  "semantic_classifier_cache_hit_rate": 0.58,
  "semantic_classifier_input_tokens": 9821,
  "semantic_classifier_output_tokens": 1432,
  "semantic_classifier_estimated_cost_usd": 0.0127,
  "semantic_classifier_cost_by_user_usd": {
    "alice@example.com": 0.0068,
    "bob@example.com": 0.0059
  },
  "semantic_classifier_added_latency_p50_ms": 37,
  "semantic_classifier_added_latency_p95_ms": 84,
  "policy_blocks": {
    "no-destructive-commands": 12,
    "no-network-attacks": 8,
    "no-sensitive-path-access": 15,
    "no-phishing-in-messages": 5,
    "deno-sandbox": 2
  }
}

🎛️ Dynamic config for safety tuning

CON-1883: All safety thresholds were hardcoded — if PII redaction had false positives or loop detection was too aggressive, the only fix was a code change + redeploy. Safety behavior is now tuneable at runtime via dynamic config (GCS blob, polled every 30 seconds).

All knobs use zero-value = code default semantics. Setting a knob to 0 (or omitting it) uses the hardcoded default. This means an empty config file produces the same behavior as before the feature was added — no migration needed.

🏗️ User isolation architecture

Our runtime uses a goroutine-per-user architecture within a shared Go process on Cloud Run. This is a deliberate trade-off: cheaper per-user cost (~$0 marginal cost vs. $20+/VM for OpenClaw) at the expense of weaker OS-level isolation.

What we verified (and what we didn't)

We ran a 14-test isolation probe suite that confirms:

• ✅ Clean subprocess environment — no parent env leakage
• ✅ Per-user rate limiting — users cannot exhaust each other's budgets
• ✅ Per-thread loop detection — loops in one thread don't affect others
• ✅ Concurrent filesystem safety — no races under concurrent access
• ✅ Workspace jail — absolute paths and traversals blocked
• ✅ Exec sibling blocking — commands referencing other workspaces blocked

Gaps closed by nsjail (February 2026):

• ✅ System file reads blocked — mount namespace hides files outside user workspace
• ✅ PID enumeration blocked — PID namespace shows only the subprocess
• ✅ /tmp isolated — per-sandbox tmpfs (10 MB)
• ✅ Dangerous syscalls blocked — gVisor hypervisor-level syscall filtering (Cloud Run gen2)
• ✅ Sibling workspace access — mount namespace + application-layer blocking

Shared-process memory isolation (what's actually true):

• ✅ Go runtime memory safety: Go has no pointer arithmetic, enforces bounds checking on all slice/array access, and uses a garbage collector. One goroutine cannot read another goroutine's heap memory through normal Go code. This is materially different from C/C++ shared-process architectures where buffer overflows or use-after-free bugs can cross user boundaries.
• ✅ /proc and /dev not mounted in nsjail: The nsjail config only bind-mounts /usr, /bin, /lib, /etc/ssl, and a few config files. /proc and /dev are not mounted. Exec'd subprocesses cannot access /dev/mem (physical memory), /dev/kmem (kernel memory), /proc/self/mem (process memory), /proc/<pid>/maps (memory maps), or /proc/<pid>/environ (environment variables).
• ✅ NoMemoryAccess policy (defense-in-depth): Even outside nsjail (fallback path), the exec policy layer blocks commands referencing /dev/mem, /proc/*/mem, /proc/*/environ, and kernel internals (/proc/kallsyms, /proc/kcore).

Residual risk (documented honestly):

• ⚠️ Go runtime CVE: A memory corruption bug in the Go runtime itself (or in a C library called via cgo) could theoretically allow cross-goroutine memory access. This is low-probability — Go's runtime is extensively tested and fuzzed — but it is the residual risk in our shared-process architecture. For users who need hardware-level memory isolation (separate address space per user), we offer the Firecracker premium tier.

💾 Storage exhaustion defense

Paper reference: Case Study #5 (Denial of Service — disk filled with output)

In the "Agents of Chaos" study, attackers filled the 20 GB volume by having the agent generate large outputs or write many files. Our runtime enforces storage limits at three levels:

Workspace usage is scanned lazily (at write time) and cached for 30 seconds. The cache is invalidated after every successful write. This keeps the hot-path overhead to 31 ns (cache hit) while still catching workspace overflow.

⚡ Performance benchmarks

All mitigations run in the tool-call hot path. We benchmark each one to ensure they add negligible latency relative to LLM inference (500 ms – 3 s). Measured on Apple M4 Max with -benchmem and -count=3.

Sandbox manager overhead

🧪 Adversarial test suite

We maintain a 33-test adversarial suite covering 16 attack categories, designed to mirror the attacks from the "Agents of Chaos" paper plus additional vectors specific to our architecture. All tests run with Go's -race detector enabled.

Result: 41 of 41 attacks fully mitigated. The original 33 tests plus 8 new tests for memory access paths, builtin write protection, and skill poisoning (CON-1913).

🚀 Cloud Run safety e2e tests

CON-1883: The adversarial tests above run in-process. They verify policy logic but not the full deployed stack: iptables REDIRECT → safe proxy → nsjail namespace → policies → PII response filter. We now have 9 deployed-instance integration tests that run against a live Cloud Run instance and verify end-to-end enforcement.

# Run against staging:
go test -v -tags=e2e ./personal_ai_runtime/e2e/ \
  -run TestSafety \
  -staging-url=https://gravity-staging-329044329780.us-central1.run.app \
  -timeout=5m

✅ Cloud Run verification (February 24, 2026)

We built a Docker image with nsjail, pushed it to Google Artifact Registry, and ran end-to-end tests on Cloud Run gen2 (which runs containers inside gVisor). These are the actual results from production infrastructure — not local dev or simulated environments.

What works on Cloud Run gVisor

What gVisor blocks (and why that's fine)

Measured latency

🔥 Premium isolation: Firecracker microVM

The standard tier provides strong isolation for all users: nsjail namespaces for subprocesses, Go's memory safety for the shared process, and /proc//dev exclusion from sandboxed exec. The residual risk is a Go runtime memory corruption CVE — low-probability but nonzero. For users who handle high-value credentials (banking APIs, healthcare data, enterprise secrets) and need hardware-level memory isolation, we offer Firecracker microVM isolation as a premium tier.

How warm pools work

Both tiers use adaptive warm pools to minimize latency:

• Standard tier: A pool of pre-created nsjail namespaces. When a user starts an agent run, they grab a namespace from the pool (instant). The pool size adjusts every 30 seconds based on recent demand using an exponential moving average. Target: enough warm namespaces to absorb ~2 minutes of traffic spikes without cold creates.
• Premium tier: A pool of pre-booted Firecracker VMs (~200 warm). When a user connects, they get a warm VM with the Go agent binary already running. Cold boot (when pool is exhausted): 125–500 ms, maskable by the first LLM call.

Agent quiescence signaling

Agents signal when they're done making tool calls (quiescence). This lets the sandbox manager recycle namespaces/VMs earlier, keeping the warm pool healthy. External signals (incoming email, webhooks, scheduled proactive tasks) pre-warm sandboxes before the agent run starts — so the namespace is ready when the first exec call arrives.

🗺️ Completed & remaining