How Crawdad Handles Your Data

Full technical transparency. Zero-knowledge by architecture, not by promise.

1. The Architecture

Your Machine
Agent → Crawdad Sidecar (localhost:7749) → Decision (allow/block)
                     ↑↓
              Signed counts only
                    ↓
Crawdad Cloud (metering, licensing, signature updates)

All content scanning — firewall analysis, policy evaluation, PII detection, memory integrity checks — happens locally on your machine inside the Crawdad sidecar process. The sidecar binds exclusively to 127.0.0.1:7749 and never exposes content to any external network.

2. What Never Leaves Your Network

✓ Message content — inbound text scanned by the firewall
✓ Action parameters — tool calls evaluated by the policy engine
✓ Agent responses — outbound text scanned for PII
✓ PII values — detected personally identifiable information
✓ Memory content — agent memory entries and context
✓ Private keys — stored in your system keychain, never transmitted

Even if Crawdad's servers were fully compromised, there is no customer content to retrieve. This is enforced by architecture, not by policy.

3. What Is Transmitted to Our Servers

The sidecar sends a signed metering packet every 60 minutes containing only operation counts:

{
  "tenant_id": "t_abc123",
  "device_id": "d_xyz789",
  "sequence": 42,
  "counts": {
    "firewall_scans": 142,
    "action_authorizations": 89,
    "outbound_scans": 142,
    "memory_writes": 23,
    "privacy_classifications": 67
  }
}

This packet is signed with your device's Ed25519 key. Any tampering invalidates the signature. No content, no parameters, no PII values — only how many operations ran.

4. What Is Stored Locally

audit.db — SHA-256 hashes of content (not reversible), decisions, risk scores, PII category names (not values). Merkle-chained for tamper detection.
metering.db — Atomic counters by operation type. No content.
signatures/ — Ed25519-verified detection pattern bundles, polled every 4 hours.
device.cert — Short-lived device certificate (24-hour expiry, auto-renewed).

5. How to Verify Independently

Run crawdad verify to get a cryptographically signed attestation:

$ curl http://127.0.0.1:7749/v1/verify

{
  "architecture": "Zero-knowledge sidecar v0.5.0",
  "data_never_leaves": [
    "Message content",
    "Action parameters",
    "Agent responses",
    "PII values",
    "Memory content",
    "Private key"
  ],
  "data_sent_to_server": [
    "Signed metering counts (operation totals only)",
    "Device certificate renewal requests"
  ],
  "audit_chain_valid": true,
  "sidecar_bound_to": "127.0.0.1:7749"
}

You can also inspect the audit database directly:

$ sqlite3 ~/.crawdad/audit.db ".schema"
-- No content/message/text columns exist.
-- Only: entry_id, timestamp, endpoint, decision,
--       risk_score, content_hash, pii_categories, chain_hash

6. Threat Model

What we protect against

Prompt injection and jailbreak attacks (27 detection patterns)
Unauthorized tool execution (policy engine with Rule of Two)
PII leakage in agent responses (15 detection categories)
Memory tampering (Merkle-chained integrity verification)
Malicious skill injection (SHA-256 attestation + SBOM analysis)
Agent collusion and cascade failures (Byzantine fault detection)

What we do not protect against

Vulnerabilities in the underlying LLM itself
Social engineering of human operators
Physical access to the machine running the sidecar
Zero-day exploits in the Rust runtime or OS kernel

7. Deployment Modes

Sidecar (zero-knowledge) — all scanning local, signed counts to cloud for billing. Recommended for all production use.
Cloud API — content processed server-side. Available for development/testing convenience. SDK warns when using this mode.
Air-gap — fully disconnected. Sidecar runs without any network access. Metering reconciled offline. Available for Enterprise and Government tiers.