On August 1 we published a thesis: governance is not what you did, it’s what you can prove — a dated, clause-anchored, owner-named, independently verifiable artifact chain. The same day, we approved a small experiment to pressure-test one line of it: a runtime guardrail generates evidence; it is not, by itself, governance. Easy to assert on a slide. So we ran it in the real world.
The setup was deliberately modest and pre-registered — the trial and its analysis were scoped before anything happened, so the result would test a hypothesis rather than rationalize one. We installed a runtime agent guardrail — Cisco DefenseClaw 0.8.10 (released July 30, 2026) — in observe mode (watch and log, never block) beside a Claude Code workflow, in a throwaway sandbox folder in our own app-development environment. The question: what does a runtime evidence layer actually produce, and how far is that from what a board, an auditor, or an underwriter asks for?
What observe mode showed — exactly the point we expected
Within the first day, the guardrail was productive. A static scan flagged 524 findings on installed tooling. A baseline test fired a CRITICAL alert on the most dangerous shell shape there is — a recursive force-delete of the root path.
Except it wasn’t. The command was echo "rm -rf /" — text printed to a terminal, nothing deleted. The rule had matched the literal string; it even captured our own inline comment saying nothing is deleted. And it was systemic, not a fluke: every time we merely wrote about a dangerous pattern — in a memo, a finding title, a document like this one — the same rule re-fired at CRITICAL. Documenting a dangerous pattern produced the identical alert as executing it.
This is not a defect. It is what a high-recall, context-blind evidence layer is: it scores severity by the worst-case potential of a matched pattern, not by intent, execution, or realized risk. It cannot know whether the pattern was run, quoted, escaped, or written about. And that is precisely the thesis, made concrete: a runtime guardrail supplies raw signal. Turning that signal into evidence requires a human to triage it and a program to map it to an owner, a control, a regulatory clause, and a review cadence. The tool generates the finding; governance decides what it means. A raw severity total, trusted as-is, would have you blocking the writing of this sentence.
That alone would have been a clean, if quiet, confirmation. Then the experiment stopped being quiet.
What actually happened — the tool became the incident
An observe-mode install is, by definition, not supposed to be able to block anything. Ours did.
A separate, live production Claude Code session — different work, different window — began failing every tool call with a single, uninformative line: “gateway unreachable.” The guardrail’s fail-mode had silently drifted to closed across four internal layers while still reporting mode observe. With fail-closed behavior wired into roughly forty global lifecycle hooks, any unreachable or incomplete response from the guardrail didn’t get logged and waved through — it blocked the tool call, on every session on the host. A product bought for visibility had become an availability dependency on every action.
Then the recovery path failed too. The documented off-switches — the commands to force fail-open, to disable, to uninstall — hung on a stuck internal lock. The vendor’s own remediation did not function while the product was in its failure state. A first file-level repair half-succeeded because a watchdog moved the tool’s own backup file out from under the restore mid-operation, while the audit database quietly ballooned to roughly 74 MB. Clean resolution required stopping the gateway and its watchdog and restoring configuration from known-good content by hand.
Two precision points, because they matter and they’re easy to get wrong. The guardrail caused this outage — it did not surface some pre-existing problem; the tool was the incident. And fail-closed was policy executing correctly in the wrong context — not a crash, not a bug in the usual sense. The software did what a fail-closed guardrail is supposed to do. The failure was that an observe-mode install was ever in a position to do it, silently, to unrelated work.
This is the whole argument, in one night
We set out to illustrate that observability is not governance. We could not have staged a better demonstration if we’d tried.
Telemetry is not evidence: the guardrail produced 524 findings and a CRITICAL alert on a command that deleted nothing. A runtime block is not policy: the tool enforced a decision no human had reviewed, in a context no one intended, and announced it in three words. And the deepest one — the through-line under both halves of that night, because a second, unrelated system on the same machine failed the same way at the same time, silently falling back to a backup and telling no one: systems that act silently convert a single small defect into hours of misdiagnosis; the cure is evidence — every automatic decision must pay for its autonomy in a verifiable trace.
None of this means don’t run guardrails. Runtime agent guardrails are a real and necessary category; an organization letting coding agents touch its data without one is exposed. DefenseClaw’s detection layer is deterministic, instant, and needs no model or key — genuinely useful. The finding here is narrow and specific: an observe-mode product should not be able to silently fail closed, its off-switch must work while it is failing, and it must not have to be fought to remove. Those are fail-mode-default and safety-of-operation properties — the leg of the CIA triad nobody stress-tests an observe-mode tool against — and we reported them to the vendor. We reported the fail-closed drift and the deadlocking remediation path to Cisco via GitHub’s private vulnerability reporting on August 3, 2026 (GitHub Security Advisory GHSA-94gw-wrrg-5594, in triage); response pending.
The false positive is security’s oldest wound. This one doesn’t heal with tuning.
Every SOC analyst already knows this monster. The false positive is the oldest wound in security operations — alert fatigue, the flood that cries wolf until the real wolf walks through unnoticed. The usual cure is tuning: raise the threshold, suppress the noisy rule, whitelist the known-good.
For agentic monitoring, tuning won’t reach it, because the problem isn’t a bad threshold — it’s structural. The tool cannot distinguish an action from a description of that action. And description is the medium agentic work runs in. Coding agents reason in language about dangerous operations all day: quoting them, explaining them, writing the safeguard against them. A tool that flags the presence of a pattern rather than the occurrence of an act is watching the one kind of work whose entire substance is description.
Our own exhibits show it plainly. The scan returned 524 findings (14 CRITICAL, 176 HIGH, 164 MEDIUM, 164 LOW, 6 INFO). One CRITICAL fired on the literal string echo "rm -rf /" — printed text, nothing deleted (finding 4f8eeff7…, confidence 0.898). Another CRITICAL fired on our own disclaimer comment — the line that said nothing was deleted (finding 9e8acaad…). The same top severity for doing it, for printing it, and for warning against it.
You cannot threshold your way out of a tool that can’t tell a command from a comment about the command. Read that way, 524 is not a score — it is noise volume. The number is loud precisely because the judgment that would make it mean something — which of these actually mattered — has been left out of the tool by design. That is an epistemology problem, not a tuning problem, and no slider fixes it.
Confidentiality, Integrity, Availability — and the leg nobody tests.
Most of us memorized the CIA triad as a static list: Confidentiality, Integrity, Availability. Watch it move. A security control added to protect integrity and confidentiality — a guardrail over an agent’s actions — violated the availability of the very work it was watching. The three legs are tradeoffs, not independent checkboxes; protecting one cost another. And it was an observe-mode install, the most passive setting a security tool has, that breached the leg nobody stress-tests on a watch-only product. That question isn’t on the vendor questionnaire. It should be.
The incident is clarifying because it smashed together three things people routinely conflate. Pull them apart, with the night as the worked example:
- Observability is the tool seeing — the 524 findings. It answers “what happened?”
- Enforcement is the tool acting — the block, the fail-closed. It answers “stop, or allow?”
- Governance is a human, or a governed system, deciding what it means — who owns each finding, which clause it maps to, on what review cadence. It answers “does this satisfy due care?”
The outage was all three collapsed into one: the team bought observability, the tool silently enforced, and no governance layer ever decided whether that enforcement was authorized. The muddle isn’t academic — it is how the outage happened.
Which puts a sharper edge on two words the security world uses loosely. Due Diligence is the ongoing homework — knowing your AI surface, running the assessments, maintaining the artifact chain; the investigation. Due Care is acting reasonably on what that diligence reveals; the response. And here is the claim that ties the whole night together: you cannot exercise Due Care about something you don’t understand. A board that can’t tell observability from governance cannot make a reasonable decision about either. So literacy about AI governance is not a nice-to-have layered on top of Due Care — it is a component of it. The EU AI Act’s Article 4 has said as much since it took effect on February 2, 2025: AI literacy is an obligation, not an aspiration.
That is the literacy gap Due Care now creates — being able to tell observability from governance, diligence from care, before someone asks you to prove you could. Closing that gap is the work of SanctumShield Academy.
The governance lesson is the one we published on August 1, now with a scar to prove it. A guardrail generates evidence. Governance is the chain that makes the evidence answer a question — an owner, a control, a clause, a cadence — and the human judgment that decides when an automatic decision can be trusted. Buy the tool. Then build the chain, and keep a hand on the switch.
Product facts are pinned to Cisco DefenseClaw 0.8.10 (released July 30, 2026) and reflect behavior observed in a single independent evaluation; the defects were reported to the vendor before this was published (GHSA-94gw-wrrg-5594). The technical crosswalk behind this — guardrail finding types mapped to Persuasion-Exposure Validation (PEV) controls and EU AI Act evidence obligations — is the companion to Agent Guardrails Generate Evidence. See the controls at /under-the-hood and the artifact chain at /sample-outputs.