The five gates every write passes before it can poison your cache

Here's an attack most people never consider. In a multi-tenant cache, if an attacker can get a poisoned answer stored, it doesn't hit one victim, it gets served to everyone who asks a similar question. The blast radius is the whole user base. A cache that reuses answers has to treat every write as a potential attack.

In plain words. Before any answer becomes reusable, Crowkis scores it through five independent checks. If the composite score is too low, the write is refused and logged, it never gets a chance to be served.

flowchart TD
  W["candidate write"] --> S1["coherence"]
  S1 --> S2["content policy"]
  S2 --> S3["source trust"]
  S3 --> S4["tenant isolation"]
  S4 --> S5["neighbourhood check"]
  S5 --> G{"trusted enough?"}
  G -- yes --> OK["eligible to serve"]
  G -- no --> NO["refused + ledgered"]
  style OK fill:#fbe9e8,stroke:#d62221,stroke-width:2.5px
  style NO fill:#f3eee5

Figure 1. the write-trust pipeline Coherence, content, source trust, isolation, and a neighbourhood outlier check, every write earns its place.

The point isn't any single gate; it's that they're independent. An attacker might fool one, but slipping a poisoned, incoherent, low-trust, out-of-distribution answer past all five at once is a genuinely hard problem, and every failed attempt leaves a trail in the ledger.

The bottom line

A shared cache is a shared attack surface. Score every write like it might be hostile, and cache poisoning stops being a headline waiting to happen.

#The bottom line

Keep reading

Prompt-injection and jailbreak detection at the cache layer

Anti-poisoning write pipeline: how it works and when to use it

PII and GDPR in your LLM cache

The bottom line