Trust, by architecture.

Your agents already act with real credentials and real access. Crawdad governs each agent by its purpose and judges the action it takes, not the intent it claims, and every claim on this page is enforced by the architecture itself, not by policy documents or vendor assurances. Read the source, run the benchmark, verify the audit chain yourself, none of it asks you to take our word.

Architecture Docs → Public Benchmark

Three things a cloud gateway structurally can’t offer.

Verify the audit log yourself

A standalone open-source verifier (crawdad‑verify) checks the Ed25519-signed hash chain with no network, no Crawdad service, and no secrets from the audited machine. An auditor who distrusts us can build the tool and confirm integrity independently, a trust primitive a hosted gateway cannot offer symmetrically.

Don’t trust, verify

Local-first, on-device analysis

Prompt and response content is analyzed on-device and is never sent to a Crawdad-operated server by default. Off-machine telemetry is metadata-only, opt-in, and constrained by a red-team-tested allowlist that structurally cannot carry prompts, responses, or credentials.

Content stays on the machine

A benchmark you can run

A public, versioned corpus of 497 real agent attacks and 1,172 benign samples, CC BY 4.0, clone it and run it against any tool. We even name the one attack we miss and the one benign we flag. The honesty is the differentiator.

Clone & reproduce

Governed by purpose, enforced on the wire.

Detection tells a security team what an agent did. Governance decides what it is allowed to do in the first place. Crawdad governs each agent by an operator-declared charter it cannot see or edit, judges the action the agent took rather than the intent it claimed, and watches the shape of the whole session for staged compromise. Every primitive below is enforced on-device at the agent-to-tool boundary and proven by an over-the-wire block test against the real proxy.

Charters: govern by purpose

An operator writes a charter, held outside the agent’s control, declaring the agent’s real job as an allowlist over three axes: the tools it may call, the data (paths, hosts, recipients) it may touch, and the effects it may produce. Crawdad checks 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. The identical request from two agents can get two verdicts, because the charter decides, not the bytes.

Capability · target · effect

Trajectory: watch the whole session

A sequence of individually-allowed steps, enumerate then read progressively more sensitive in-scope data then send, can still compose toward harm. Crawdad measures that shape across the session with deterministic signals anchored to resource sensitivity, and gates an on-device reasoner onto the genuinely ambiguous cases. With no local model reachable, a completed staging chain is held for review, never silently allowed. The false-positive cost on ordinary multi-step work is measured at zero. It does not claim to catch every composed harm; it catches staged compromise that carries a sensitivity climb.

Escalation-shape · 0 benign FP

Local-first governance plane

Govern each agent by identity: autonomy ceilings (read-only through privileged), security zones that bound the tools an identity may touch, per-tool rules on a kill / deny / ask / observe / allow ladder, and a cumulative session-risk budget that escalates intervention as a session gets more dangerous. The primitives compose most-restrictive-wins and are authored in a simple policy file.

Autonomy · zones · session risk

Credential mediation, bypass-impossible

In broker mode the agent holds an opaque placeholder that authenticates only through Crawdad. The real key lives in a hardened AES-256-GCM store and never enters the agent’s environment, headers, or URL; sent straight to the provider, the placeholder is rejected before any upstream contact. Proven end-to-end across all five major providers. This is a credential-layer guarantee; the separate network-pinning layer runs on macOS and Linux today, with Windows in progress. Opt-in.

5 providers · proven E2E

Detection becomes protection

The arbiter promotes a single high-confidence detection to an inline block, so proxy-path blocking reaches 99.8% on the public benchmark, matching the detection rate, at an unchanged 0.09% false-positive rate and microseconds of added cost. The credential and data-exfiltration floors always block inline regardless.

Block 99.8% · 0.09% FP

Every one of these decisions is legible. An operator sees the live governance feed and per-session risk from the local dashboard, authors a charter that governs at the wire on the next action, and approves or denies a held action with a real effect on the running engine. Across a fleet, the self-hosted console rolls governance up per client and across clients, distributes charter templates that devices load, and surfaces held actions for triage.

Two further controls sit on the same on-device chokepoint: a dual-consent gate that structurally requires both an org policy and an on-device end-user consent record before any content-carrying telemetry can leave, and the external forensic anchoring covered in the Integrity & audit section.

Five properties, enforced by design.

Crawdad runs as a transparent proxy on each device. Raw content, prompts, responses, documents, is inspected and enforced locally. These aren’t features you enable. They’re properties of the architecture that you’d have to deliberately break to lose.

  • Built in Rust, 3,737 automated tests across 26 crates (mechanically counted 2026-08-22)
  • Multi-layer detection pipeline, all on-device
  • No Crawdad-operated server receives prompt or response content by default

Local-first

