system: OPERATIONAL
← back to all hacks
DEFENSE LOW NEW

Sharing prompt-injection intel across LLM services without sharing prompts

A SaTML 2026 paper from Microsoft turns detected injection prompts into privacy-preserving binary fingerprints, so one service can warn another about an attack without exposing raw user text.

2026-07-02 // 6 min affects: hosted-llm-services, llm-api-gateways, rag-pipelines

What is this?

BinaryShield is a defensive technique for sharing prompt-injection threat intelligence between LLM services without sharing the underlying user prompts. It was published by Waris Gill, Natalie Isak and Matthew Dressman of Microsoft as “Cross-Service Threat Intelligence in LLM Services using Privacy-Preserving Fingerprints” (arXiv 2509.05608) and accepted to IEEE SaTML 2026, held March 23–25, 2026 at TU Munich.

The problem it targets is operational, not exotic. A large provider runs many separate LLM services — chat, coding, search, internal copilots — often under different tenants and different regulatory regimes. When one service detects a prompt-injection attempt, the natural move is to warn the others so the same payload does not slip through elsewhere. But the evidence is the user’s prompt, and privacy rules (and plain good practice) forbid copying raw prompts across those compliance boundaries. So each service defends alone, and an attack blocked in one place can keep working in another for weeks. This sits directly on top of the point the OWASP GenAI Security Project restated on June 11, 2026: prompt injection is a structural weakness, not a bug awaiting a patch, so containment and detection matter more than a hoped-for fix.

How it works

BinaryShield converts a flagged prompt into a compact fingerprint that preserves enough of the attack’s shape to match near-duplicates, while stripping the parts that would leak a person’s data. The authors describe a four-stage pipeline:

  1. PII redaction removes names, emails, secrets and other identifiers before anything else touches the text.
  2. Semantic embedding (using ModernBERT) maps the redacted prompt into a vector, so that reworded variants of the same attack land near each other rather than being treated as unrelated strings.
  3. Sign-based binary quantization collapses that vector to a short binary code — each dimension becomes a single bit — which is cheap to store and fast to compare with a Hamming distance.
  4. Randomized response flips bits with a controlled probability to provide local differential privacy, so a shared fingerprint carries a formal privacy guarantee rather than an informal promise.

The result is a bit-string that another service can match against its own traffic. Two services can compare notes on “have you seen this attack?” without either one revealing what its users typed. No prompt text, redacted or otherwise, crosses the boundary — only the noised binary code does.

The authors report that BinaryShield reaches an F1 of 0.94 at recognizing related injection prompts, against 0.77 for a SimHash baseline (the standard privacy-preserving locality-sensitive hash), while using about 64× less storage and running similarity search roughly 38× faster than dense embeddings. The trade-off is the usual one for differential privacy: more added noise means stronger privacy but weaker matching, and the paper tunes that balance rather than eliminating it.

Why it matters

Most published defenses try to stop an injection at a single service boundary — input filters, detectors, provenance tracking. Those help, but attackers reuse payloads, and the IPI Arena competition showed no frontier model is immune to indirect injection in the first place, while detectors are themselves evadable. If a payload is going to get past some service some of the time, the practical question becomes how quickly the rest of your fleet learns about it. BinaryShield is one of the few concrete answers to the coordination half of the problem: it lets a detection in one place raise the cost of reuse everywhere, which is exactly the kind of fleet-wide signal that in-the-wild indirect injection makes valuable.

It is worth being precise about scope. This is threat-intelligence sharing, not a detector — something still has to flag the prompt first, and a fingerprint only matches attacks similar to ones already seen, so it does nothing against a genuinely novel payload. It is a way to make each detection go further, not a replacement for detection.

Defenses

For teams operating more than one LLM service, the actionable takeaways:

  1. Treat detected injections as shareable signal. When one service flags an attack, the others should be able to act on it. Design for that fan-out instead of leaving each service to relearn the same payloads.
  2. Share fingerprints, not prompts. A redacted-then-quantized-then-noised representation lets you exchange “seen this attack” signals across tenants and jurisdictions without moving raw user text — the property that makes cross-boundary sharing defensible.
  3. Set the privacy/utility knob deliberately. Local differential privacy has a tunable budget; pick it with your compliance and security teams together, and measure the recall you give up, rather than accepting a default.
  4. Keep it as a layer, not the wall. Pair fingerprint-based intel with per-service input handling, least-privilege tool scopes, and containment of the lethal trifecta. Cross-service intel shortens the window of a known attack; it does not catch an unknown one.
  5. Log for reuse. Even inside one organization, an internal fingerprint store of past injections gives later services a head start — the same pre-output detection work benefits from knowing which payloads have already been seen.

Status

ItemReferenceDateNotes
PaperCross-Service Threat Intelligence in LLM Services using Privacy-Preserving Fingerprints (arXiv 2509.05608)2025 preprintWaris Gill, Natalie Isak, Matthew Dressman (Microsoft)
VenueIEEE SaTML 20262026-03-23 → 03-25Accepted paper; TU Munich
Reported resultsF1 0.94 vs SimHash 0.77~64× storage reduction, ~38× faster similarity search vs dense embeddings
ContextOWASP State of Agentic AI Security 2.012026-06-11Prompt injection treated as structural, not patchable

The honest framing: BinaryShield does not make an LLM harder to inject. It makes a successful detection travel — turning one service’s catch into every service’s warning, without any of them having to hand over what their users typed. In a world where prompt injection is conceded to be structural, that coordination is one of the few defensive gains still fully in the operator’s hands.

Sources