What is the difference between monitoring and containment for AI agents?

Monitoring and detection watch agent traffic and raise an alert when something looks like an attack; that is the smoke alarm, and it is valuable. Containment acts on it. In Enforce mode Crawdad installs an operating-system default-deny egress lock so a governed agent can reach only the Crawdad proxy path, and the Maximum tier runs the agent inside a sealed VM whose only network interface routes through Crawdad. For an MSSP, that is the difference between reselling an alert and operating a control that stops a compromised agent from reaching anything else.

Can one MSSP manage AI agent security for many clients from a single console?

Yes. The self-hosted Fleet Console models each client as an isolated scope subtree with role-based access, so an analyst sees only the clients they are granted. Provision a client, roll out to its fleet with one enrollment key, distribute charter templates that govern at the wire, and roll every client up into one view with per-client threats, open holds, and metered cost.

Does one client's content stay isolated from another's?

Raw content, prompts, responses, and documents never leave the client's machine by default; what reaches the console is metadata only, per the red-team-tested telemetry chokepoint. Per-client tenancy and isolation are enforced by the scope model and verified end to end. No client's prompt or response content is aggregated centrally.

Enforce mode · new in 1.6

Your SOC watches for the attack. Crawdad also stops it.

Detection and monitoring are how the category watches for trouble, the smoke alarm, and it earns its place. Crawdad adds the control that acts on the alert: an operating-system egress lock and sealed-VM containment that stop a compromised agent from reaching anything but the Crawdad path. For an MSSP, that is the difference between reselling an alert and operating a control that contains the incident. Multi-tenant, zero-knowledge, one console for every client.

Become a Partner → Download the Partner Brief

Crawdad Fleet Console, multi-tenant AI agent containment across your client base

Fleet Console, per-client tenancy and enforcement posture across every client

Response authority

The market already knows the axis buyers evaluate on. Monitoring, or active containment.

Nearly everything in the AI-security aisle today watches: it inspects traffic and raises an alert. That is real value and Crawdad does it well. But an alert is not a control. When a client asks what actually happens to a compromised agent, an MSSP wants an answer that ends in contained, not flagged.

What everyone resells

Monitoring & detection

Watching for smoke

Inspects agent traffic and scores it for attack patterns
Raises an alert, a verdict, a dashboard entry
Tells you an agent was targeted, after the request is on the wire
Response authority stops at notification, the next move is a human's

What Crawdad adds

Active containment

Putting out the fire

Everything monitoring does, plus a control that acts on it
Enforce installs an OS default-deny egress lock, the agent reaches only the Crawdad path
Maximum seals the agent in a VM whose only network interface routes through Crawdad
Response authority reaches all the way to contained, at the operating system, not by asking the agent nicely

Detection is the foundation, and Crawdad's is benchmarked in the open. Containment is the control you can point to in an incident review. Selling both, from one platform, is the differentiated MSSP offer. See detection and blocking, attack by attack →

The enforcement boundary · new in 1.6

A control your analysts operate. Proven on real hardware.

Monitor is the default, a stock device is byte-for-byte unchanged. Move a client's devices into Enforce and the operating system itself makes Crawdad the only path off the machine. Everything below is opt-in, pinned per client from the console, and proven, not asserted.

Enforce · the OS egress lock

Locked at the operating system, not by policy

Enforce installs a persistent OS default-deny egress lock (pf on macOS, iptables on Linux). A governed agent reaches only the Crawdad proxy path; everything else, including UDP/QUIC, is denied by construction.

›The lock persists across a kill of the Crawdad process, so the boundary doesn't vanish if the enforcer dies.
›Proven against a live Linux kernel: default-deny to-any, UDP/QUIC, kill -9 persistence, clean removal; and on macOS pf.

Maximum · sealed-VM containment

Containment by construction