Raw content never leaves the device by default. Inspection, detection, and enforcement all happen on-machine. Metadata-only telemetry egresses by default; content does not. Telemetry depth is customer-governed.

Metadata-only telemetry

Metadata-only telemetry by default. The fleet console sees detection counts and posture signals, never raw prompts or responses.

Runs fully offline

Fully functional with no outbound connectivity. Detection, enforcement, and audit logging all operate entirely offline.

Transparent proxy

Sits in the network path as a local proxy. Every request to an AI provider passes through the detection pipeline before reaching the network.

On-device detection

The full multi-layer detection pipeline runs locally. No content is sent to a remote classification service by default. Latency is local, privacy is structural.

Hard floors

Credential and data-exfiltration blocks are mode-independent floors, enforced at three independent levels, a local user cannot lower them. The machine-learning classifier is an optional detection layer, not a dependency of the core blocks.

Every event chained. Anyone can verify it.

On each device, every security event is written to an append-only, SHA-256 hash-chained, Ed25519-signed forensic log. The signing key lives in the OS keychain (macOS) or a TPM-sealed store (Linux), not in the database. Any insertion, modification, or deletion breaks the chain and is detectable.

Precisely: it is a linear hash chain, not a Merkle tree, and it is tamper-evident, not tamper-proof. Tamper-evidence holds against an attacker with database write access; a root/same-user attacker who can read the signing key can re-sign a rewrite, which is exactly what external anchoring (below) is for.

Hash-chained forensic log
Event N-1 entry_hash: a3f7...
Event N prev_hash: a3f7...
Event N+1 prev_hash: c91d...
Ed25519 sig per entry
Append-only SHA-256 linked Ed25519 signed per entry Key in keychain / TPM Offline-capable

Append-only forensic chain

Every inspected request, detection, and policy decision appends a chain row, entry_hash = SHA‑256(prev_hash ‖ table ‖ row ‖ content_hash ‖ time), then Ed25519-signed. Delete or modify any row and the chain breaks at that point, visibly and cryptographically. Records can be crypto-shredded for GDPR erasure while preserving the chain entry and its hash, so it is tamper-evident and append-only, not “permanent.”

SHA-256 chain + Ed25519

Verify it without us

A standalone verifier walks the chain from genesis to head, checking linkage and every per-entry signature, with no network, no Crawdad service, and no secrets from the machine. Run crawdad verify-chain, or build the open-source crawdad‑verify yourself. Content-hash verification is deliberately out of scope so that a distrusting auditor can still build and run the tool.

Public-key verifiable

Anchor beyond local admin

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). crawdad‑verify ‑‑anchor then cross-checks the live database against that off-machine record, catching a re-signed rewrite that internal verification alone would pass. A dedicated re-sign test proves exactly this. Anchoring is opt-in; it protects once the witnessed value is genuinely held off-machine.

External anchor (opt-in)

Contemporary Agent Attacks: a public benchmark that names its own misses

Crawdad's detection engine is measured on Contemporary Agent Attacks, a public, versioned corpus of 497 real agent attacks and 1,172 benign samples across 22 categories, licensed CC BY 4.0. On this corpus the full engine detects 496 of 497 (99.80%) at a single false positive (0.09%), and we name both the one attack we miss and the one benign sample we flag.

99.8% detection-engine accuracy on a public, reproducible benchmark

Read this precisely: 99.8% is the detection engine’s accuracy, measured with the ML classifier run on every input, which is how the proxy runs it. It is the detection rate. Blocking is a separate decision the arbiter makes, and stating the two apart is a point of rigor, not a caveat. The credential and data-exfiltration floors always block inline. For every other detection, the arbiter promotes a single high-confidence hit to an inline block, so proxy-path blocking reaches 99.8% as well, at an unchanged 0.09% false-positive rate and microseconds of added arbiter cost. Detection and blocking coincide here because the arbiter is built to make them coincide.

497attacks tested
1,172benign samples
0.09%false-positive rate
1missed attack
Every result is published. We’re not aware of another vendor in the category that publishes a reproducible, clone-and-run benchmark. Clone the corpus, run it against your tool, compare, every number on this page is verifiable.
The miss (1 of 497) A bare social-engineering pretext opener in the human-agent-trust category (holdout set). Disclosed and tracked in the published results.
The false positive (1 of 1,172) A StackOverflow question about Go method receivers, with GitHub source links, flagged by the pattern layers, not ML. Disclosed and tracked.

Last full re-verify 2026-08-02 (496/497 detected, 1 false positive). Without the ML layer, the pattern-only floor is 37.8%, ML is a booster on top of deterministic patterns, not a gate. This is an evaluation corpus, not training data, so “overfitting” doesn’t apply, but one benchmark isn’t everything, and no external party has independently re-run it against a running sidecar yet.

AndrewSispoidis/contemporary-agent-attacks →

