Trust Center

Security Overview

Crawdad is a local security tool for teams deploying autonomous AI agents. The sidecar runs entirely on your machine. Metadata-only telemetry (event counts, categories, verdicts) egresses by default, raw content (prompts, responses, action parameters, PII) never does. This is enforced by a sanitization chokepoint in the architecture, not policy. Telemetry depth is customer-governed and off by default; enabling content-carrying (full) telemetry requires explicit authorization and is recorded in the audit chain. The one opt-in exception is the L7 cloud LLM Judge (off by default, gated behind an explicit warning), which sends content to a third-party model if you enable a cloud backend. The system is implemented in Rust for memory safety; 3,737 automated tests across 26 crates (mechanically counted 2026-08-22; run grep -rhoE '#\[(tokio::)?test\]' --include='*.rs' crawdad-* to reproduce).

Five architectural invariants are property-tested over 1,000,000 iterations on every release by the crawdad-zk-verify crate. A standalone getcrawdad/zk-verify MIT reproducer is on the roadmap so any operator can confirm the invariants against a running sidecar independently.

Reproducible Detection Benchmark

Crawdad's detection claims are reproducible. The AndrewSispoidis/contemporary-agent-attacks repository contains 497 attacks across 22 categories, 1,172 benign samples across 4 sources, and a tool-agnostic benchmark runner, licensed CC-BY 4.0 so any operator, researcher, or competing vendor can run it against any classifier.

Current Crawdad result on the public corpus (full detection engine, ML on every input; last full re-verify 2026-08-02): 496/497 = 99.80% detection, 0.09% false-positive rate (1/1,172), F1 99.80%. The visible set is 395/395 (100%); the single miss is a bare social-engineering pretext opener in the 102-sample holdout. The one false positive is a StackOverflow question about Go method receivers (with GitHub source links), flagged by the pattern layers, not ML. Without the ML layer the pattern-only floor is 37.8%, ML is a booster, not a gate.

Detection is not the same as blocking. The 99.80% figure is a detection-engine measurement, not a “protection rate.” The ML classifier runs on every input (no prefilter gates inference); what varies is blocking. The credential and data-exfiltration floors always block inline. For every other detection, the arbiter promotes a single high-confidence hit (ML or dynamic signature, confidence at or above 0.70) to an inline block, which puts proxy-path blocking at 99.80% on this corpus at an unchanged 0.09% false-positive rate and microseconds of added arbiter cost, measured in-process on the same benchmark. Detection and blocking are reported separately because they are separate mechanisms; here they coincide because the arbiter is built to make them coincide. No external party has independently re-run the corpus against a running sidecar yet.

Reproduce it:

git clone https://github.com/AndrewSispoidis/contemporary-agent-attacks
cd contemporary-agent-attacks
python3 benchmark/run.py --adapter adapters.crawdad --tool crawdad-v1.7.1

The benchmark runner accepts adapters for any tool exposing an HTTP scan endpoint, see CONTRIBUTING.md for submission guidelines.

Per-Agent Isolation, Trust System v1.0

Every agent that talks to Crawdad runs at one of four trust levels: Autonomous (full L1–L6 detection, L7 skipped, no restrictions), Monitored (full L1–L7, default for new agents), Restricted (full pipeline + active per-tool-call restrictions), Quarantined (all requests return HTTP 403 before detection runs).

• Per-agent enforcement, not per-provider, each inbound request is attributed at connection time by resolving the caller's TCP socket to its owning PID and walking the process tree for a classifiable agent ancestor. Blocking one agent never affects another agent on the same provider. An attacker compromising a low-trust agent cannot reach another high-trust agent's quota or traffic.
• Automatic escalation on detection, when any detection fires on an attributed agent, the system ratchets its trust level down according to a fixed rule set: score-based (≥50 escalates Autonomous, ≥70 escalates Monitored, ≥90 escalates Restricted), rate-based (two detections in 5 min, three in 10 min), and category-based (exfiltration patterns quarantine immediately from any level). This is the 3am-incident backstop, even with no human in the loop, a compromised agent's blast radius is bounded.
• Configurable auto-recovery, agents walk back toward Autonomous after configurable quiet periods (default 1 h for Monitored → Autonomous; default off for Restricted and Quarantined recovery, requiring human review). Manual level changes are never auto-reverted.
• Every transition is audited, level changes are recorded in the tamper-evident audit log with the triggering event, previous level, new level, and whether it was manual or automatic. The agent detail view in the dashboard shows the full trust timeline.
• Fail-open on attribution failure, if the PID lookup fails (permission denied, process exited, unsupported platform), the connection is treated as an unknown agent at Monitored level. Full scanning runs, no restrictions apply, never blocked. We don't deny legitimate traffic because the OS refused to cooperate with a lookup.