The opt-in Maximum tier runs the agent inside a sealed VM (macOS/arm64, Apple's Virtualization framework) whose only network interface routes through Crawdad. Escape is refused at the packet level, not by a deny rule.

›On real Apple-silicon hardware, an adversarial escape battery inside a live sealed VM was fully blocked, and the host filesystem was byte-identical after a guest destruction battery.
›Liveness-gated, fail-closed: with the VM capability absent it falls back to the Standard egress-lock floor and reports the configured vs in-force tier honestly.

Break-glass · fail-closed

Hard to turn off, on purpose

Because the lock survives a kill, there is a deliberate recovery path, and it is deliberately hard to reach, exactly the audit story a SOC wants.

›Break-glass requires root and a device-administrator token, is written to the tamper-evident audit chain, and auto-reverts to Enforce at expiry. The agent can never invoke it.
›Fail-closed by default: if Crawdad is alive but can't inspect a request, it blocks rather than forwards. There is no degraded fail-open path.

Platform, stated plainly. Full runtime enforcement runs on macOS and Linux. Windows runs Crawdad today for monitoring and the mandatory credential broker, but there is no OS egress lock yet; we report that rather than imply parity, and full Windows enforcement is on the roadmap. Read the Enforce mode guide →

Multi-tenant by construction

Every client, walled off. One console.

An MSSP lives or dies on isolation. In Crawdad, each client is its own scope subtree with role-based access, so an analyst sees only the clients they are granted. And because the architecture is local-first and zero-knowledge, the isolation is structural, not a filter: one client's prompts and responses never leave that client's machines, so they cannot mix in a shared store because there is no shared store of content.

Per-client tenancy and isolation enforced by the scope model, verified end to end
Raw content stays on each client's machines; the console holds metadata only
A regulated client (HIPAA-style, GLBA-style) can be walled off from the rest of the book
Governance, threats, and enforcement posture roll up per client and across clients
Charter templates authored once, distributed to a client's devices, governing at the wire

We prove this the honest way: a repeatable, clearly-labelled synthetic environment stands up several fictional customer orgs across real verticals and shows the isolation, posture spread, and rollup end to end. It is watermarked synthetic throughout, never presented as real customers.

Fleet Console, per-client tenancy and isolation for an MSSP book of business

Crawdad Dashboard, per-client detection trends and enforcement posture

Fits the SOC you already run

Provision, contain, prove, and stream to your stack.

The multi-tenant model, the enforcement rollout, the review queue, and the exports are part of the product, not services you assemble. Crawdad rides alongside the tools your analysts already live in.

Provision & roll out

A client, then its fleet

Create an isolated client scope, then roll out with one minted enrollment key and a ready-to-run package: the enroll command, the unattended installer invocations, and the CA fingerprint pin. Devices self-enroll with no per-device signing. Push it through the RMM or MDM you already run.

Contain & review

Set the posture, resolve the holds

Set enforcement per client and pin it fleet-wide. A charter bounds what a client's agents are for, judged on the action taken, not the intent claimed; held actions surface in a cross-client review queue your analysts resolve from the console, releasing a session or keeping it gated.

Prove

A report you can hand the client

Every device event lands in a tamper-evident, hash-chained audit log, Ed25519-signed and offline-verifiable with an open-source tool, no network and no secrets from the machine. Verifiable forensics is the report you hand a client after an incident.

Stream & bill

Into your SIEM, onto your invoice

Export detection and governance events to your SIEM over Splunk HEC or OpenTelemetry, so agent-layer signal lands where your analysts already work. Bill per governed device at $4.99/month through Stripe metered usage records, counted from the real device inventory.

Trajectory reasoning watches the shape of a whole session and holds a staged compromise for review, the exfiltration whose every single step looked fine. No runtime check catches every composed harm; this catches the staging shape, at a false-positive cost measured at zero on benign multi-step work. The whole model runs on your own self-hosted console, with each client's content staying on their machines.

Detection you can check

99.8% detection on a public, reproducible benchmark

99.8% is what the detection engine catches on the corpus, the local sidecar's full multi-layer ML pipeline running in-line on proxied traffic. On the proxy path the arbiter blocks what it detects, at a 0.09% false-positive rate. Detection and blocking are named as separate mechanisms, on purpose. How detection becomes blocking →

497attacks tested

1,669total samples

0.09%false-positive rate

1missed attack

Every result is published, including the one miss and the one false positive. Clone the corpus, run it against us or anyone, and compare. In a category full of unverifiable assertions, a reproducible benchmark is the point, not the footnote.

Multi-layer detection pipeline. Built in Rust. 3,737 automated tests across 26 crates. Zero-knowledge by default, raw content stays on the client's machine, metadata-only telemetry unless air-gapped.

AndrewSispoidis/contemporary-agent-attacks →

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

MSSP economics

A control you can price. A tier above the feed.

Containment is a higher-value service than a feed of alerts. Crawdad gives you something to charge for that your clients can feel.

Differentiate

Sell the control, not just the alert

Most of the market resells detection. An MSSP that can say "and here is the control that contained it, at the operating system" has a story the alert-only competitor can't match, backed by proof, not adjectives.

Additive

Alongside your existing stack

Crawdad covers the agent layer that EDR, DLP, identity, and network tools don't see, and streams its signal into the SIEM your analysts already run. Additive to your SOC, not a rip-and-replace.

Timing

Define the containment tier first

Agent security is nascent, and containment is the part most vendors haven't reached. The MSSPs who bring a real control now set the standard their clients measure everyone else against.

For your evaluation, stated plainly: full runtime enforcement runs on macOS and Linux; Windows runs today for monitoring and the mandatory credential broker, with full Windows enforcement on the roadmap. SOC 2 is architected-for, not certified, and no third-party security audit has been completed. 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. We have no customer or production-deployment claims to make in either direction. See the full trust posture →