Machine-readable dataset record (schema.org Dataset, JSON-LD) →

CC BY 4.0 · 497 attacks · 1,172 benign negatives · 22 attack categories

Architected for compliance. Not certified, transparent.

Crawdad’s architecture maps to the frameworks below. We do not claim certification. We publish the architecture, the controls, and the benchmark so your compliance team can evaluate the fit themselves.

Architected for SOC 2 controls

The controls map to the Trust Services Criteria: local-first data handling, tamper-evident audit trails, signed enforcement floors, and metadata-only telemetry by default. Your auditor evaluates the mapping against source you can read.

Trust Services Criteria SOC 2 controls

PHI stays on the device

Protected health information never leaves the machine by default and is never included in telemetry. Because content is inspected on-device, there is no Business Associate Agreement to sign for content inspection, and nothing for a covered entity to hand a third party. The model fits organizations working toward HIPAA.

HIPAA HITECH

Architected for GLBA

Financial data stays on the institution’s own infrastructure. This on-device model, where raw content never leaves the machine by default, and tamper-evident audit logs support the GLBA Safeguards Rule and SEC 17a-4 recordkeeping, evaluated against the published architecture.

GLBA SEC 17a-4 SOX

Data sovereignty & offline deployment

Crawdad runs fully offline, with no outbound connectivity requirement. Detection, enforcement, and audit all operate on-device with no telemetry dependency, so data stays within sovereign boundaries for government, defense, and critical-infrastructure environments.

Data sovereignty Offline On-prem

NIST AI RMF alignment

The detection pipeline, audit architecture, and enforcement model align with the NIST AI Risk Management Framework practices for AI-system governance and risk mitigation.

NIST AI RMF AI governance

Source-available. Not open source.

Crawdad’s product code is licensed under the Business Source License 1.1 (BSL 1.1). You can read every line of source. You can audit the detection pipeline, the proxy architecture, the audit-log implementation. BSL 1.1 is source-available, it is not an open-source license.

The benchmark corpus is a separate work, licensed under Creative Commons Attribution 4.0 (CC BY 4.0). Clone it, redistribute it, build on it. The two licenses cover different things.

  • Product source, auditable, not redistributable
  • Benchmark corpus, freely redistributable
  • Two works, two licenses, clearly separated
Work License You can
Crawdad product BSL 1.1 Read, audit, and inspect all source code. Use under license terms. Not open source, not freely redistributable.
Benchmark corpus CC BY 4.0 Clone, redistribute, and build upon the benchmark corpus with attribution. Run it against any tool.

The sensitive stores are encrypted, fail-closed.

We state this precisely, per store, rather than a blanket “encrypted” or a blanket “no encryption at rest.”

Sidecar 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 at rest 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.

SQLCipher AES-256 · fail-closed

Keys & ML model

Device keys and the audit signing key are sealed with AES-256-GCM in a hardened key store. On Apple-silicon machines the ML model is encrypted with a Secure-Enclave-bound key; on other hosts the model file is plaintext (it contains no customer data).

Hardened key store

Gateway & console DBs

The management gateway and console databases are plaintext SQLite/Postgres that rely on OS full-disk encryption (FileVault, LUKS, or the managed provider’s at-rest encryption). We recommend enabling full-disk encryption; Crawdad-managed at-rest encryption there is on the roadmap.

OS disk encryption

What’s shipped, and what isn’t, yet.

We publish the gaps too. Nothing below is presented as done until it is.

Certifications

SOC 2 and FedRAMP are architected-for, not started, we never claim certification. No independent third-party penetration test has been completed yet (planned). A vulnerability-disclosure policy is in place, with a 24-hour acknowledgment commitment.

Platforms

Full runtime enforcement runs on macOS and Linux: a Developer-ID-signed local proxy that blocks routed traffic, plus an opt-in sealed-VM Workspace on macOS. Windows runs today for monitoring and the mandatory credential broker, with full Windows enforcement on the roadmap. A macOS System Extension for system-wide interception is built and pending an Apple entitlement; until it is granted, protection covers agents routed through Crawdad rather than every process on the machine.

Detection vs. protection

The 99.8% figure is detection-engine capability. Blocking is the arbiter's decision: the credential and data-exfiltration floors always block inline, and a single high-confidence detection is promoted to an inline block, which puts proxy-path blocking at 99.8% on the benchmark at a 0.09% false-positive rate. We state detection and blocking separately on purpose, because they are separate mechanisms. And Crawdad protects agents whose traffic is routed through it, not every agent on the machine system-wide.

Security posture you can verify. Not just trust.

Read the source. Run the benchmark. Verify the audit chain. Talk to us about how Crawdad’s architecture maps to your security and compliance requirements.

Contact Us → Architecture Docs

Get in Touch

Tell us about your needs and we'll follow up.