What we stop, and what we do not.
Security products tend to describe their coverage and stay quiet about their edges. We publish both, because a control whose limits you do not know is a control you will misplace your trust in. If you only read one line: we govern what your agents ask us about. We do not govern the machine they run on.
The honest summary
Hidden instructions, data-exfiltration text, and obfuscated intent in tool metadata are caught deterministically, at scan time and again at call time.
Cloud metadata URLs, credential file paths, shell injection, unsafe deserialization, and remote-code loader flags in the actual call arguments. This is the common real attack: the tool is fine, the value the model chose is not.
Runtime hash pinning catches a rug-pull at call time, not just on a scheduled rescan.
Churn, novelty, and breadth are correlated and reported. They never block. Six ordinary production patterns, including CI matrix builds and multi-tenant SaaS, are behaviourally identical to a malicious swarm, so enforcing here would fail across your whole fleet at once instead of one call at a time.
A session that ingested untrusted input, touched sensitive data, then went silent without reaching a decision is surfaced for review. We can show you the gap. We cannot close it.
An attacker with a foothold in the agent host can skip our SDK, patch it out, or run a parallel process with the same key. Our guarantee there is tamper-evidence, that the signed ledger shows the gap, not tamper-prevention.
A vulnerable dataset loader, an exposed internal service, a misconfigured cluster. If it does not pass through us, we never see it.
A worked example: the Hugging Face breach
In July 2026 an autonomous agent system breached Hugging Face. A remote-code dataset loader and a template injection in a dataset config produced code execution on a processing worker; from there the intruder escalated to node level, harvested cloud and cluster credentials, and moved laterally across internal clusters over a weekend. Hugging Face recorded more than 17,000 attacker actions across a swarm of short-lived sandboxes.
We would not have stopped it. Not one step of that chain was a governed tool call. We say so plainly because the alternative, letting you assume otherwise, is how security products get bought and then fail to matter.
What is true and checkable: we flag the loader flag that started it. A call argument setting trust_remote_code, allow_pickle, or an unsafe deserializer routes to human approval. Had that ingestion run through an agent we govern, a person would have been asked first.
The part worth dwelling on is the aftermath. Hugging Face could not attribute its own breach and had to wait for OpenAI to volunteer that its models were responsible. That is the gap signed receipts close: attribution that does not depend on the other party choosing to speak.
Things we deliberately do not do
- We never auto-block a whole account on behavioural signals. The blast radius of a wrong call at that scope is your entire fleet, and an attacker could trigger it deliberately with a couple of hundred deliberately loud calls. Full quarantine stays a lever a human pulls.
- We never return a fake verdict. No allow-then-block-downstream. In a product whose value is that the record says what happened, a deliberately false receipt would be disqualifying.
- We do not pool behaviour across customers. Baselines are per-account and self-referential. Cross-tenant modelling would make your traffic someone else's training data.
- We do not explain a block to the agent. An authorization API that returns which rule tripped and what the score was is an oracle an attacker binary-searches. Full reasoning goes to your receipt, your log, and your webhook.
- We do not claim compliance with frameworks that have no compliance regime. Aligned with, never compliant with.
What our accuracy number covers
Our published benchmark measures per-call and per-session decisions on a public corpus. It does not extend to cross-session correlation, which ships in monitor-only mode and is not covered by that figure. When a model-backed check is refused or fails, the result is recorded as indeterminate rather than counted as a clean pass, so an unanswered check never masquerades as a finding of safety.
We do not claim to be first or only at cross-session correlation. Other vendors ship parts of it. What we do differently is deliver enforcement in your own process, with every decision reachable deterministically without a model call, and produce an Ed25519 receipt a third party with no Queldrex account can verify offline.
This page describes technical behaviour and is not legal advice or a guarantee. It is versioned with the rulebook and updated when the rulebook changes. If you find a claim on this page that is wrong, tell us at hello@queldrex.com and we will correct it here.
Read the Trust Receipt spec →