Scope of v1.0. What ships: per-agent attribution, the four levels, automatic escalation with the rules above, auto-recovery, default restrictions on entry to Restricted, audited transitions. What's roadmap: fleet-wide policy hierarchy, cross-device trust sync, industry policy templates.

Governance plane. At the agent↔tool boundary, Crawdad enforces autonomy ceilings (read-only through privileged), security zones, blanket per-tool rules, and a cumulative session-risk budget, composed most-restrictive-wins and authored in a policy file. Each primitive is proven by an over-the-wire block test against the real proxy.

Contextual Agency Governance. An opt-in charter governs an agent by purpose: an operator-declared allowlist over the tools, data, and effects its job needs, held outside the agent's control and enforced on the observed action, so a deceptive stated intent buys nothing and an out-of-charter action is blocked at the wire with the axis named. A trajectory layer watches the shape of the whole session for staged compromise (enumerate, read progressively more sensitive in-scope data, then send) that no single-action check would catch, with deterministic sensitivity-anchored signals plus an on-device reasoner gated onto only the ambiguous cases; a completed staging chain is held for review when no local model is reachable, never silently allowed. Ordinary multi-step work is measured at zero false positives, and it does not claim to catch every composed harm. Every charter and trajectory decision is recorded to the tamper-evident audit chain, metadata only, and surfaced on the local dashboard (live feed, per-session risk, a review queue with a real engine effect, and charter authoring that governs at the wire) and rolled up per client and across clients in the Fleet Console.

Remote Control Plane, Security Controls

Crawdad ships a remote control plane that lets operators monitor agents and change trust levels from a paired phone. The plane is built so the on-device guarantee still holds, the relay sees only encrypted blobs and opaque device IDs, and a layered set of controls bounds what a paired device (or a compromised one) can do.

• Ed25519 command signing, every command originating from a paired device (change trust, release quarantine, acknowledge alert) is signed with the device's Ed25519 key. The sidecar verifies the signature against the stored public key for that device before any command is honored.
• Replay prevention, commands carry a monotonic nonce and timestamp. The sidecar rejects any command with a nonce it has already seen or a timestamp outside a bounded window.
• AES-256-GCM encryption for relay traffic, state snapshots pushed from sidecar to phone and alerts streamed from sidecar to phone are AES-256-GCM encrypted with a key derived during pairing. The relay forwards ciphertext it cannot decrypt.
• Per-device rate limits, 5 trust-level changes per 10 minutes per device. 1 quarantine release per hour per device. Rate limits are enforced at the sidecar; the relay has no authority to make rate-limit decisions.
• Local kill switch, the desktop Settings → Paired Devices → Disconnect action invalidates the device's key immediately. Any in-flight or future signed command from that device is rejected; no network round-trip to the relay is required.
• Permission scoping per device, each paired device is tagged view-only or full-control. View-only devices can read state snapshots and receive alerts but cannot issue trust-change or quarantine-release commands; the sidecar rejects unauthorized commands independent of signature validity.
• PIN gate, sensitive actions can be PIN-gated on the phone. The PIN is used to unlock the local signing key; it never transits the relay.
• Audit trail for remote commands, every accepted remote command is written to the tamper-evident audit log with the device ID, previous level, new level, and trigger string, indistinguishable from a local admin action in the audit chain.
• Pairing-database isolation, paired-device records live in a dedicated pairing_db SQLite file (WAL, synchronous=NORMAL) separate from the audit and metering databases, so recovery or rotation of one domain does not touch the others.
• Tool-name anonymization (optional), tool names are included in remote state snapshots by default (e.g., Read, Bash, WebSearch). If your agents use custom-named tools that could reveal the nature of your work, enable "Anonymize tool names" in Settings to replace them with generic categories (file_read, file_write, shell, web, api_call, other) before they leave your machine. The local audit trail and dashboard always show the real names, the mapping only applies to the encrypted snapshot pushed to paired devices. Startup default is off; flip at runtime via Settings (desktop or mobile) or set CRAWDAD_ANONYMIZE_TOOLS=1 to enable at boot.

NIST 800-53 alignment. Relevant controls: AC-2 (account management, paired device lifecycle), AC-3 (access enforcement, signature + scope checks), AC-7 (unsuccessful logon attempts, rate limits), AU-2/AU-3 (auditable events, every accepted command audited), IA-2 (identification & authentication, Ed25519 per-device), SC-8 (transmission confidentiality, AES-256-GCM relay), SC-13 (cryptographic protection, Ed25519 + AES-GCM), SI-4 (system monitoring, local kill switch + audit trail).

Protection Mode Auth Boundary

Mode-changing endpoints (/api/v1/mode and /api/v1/mode/unpause) are mounted only on the management API and are not reachable from the proxy data path. A prompt-injection payload that arrives through traffic on the provider proxy ports cannot trigger a mode change or pause. Mode changes from a paired mobile device are signed and audited. Pause does not unquarantine quarantined agents, quarantine state is independent of mode. Allow-Always rules continue to apply at every mode.

