Safety in Personal AI

🎯 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:

⚖️ 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

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. Applied as a Pre policy on both filesystem and exec tools.

M4: PII Redaction

Post-execution filter on all tool output. Regex patterns detect and redact:

• SSNs: XXX-XX-XXXX patterns → [REDACTED SSN]
• Credit cards: 13–19 digit sequences with Luhn validation → [REDACTED CC]
• API keys: Common prefixes (sk-, AKIA, ghp_, xoxb-, etc.) → [REDACTED API KEY]
• JWTs: eyJ... three-part dot-separated tokens → [REDACTED JWT]
• Private keys: PEM blocks (BEGIN RSA PRIVATE KEY, etc.) → [REDACTED PRIVATE KEY]

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, a validation callback checks the content for dangerous patterns: shell injection ($(), backtick commands), credential harvesting instructions, exfiltration URLs (webhook.site, requestbin, ngrok, etc.), and excessive permission requests. Validation errors block the write entirely; warnings are surfaced but the write proceeds.

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 Circuit Breaker

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

System prompt injection 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. This is a soft mitigation (LLM-level, not infrastructure-enforced) but has proven effective in testing.

🏗️ 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

And confirmed known gaps that require OS-level fixes:

• ⚠️ Exec can still read system files (/etc/passwd) — needs chroot/namespace
• ⚠️ Exec can enumerate PIDs (ps aux) — needs PID namespace
• ⚠️ No memory isolation between users (shared address space)
• ⚠️ /tmp is shared across all users

💾 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.

🧪 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: 31 of 33 attacks fully mitigated. 2 known gaps (system file read and PID enumeration) require OS-level namespace isolation. These are tracked and on the roadmap.

🗺️ Open gaps & roadmap

We believe in being transparent about what we've fixed and what remains open.

Roadmap

1. Phase 1 (done): Application-layer policies (M1–M10) + workspace jail + storage quotas
2. Phase 2 (next): nsjail per-exec — mount/PID/seccomp namespaces for subprocess isolation
3. Phase 3 (future): gVisor or Firecracker per-user sandbox when handling high-value credentials