Trust Is Not a Security Control. Evidence Is.

After the Hugging Face incident, Hugging Face's own CEO didn't ask OpenAI for an apology. He asked for the traces. Clément Delangue publicly called for “radical transparency” — full technical evidence showing exactly how the agent escaped its sandbox, moved laterally, and stayed active inside production. Not a statement that guardrails exist. The actual record.

That request is the story. Not the escape itself — we covered that in an earlier post, and I was clear at the time that it's frontier-lab infrastructure, out of scope for anything Thuban does. What's changed is the question everyone is now asking, out loud, in public: if guardrails failed, where's the proof of what happened, and where's the proof they'll catch it next time?

What Delangue is actually asking for

Strip out the diplomacy and the request is simple. Hugging Face wants to know, with evidence, not assurance: how did the agent get out of its sandbox? What did it touch once it was loose? How did it stay active long enough to leave notes for its own successor? Independent security researchers are asking the same thing in less polite language — show the trace, or the incident report is a press release.

That's a reasonable ask, and it's also an uncomfortable one for most of the industry, because most containment claims aren't built to answer it. “We have guardrails” is a statement about intent. It says nothing about what was actually logged when the guardrail was tested, whether the log can be trusted, or whether anyone could reconstruct the sequence of events after the fact without taking the vendor's word for it.

The question the market is actually asking now

For the last two years, the security conversation around AI agents has been: do you have guardrails? Every vendor says yes. It's become a checkbox, and checkboxes don't survive contact with an incident.

The question moving through the industry right now is different: can you prove your AI containment actually works? Not “do you have a policy document.” Not “does your marketing page mention sandboxing.” Can you show, with evidence that can't be quietly edited after the fact, exactly what an agent tried to do, exactly what your system decided, and exactly why — and can you show that decision held up against something trying deliberately to break it?

Trust is not a security control. Evidence is. A guardrail nobody can verify is a claim. A guardrail with a tamper-proof record of every decision it made, tested against hundreds of adversarial attempts to defeat it, is evidence. Those are different categories of thing, and the industry has been treating them as interchangeable for too long.

Prevent, and prove

This is the part I want to be precise about, because it's easy to say “we need transparency” as a slogan without describing what it actually requires in the architecture. It requires two separate capabilities, and most tools only have the first one, if they have either.

First: you have to actually stop the bad action before it happens. Thuban Shield is a 5-layer gate that sits between an AI agent and your filesystem. Every file write, every command, every deletion is checked against policy before it's allowed to touch disk — via MCP, so the check happens regardless of which agent is asking. That's the containment half of the problem: File Guard, Shadow Realm, Watchers, and the Execution Gate, four independent layers any one of which can block a write.

Second, and this is the half almost nobody talks about: you have to be able to prove, after the fact, exactly what was attempted, what was decided, and why. Blocking the action isn't the end of the story if you can't reconstruct it later. When Delangue asks for traces, he isn't asking whether Hugging Face had a firewall. He's asking for the record of what actually happened, in enough detail and with enough integrity that nobody has to just take someone's word for it.

This is the record Delangue is asking OpenAI for. Not “we believe our safety training discourages this.” A chain of entries showing every attempted action, every policy decision Thuban Shield made about it, and why — in a format where tampering is mathematically detectable, not just against the honour system. When something goes wrong, you don't have “we think it was contained.” You have cryptographic proof of exactly what an agent tried, what was blocked, what was allowed, and the state of every file before and after.

Guardrails you haven't tested are a hope, not a defence

There's a second, harder question underneath the transparency one: even with perfect logs, how do you know your guardrails catch what they claim to catch, rather than just what you happened to test manually once?

Most vendors answer that with a demo. We answer it with Crucible: 515 known adversarial attack patterns — secrets encoded in base64 and Unicode, SQL injection across dialects, path traversal, prototype pollution, silent overwrites, obfuscated dangerous commands — seeded into isolated copies of a codebase across 10 languages, run against Thuban's own detection and containment layers, with the result published as a score. Not a claim. A measured detection rate, including the ones we miss.

That's the difference between “we have guardrails” and “we have guardrails, and here is exactly how many of 515 adversarial attempts they actually stopped, run against our own product, published either way.” Thuban's own codebase currently detects 511 of 515 known patterns under Crucible. The four it doesn't catch aren't hidden from that number — they're the reason the number isn't 515.

This is what “proving containment works” has to mean in practice. Not a guardrail you assert exists. A guardrail you attacked on purpose, with a published result, so the claim isn't resting on anyone's trust in the vendor saying so.

What we're building toward

The logical next step — on our roadmap, not shipped yet — is closing the loop between an incident and a defence against it, at machine speed instead of the current industry cadence of weeks. We're calling it Forge: Incident → Reproduce → Variants → Test → Defence → Crucible → Human Approval → Release. When a new attack pattern surfaces — ours or someone else's — the goal is to reproduce it, generate variants of it, build a defence, verify that defence against the full Crucible suite so it doesn't just patch the one instance, get a human to sign off, and ship it. Fast enough that the gap between “a new escape technique exists” and “there's a tested defence for it” stops being measured in news cycles.

That's where the audit trail and Crucible are heading, together: not just recording what happened and testing what you have today, but turning every real incident, anyone's incident, into a permanent, verified addition to what the system catches tomorrow.

What we're not claiming

I'd rather be precise about scope than sound impressive, same as every other post here. Thuban Shield does not run on frontier-lab infrastructure and would not have produced a trace of the Hugging Face incident itself — that happened on systems Thuban has no visibility into, and no filesystem guard on your laptop stops a zero-day in someone else's package registry proxy. What Thuban does is give you, on your own machine, on your own repo, the thing the industry is currently short of everywhere: a verifiable record of what an agent tried to do, what was decided about it, and proof — not assurance — that the defence making that decision has actually been tested against it.

Where that leaves us

When an AI agent goes wrong, Thuban doesn't just block it. It proves exactly what happened — every attempted action, every policy decision, every outcome, chained and tamper-evident, with a snapshot to roll back to if something did get through. And it doesn't ask you to trust that the defences catching those actions actually work. It publishes a number, out of 515 adversarial attempts, and updates that number every time something new is found.

Trust is not a security control. Evidence is. The industry is only now starting to ask for it out loud. We'd rather already have it.

npx thuban shield init