Sigstore for AI Threats — Federated Signed-IOC Feeds
A novel prompt-injection discovered by one team at 3am should be blocked at every gateway in the world by morning — signed, verifiable, with no central authority anyone has to trust. Today raucle-detect v0.8.0 ships the layer that makes that possible.
For thirty years software supply chains lived with the same problem AI security has now: every defender re-discovered the same attacks in isolation, and there was no cryptographic way to share what they'd found. Then Sigstore happened — content-addressed, transparently logged, no API keys, no global root of trust. Anyone can publish; anyone can verify; the bar for "I trust this artifact" became a public-key pin instead of a vendor relationship.
That is the shape of the missing layer in AI security in 2026. Every prompt-injection guardrail today ships with whatever IOCs its vendor decided to bake in. There is no protocol for a SOC analyst who discovers a novel jailbreak at 03:00 to publish it as a signed, content-addressed indicator that every other deployment in the world can pull, verify, and start blocking on by breakfast. v0.8.0 is that protocol.
The shape of the primitive
Three layers, each with one job:
SignedIOC— a single Indicator of Compromise. Kind (regex,substring, orunicode_signature), pattern, severity, categories, issuer, key ID, optionalrevokesandexpires_at. The body is canonicalised to deterministic JSON, hashed with SHA-256, and Ed25519-signed. The hash is the identifier.Feed— a bundle of IOCs from one issuer, plus a Merkle root over the sorted content hashes and one manifest signature. Every IOC is also individually signed, so a partial copy of a feed remains verifiable offline.FeedStore— the consumer side. A directory of subscribed feeds. Everymerge()re-verifies the Merkle root, the manifest signature, and every individual IOC signature against a pinned pubkey. Renders the live IOC set as pattern rules that drop intoScanner(feed_store=...).
That's the whole protocol. There is no central server, no API token, no "Raucle Cloud account required". The reference implementation is MIT-licensed Python and runs against any static-file host.
Subscribe in one line
The genesis feed is live at raucle.com/feed/core.json. Signed by issuer raucle.com, key ID 8fa2ffa741ba6e3a. Pin the public key once:
From there the scanner picks it up with a single keyword:
from raucle_detect import Scanner
from raucle_detect.feed import FeedStore
scanner = Scanner(feed_store=FeedStore.open("~/.raucle/feeds"))
result = scanner.scan(untrusted_input)
# Matched rules carry source="feed:raucle.com" — full attribution
# flows into the v0.5.0 receipt and v0.4.0 audit chain.
Trust without authority
The hard problem any federated threat-intel system has to solve isn't distribution. It's who do I trust, and why? The answer in v0.8.0 is deliberately small: you pin one public key per feed. That's it.
There is no Raucle root CA. There is no list of "approved issuers". Each consumer maintains its own allowlist. Want our feed? Pin our key. Want OWASP's once they publish one? Pin theirs. Want your SOC team's internal feed? Pin its key. Multiple feeds compose: the local store accepts all of them and renders one unified ruleset.
Hostile-revocation rejection. An attacker who compromises issuer B's feed cannot retroactively delete IOCs published by issuer A. Revocations are scoped to the publishing issuer — cross-issuer revokes are silently dropped in FeedStore.all_iocs(). This is a small property with large consequences.
What's in the genesis feed
Twelve indicators across the seven evasion classes we've spent the year cataloguing. Not a comprehensive catalogue — a credible starting line that exercises every IOC kind the protocol supports:
| Kind | Class | Severity |
|---|---|---|
regex | Instruction-override family ("ignore all previous") | high |
regex | System-prompt extraction probes | high |
regex | Persona-swap jailbreaks (DAN, developer-mode) | critical |
regex | Restriction-stripping prompts | high |
unicode_signature | Zero-width / BOM / word-joiner evasion | high |
unicode_signature | Bidi-override Trojan-Source characters | high |
regex | Base64-indirection → execution | critical |
substring | ChatML <|im_start|>system token | critical |
substring | Llama-2 [INST] <<SYS>> token | high |
regex | Explicit data-exfiltration directives | critical |
regex | Tool-abuse via curl + secret variables | critical |
regex | Remote-fetch-then-execute indirection | high |
Re-signing on each update. Anyone can propose additions with a reproducible attack sample.
Run your own feed in five minutes
The single best property of this design is symmetry: the publishing path is the same code as the consuming path, just run from the other side. You don't need our infrastructure to participate. You don't need anyone's.
How this composes with the rest of the stack
The whole reason this release lands now and not earlier in the year is that the layers it depends on are already in place. Provenance receipts (v0.5.0) bind every scan to a ruleset hash; audit chains (v0.4.0) bind every ruleset hash into a tamper-evident sequence; counterfactual replay (v0.6.0) lets you re-run last week's traffic against an updated ruleset. Subscribing to a feed mutates the ruleset, and that mutation is itself attestable:
- A feed-derived match carries
source="feed:<issuer>"through to the receipt, so a downstream SOC can answer not just why was this blocked but which feed and which issuer caused the block, three days later, cryptographically. - The ruleset hash bound into every audit entry now includes the feed contribution, so historical audit chains are honest about which version of the world saw which version of the rules.
- A counterfactual replay across last week's traffic with a newly-merged feed answers a question that was unanswerable a month ago: "would yesterday's IOC have caught last month's incident?"
What this is not
Three things v0.8.0 deliberately doesn't try to be, to keep the protocol honest:
- Not a central reputation system. There is no "is this issuer trustworthy" lookup. The protocol cannot decide that for you. Pin keys you have a reason to trust.
- Not a substitute for the semantic layer. Signed regexes catch what regexes catch. Novel attacks that don't match any prior pattern still need the heuristic and ML layers. The feed is fast wide distribution of known badness — a complement, not a replacement.
- Not a transparency log yet. Sigstore's killer property — a public, append-only Rekor log — is the natural next step but isn't in v0.8.0. Today the feed lives at a URL and is verifiable offline; tomorrow it can be anchored into a transparency log so silent withdrawals become detectable.
The arc, restated
Every release this year has been a piece of one architectural argument: trust in AI infrastructure must be cryptographic, not promised. Provenance gave us per-step attestation. Audit gave us tamper-evident history. Counterfactual replay gave us verifiable hindsight. Multimodal gave us coverage across the input surface. Today's release adds the social layer — the part where defenders' work compounds instead of being re-done in isolation.
The protocols of verifiable AI are getting built one primitive at a time. The next one is bigger.
Discussion: Hacker News · Lobste.rs · /r/MachineLearning · GitHub Issues
Raucle is an open-source AI security project. The runtime detection engine, the provenance receipt format, the input store, the multimodal scanner, the federated feed protocol, and all reference implementations are MIT-licensed.