Launching Clampd: runtime firewall for AI agents
Hey IH
Just launched Clampd: a self-hosted runtime firewall for AI agents. Sits between the agent and its tools, inspects every call before it runs, blocks the destructive ones.
Works across the whole stack: coding agents (Cursor, Claude Code), MCP servers, agent SDKs, A2A delegation chains, CI/CD pipelines running agents, and x402 / on-chain payment agents. Anywhere an AI is calling tools on your infra.
Built in Rust. Deploys via Docker. Self-hosted, no data leaves your environment.
Why I built it
I'm an identity and authentication engineer by background, years on Rules engine and Keycloak, eID, OIDC. Identity tells you who the agent is. It doesn't tell you what the agent is about to do.
Every "AI did something destructive" story follows the same pattern: agent has legitimate credentials, calls a legitimate tool, runs a destructive command. Nothing in the stack is watching what the call actually does. Auth checked who. Authorization checked what they could access. Neither answered "is this specific call about to wipe production, drain a wallet, or leak the customer table?"
PocketOS this weekend was the latest coding-agent version, 9 seconds, full database and backups gone. But the same gap exists in MCP servers (poisoned tool calls), A2A chains (delegation laundering destructive intent through trusted agents), and x402 payment flows (agent authorizes a payment it shouldn't). Different surfaces, same missing layer.
Where I'm at
Self-hosted core is shipping. clampd-guard for Cursor and Claude Code is live. 9-stage pipeline covering scope enforcement, content scanning, behavioral anomaly detection, and kill switch. A2A delegation chain governance with Ed25519 scope tokens. Solo founder, Tallinn, building alongside a day job for now.
What I'd love from IH
If you're running agents in production, coding, MCP, A2A, payment, anywhere, hit me up, would love to pressure-test against your stack. Honest feedback on support@clampd.dev. If you've had an "agent did something stupid" story, I want to hear it, I collect these.
Reproducing the PocketOS scenario as a demo video this week. Will post here when it's up.
-
1Your distinction between identity and action is important. I'd add a third dimension: **identity → proposed action → authority at consequence** A runtime firewall can correctly establish: * this is Agent A; * Agent A is using legitimate credentials; * this proposed tool call is not destructive under the state Clampd observes. But consider: T0 — Clampd inspects the exact call and allows it T1 — the call leaves the enforcement boundary T2 — underlying authority or resource state changes T3 — the tool/resource receives the previously allowed call T4 — consequential side effect occurs Nothing about the identity or original call necessarily changed. What changed was whether that action was still authorised when it mattered. That's a boundary I've been exploring with OpsWatch. It makes me wonder whether the strongest architecture isn't simply: **inspect → allow → execute** but: **inspect → issue narrowly bound authority → revalidate at the resource → execute → return evidence** Then the firewall's ALLOW decision doesn't have to carry authority indefinitely across the execution gap. Given your identity/auth background, I'd be particularly interested in your view: should the final resource be required to verify a short-lived action-specific authority artifact, rather than trusting the upstream firewall decision?15 days ago Reply
