"We have guardrails." Here's what they cover, and what they don't.
Guardrails are real and useful: they filter inputs and outputs, block categories of content, validate schemas, and flag policy concerns on the text going in and coming out of a model. But an agent's risk isn't only in the text. It's in the action: what content the agent consumed, which identity it used, which tool it called, what data it could expose, and where it could send it. Runtime agent security governs that action path.
A serious agent deployment uses both guardrails and runtime security. They do different jobs.
What guardrails do well
Guardrails operate on the content boundary — the prompt in and the response out:
- Filter or block categories of harmful, unsafe, or disallowed content.
- Validate that outputs match an expected schema or format.
- Redact or flag sensitive strings in inputs and outputs.
- Enforce content policies on what the model is asked and what it says.
For content-safety and output-quality concerns, that's valuable, and you should keep it. It is not, by design, watching what the agent does with tools, credentials, and data once it has acted on that content.
What guardrails don't cover
An agent is dangerous because it acts, not just because it speaks. The action path raises questions a content filter isn't positioned to answer:
- What content did the agent actually consume? Including untrusted content — a webpage, a document, a tool result — that carried a hidden instruction.
- Which identity is acting, and what is it allowed to do? The same request should be allowed for one agent and blocked for another, based on the agent's job.
- Which tool did it try to call, and against what? A prohibited tool, or the right tool against the wrong data.
- What could it expose, and where could it send it? Credentials, files, customer data — and the network destination it would go to.
- Did the whole sequence stay within bounds? A series of individually-fine steps that add up to recon, collection, and exfiltration.
A guardrail filtering the prompt never sees the injected instruction that arrived inside a trusted document, and it isn't governing the tool call or the egress that follows.
What runtime agent security does
Crawdad runs on the device, on the wire between the agent and the model, and governs the action path:
Per-agent boundaries
Each agent gets a charter — an allowlist of tools, data, and effects — enforced on the observed action. Out of bounds is blocked at the wire, and the block names why.
Judged on action, not claimed intent
A deceptive stated intent buys nothing; Crawdad evaluates the tool call the agent actually makes.
Credentials made unusable if stolen
The real key never enters the agent's environment; a leaked placeholder authenticates nowhere.
On-device, verifiable
Nothing leaves your machine; every decision is written to a log you can verify yourself.
Neither one is the whole answer. Use both.
We're not going to tell you guardrails are useless — that would be wrong, and you'd know it. Guardrails do a real job on the content boundary. Runtime agent security does a different job on the action path. And neither eliminates the need for least privilege, secrets management, tool-side authorization, sandboxing, human approval for high-stakes actions, logging, and governance.
A mature agent deployment layers these: guardrails on the content, runtime enforcement on the action, plus the fundamentals underneath. Crawdad is the runtime-enforcement layer — the one that governs what the agent is allowed to do when hostile text inevitably gets past the filter. And it publishes a public, reproducible benchmark of 497 real attacks so you can check that claim yourself.
Free tier, every feature. Monitor mode by default. One command, one env var.