An honest comparison: Cisco’s DefenseClaw and Doberman

As I have been saying in my previous few posts, “AI security” mostly meant filtering what a model says. That has changed. The agents people run now write to disk, execute shell commands, call MCP servers, and reach the network on their own. The risky moment isn’t just the model’s text ouput anymore, it’s the tool call. A prompt injection buried in a web page or a file only matters if the agent can act on it.

That’s the surface a runtime security layer has to cover, and I'm glad people are starting to be aware of this and developing solutions. In the last few months a serious one shipped from Cisco: DefenseClaw. The tool that I’m building, Doberman, is operating with the same concepy so I’ve read their code closely. Here’s an honest comparison of where each of us is strong and where each has gaps, mine included. (Everything here is from their public epository as of August 1st 2026 since fast-moving projects change, some of this may already be different.)

What DefenseClaw does well DefenseClaw is a local gateway that sits between coding agents and their tools and turns actions into allow / alert / confirm / block decisions. A few things stand out:

• Breadth. It connects to a lot of agents, Claude Code, Cursor, Codex CLI, Amp, OpenClaw, plus a proxy for the major model APIs, and it treats MCP as first-class. If you run a mixed shop, that reach matters.

• Shipped detection, not slideware. It ships real LLM judges for prompt injection, PII, tool-injection and

• Exfiltration, and a session correlator that escalates when weak signals stack up. Plenty of projects promise this but DefenseClaw actually shipped it.

• It’s honest about its limits. Their docs frame detection as best-effort rather than airtight, which, in my opinion, is the correct thing to say but we rarely see it in this market where everyone exaggerates everything.

• It’s real, on-path enforcement, verdicts are returned to the agent, and you can read production-incident notes right in the code. They move fast, in the open, with dozens of contributors and releases most weeks. That’s Cisco putting muscle behind an open-core project, and the space is better for it.

Where Doberman is different

I am making a narrower bet, especially since I can’t compete with the resources of a giant like Cisco. It’s an authorization layer, not a governance shell, and the whole design leans on a few invariants:

• Fail closed by default. Any error, any case it doesn’t understand, the answer is block or auth. DefenseClaw can do this too, but it’s opt-in; the default leans toward staying out of your way. That’s a genuine philosophy difference, observability-first versus deny-first, but each choice has a cost.

• Raise-only. Learning and guardrails can tighten a decision but can never quietly loosen one. A detector that fails adds nothing and can’t open a hole, so I can adopt aggressive detection without it becoming a liability.

• Step-up authentication bound to the action. When something is risky enough to ask about, Doberman can require a TOTP 2FA code tied to that single action, with the approval expiring on a deadline that itself fails closed. DefenseClaw’s human-in-the-loop, as far as I can see, is a notifier, confirm or deny, without that second factor. If an attacker is in your system it is easy for them to simply bypass this without the 2FA protection

• Keyed fingerprints. Redacted secrets are stored as keyed HMACs, not truncated hashes, so a low-entropy secret can’t be brute-forced back out of the logs.

None of that makes Doberman “better.” It makes it a different tool: less surface, harder core.

Honestly DefenseClaw has much more breadth than me: with more supported connectors, shipped ML detection and correlation, MCP and plugin admission scanning, and audit export to OTel and Splunk. Doberman has a smaller detection story right now, some of it deliberately shadow-mode, some still on the roadmap, only a single-vendor set of hooks, and export is still catching up. But I’m a single person running this project with a small community; they’re Cisco.

Where I think Doberman is ahead: the authorization substrate, fail-closed by default, raise-only, action-bound step-up auth, keyed redaction, and a drift defense that gates any weakening of policy behind a second factor and an append-only ledger. If your worry is “the agent must never reach a tool around the guard, and no one should be able to quietly weaken the guard,” that’s the part I’ve spent the most time on. My focus is not only preventing agent misbehavior due to hallucination but also from external attacks.

I’m glad Defensclaw exists. I can’t out-breadth Cisco, and I won’t pretend the overlap doesn’t make things harder for a small project. But more people building runtime security for agents is exactly what this problem needed. For a couple of years the whole conversation was about model outputs while the real risk moved to what agents do, and too few tools followed it there. DefenseClaw is one that did, and did it seriously. If you’re looking to secure your Agents, check out both.

If you find a place where I’ve been unfair to their work , I’d rather correct it than have a biased win.