Forensic logging continues at every mode. When a detection would have blocked but is suppressed by Reduced or Paused mode, an audit_events row is recorded with action_taken="suppressed_by_mode" and a detail JSON containing the layer, category, protection_mode at time of event, and agent identity. The spec promise, "audit log gets fuller, never thinner, when protection is reduced", holds.

Data Storage

• Local-only storage, all data is stored on your machine in SQLite databases under a per-user data directory (~/Library/Application Support/crawdad/ on macOS, ~/.local/share/crawdad/ on Linux, %APPDATA%\crawdad\ on Windows). The directory is created with owner-only permissions (0700) and the sidecar refuses to start on a group- or world-accessible path. Crawdad does not transmit content to any external server.
• Encryption at rest (per store), the sidecar's sensitive stores, the forensic/session database (which can hold blocked payloads and full request/response content), the cost-tracker, the MCP session log, and the pending-action DB, are encrypted with SQLCipher (AES-256), keyed from a master key in the OS keychain (macOS) or systemd-creds/TPM (Linux); the sidecar refuses to start rather than run these unencrypted. Device keys and the audit signing key are additionally sealed with AES-256-GCM in a hardened key store. The management gateway and console databases are plaintext and rely on your operating system's full-disk encryption (FileVault, LUKS, or the managed provider's at-rest encryption), we recommend enabling full-disk encryption.
• Cryptographic audit trail, audit log entries are SHA-256 hash-chained (a linear hash chain, not a Merkle tree) and Ed25519 signed, providing tamper evidence and non-repudiation. The chain can be checked by a standalone verifier with no network, no Crawdad service, and no secrets from the machine.
• API forwarding, requests are forwarded to AI providers over HTTPS (TLS 1.2+), exactly as your agent would send them without Crawdad.

Access Controls

• API keys, scoped, rotatable tokens for SDK and REST API access. Each key is bound to a single project and can be revoked instantly.
• Admin keys, separate elevated credentials for account management, billing, and configuration changes. Never used for runtime operations.
• Audit trail, every access event (login, key creation, key rotation, policy change) is recorded in the tamper-evident audit log.
• Least privilege, all internal services run with minimal permissions. No service has access to another service's data unless explicitly required.

Audit Logging

• Tamper-evident log, audit records are chained in a cryptographic SHA-256 hash chain (a linear hash chain, not a Merkle tree). Any modification or deletion is detectable via chain verification. Administrators may trigger crypto-shredding of content (GDPR erasure), which replaces content with [ERASED] while preserving the chain entry and its hash for tamper evidence, so the log is tamper-evident and append-only, not “permanent.”
• SHA-256 hash chain, each entry is chained to the previous one as entry_hash = SHA-256(prev_hash ‖ table ‖ row ‖ content_hash ‖ time). Any modification to a past entry invalidates all subsequent hashes.
• Ed25519 signed, every log entry is digitally signed with Ed25519 using a device key held in the OS keychain / TPM-sealed store, not in the database, providing cryptographic proof of authenticity and non-repudiation.
• Verify it yourself, and anchor beyond local admin, run crawdad verify-chain or the standalone source-available crawdad-verify (no network, no service, no secrets from the machine). Tamper-evidence holds against an attacker with database write access; to raise the bar past a root/same-user attacker who could re-sign a rewritten chain, the chain head can be anchored to an external witness (opt-in), and crawdad-verify --anchor cross-checks the live database against that off-machine record, catching a re-signed rewrite that internal verification alone would pass.
• Retention, 7 days on Free, 30 days on Pro, 60 days on Team, 90 days on Business, unlimited on Enterprise. Logs are exportable in CEF/JSON at any time.

Incident Response

• 4-hour alert window, all affected customers are notified within 4 hours of confirmed security incident detection.
• Public advisories, security advisories are published at getcrawdad.dev/docs/advisories.html with full technical detail.
• Responsible disclosure, we follow coordinated disclosure practices and credit researchers who report vulnerabilities.

Compliance

• GDPR, Crawdad stores data locally on your machine. No personal data is processed by Crawdad's servers. You have direct control over all stored data and can delete it at any time.
• SOC 2 Type II, not yet completed.
• FedRAMP, not yet completed.
• HIPAA, Crawdad's local-first architecture means no PHI is transmitted to Crawdad. Contact contact@getcrawdad.dev for compliance questions.

Penetration Testing

• No professional third-party penetration test has been completed.
• Results will be published publicly in full, with no redactions beyond researcher-requested coordination delays.

Responsible Disclosure

If you discover a security vulnerability in Crawdad, please report it through the contact form at getcrawdad.dev. We commit to a 24-hour initial response and will work with you to understand and resolve the issue before any public disclosure. We do not pursue legal action against good-faith security researchers.

Contact

For security questions, vulnerability reports, or compliance inquiries: