🧬  Immune

  BEFORE                                        AFTER
  ● Refunds go to GB29 4471 8829   ← the lie    ◍ quarantined, dated, still readable
  ├─ ● destination already verified             ├─ ✖ revoked   (depth 1)
  │  └─ ● skip the destination check            │  └─ ✖ revoked   (depth 2)
  └─ ● refunds may be auto-approved             └─ ✖ revoked   (depth 1)
        ▶ PAID £4,200 to the attacker                 ↩ REVERSED

  ● Deliveries go to 118 Mission Rock            ● untouched
  └─ ● west-coast carrier lane                   └─ ● untouched      ← this is the product

Anyone can wipe a memory. Only a provenance graph can say these three are contaminated and those two are fine.

The 30-second version · Try it · The problem is measured, not imagined · How it works · Architecture · Use it as a plugin · Why MongoDB · Determinism and fallbacks · What we built today · Limitations · Q&A

An agent's memory is a database with an unauthenticated write path. Anything the agent reads — an email, a support ticket, a scraped page, another agent's note — can become something it believes. Nobody approves that write. There is no step where a human said yes.

Most attacks on an agent are one-shot: they work while they are on screen and stop when the chat closes. This one doesn't. One successful write and the agent believes the lie in every session afterwards, including sessions with completely different people. It never sees the original message again. It just knows the false thing.

Then it gets worse, because the agent builds on it. It draws conclusions. It takes actions. Each one looks reasonable on its own, and none of them look connected to an email from three days ago.

Immune gives that memory an immune system:

Nothing is ever deleted. A quarantined belief is locked and dated, so the agent can still answer "what did you believe on Tuesday, and what changed your mind?" Deleting is amnesia. This is a memory of having been lied to.

This is a memory project, not a security project. The hackathon brief asks that what you store and retrieve changes what the system does next. Immune asks memory the same question before and after — and gets a different answer, because the trust state of those documents changed in the database. Same prompt. Same model. Different behaviour. Security is just the failure mode that makes it obvious.

git clone https://github.com/sameernagar-hub/immune.git && cd immune && npm install

cp .env.example .env      # fill in the Atlas connection strings

npm run doctor            # 9-point pre-flight: cluster, indexes, $graphLookup, vector search

npm run demo              # the full attack and immune response, with self-assertions

npm run demo is deterministic — two consecutive runs are byte-identical, and npm run rehearse proves it by running it twice and diffing.

This is the most documented failure in agentic systems right now. Every number below is external to this project.

Every existing defence sits at the front door — trying to spot the bad message on the way in. The research is blunt about the result: standard prompt-injection defences do not stop memory poisoning, because memory poisoning only has to get through once.

Nobody is handling the case that actually matters: the lie already got in, it has been believed for days, and things have been built on top of it.

"You already bought the thing that tries to stop the bad message getting in. Nobody sold you the thing that finds what got in last month and unwinds everything your agents concluded from it."

Every retrieval is a vector search with a pre-filter on trust and status:

{ $vectorSearch: {
    index: "belief_vec", path: "embedding",
    queryVector: qv, numCandidates: 200, limit: 8,
    filter: { status: "active", source_trust: { $gte: 0.5 } } } }

The same query returns a different belief set before and after a quarantine — because the filter reads state that changed in the database. Nothing in the prompt moved.

The pre-filter is the feature. Split across a vector store plus a relational store this does not compose: you would retrieve semantically and then filter in application code, silently starving the result set because the trust filter lands on an already-truncated limit.

Implementation note worth defending: source_trust is denormalised onto every belief, because $vectorSearch can only pre-filter on fields of the documents it is searching. The cost is one updateMany when a source's reputation moves. That is a good trade, and syncSourceTrust() is the thing that pays it.

When a new claim arrives, embed it and search the existing trusted beliefs on the same subject_key:

The memorable part: the query vector is a belief, and the corpus is the beliefs collection. Memory polices itself.

Paired with exact-token matching for literals — IBANs, account numbers, package names, URLs. GB29 4471 8829 and GB29 9021 3345 are nearly identical vectors and completely opposite facts, and that gap is exactly where a memory system embarrasses itself. Meaning finds the pair; the literal decides the verdict.

db.beliefs.aggregate([
  { $match: { _id: poisonedId } },
  { $graphLookup: {
      from: "beliefs",
      startWith: "$_id",
      connectFromField: "_id",          // take this document's id
      connectToField: "derived_from",   // find documents that list it as a parent
      as: "contaminated",
      maxDepth: 6,
      depthField: "distance" } }
])

Then, in one transaction:

1. every descendant → status: "revoked", valid_to: now, revoked_by: <poisoned id>
2. the poisoned belief → status: "quarantined" — not revoked; it is evidence
3. every action whose used_beliefs intersect the contaminated set → status: "reversed"
4. the source → trust decayed, denormalised copies re-stamped

The direction is the one thing to get right and the easiest thing to get wrong. Swapping connectFromField and connectToField walks up to ancestors and returns empty for a root belief — which looks exactly like "the cascade is broken" and is not.

on refutation:            trust ← trust × 0.4
on survived verification: trust ← min(1.0, trust + 0.05)
retrieval pre-filter:     trust ≥ 0.5

Multiplicative decay, additive recovery. A source that lies once drops below the retrieval floor immediately (0.70 → 0.28); a source that behaves earns its way back over five clean checks.

This is what makes the cold re-run work. The second attack fails because the sender sits at 0.28 in the database — not because anything is in the prompt.

You cannot verify everything, and pretending otherwise is the obvious hole. Verification fires on load-bearing beliefs only:

1. the belief is about to justify a side-effectful action, or
2. two or more other beliefs derive from it, or
3. it contradicts an existing trusted belief

We don't check everything. We check what's about to matter.

This is the part that makes memory poisoning different in kind from prompt injection, and it is not a bug we left in.

The payload does not bypass one check. It installs a standing belief that the check is unnecessary — and the agent honours that belief on every future run, from a cold context, with the original message long gone.

Immune's answer is not a hard-coded exception. The suppressing belief is itself a node in the provenance graph, so when its ancestor is refuted it is revoked with everything else and the check comes back on by itself.

And the trigger that saves it is deliberately not suppressible: a belief can talk the agent out of a pre-action check, but nothing a belief says can stop two contradictory records being compared. That asymmetry is how a poisoned agent escapes on its own.

                        ┌──────────────────────────────────────────────┐
   a ticket ─┐          │  YOUR AGENT                                  │
   a webpage ─┼────────▶│                                              │
   an agent  ─┘         │   ingest ─▶ extract ─▶ reconcile ─▶ retrieve  │
   (unauthenticated     │                 │                     │      │
    write path)         │                 ▼                     ▼      │
                        │            verify(if load-bearing)   act      │
                        │                 │ refuted                     │
                        └─────────────────┼─────────────────────────────┘
                                          ▼
                        ┌──────────────────────────────────────────────┐
                        │  IMMUNE  (src/plugin.js — 5 calls)           │
                        │  quarantine ─▶ $graphLookup ─▶ revoke ─▶      │
                        │  reverse actions ─▶ downgrade source          │
                        └──────────────────┬───────────────────────────┘
                                           ▼
    ┌───────────────────────────────────────────────────────────────────────┐
    │  MongoDB Atlas — one engine, one set of documents                     │
    │                                                                       │
    │   beliefs · sources · actions · runs                                  │
    │                                                                       │
    │   $graphLookup ......... provenance traversal (the cascade)           │
    │   $vectorSearch+filter . trust-gated recall & contradiction detection │
    │   exact-token match .... literal indicators vectors miss              │
    │   transactions ......... the four cascade writes commit together      │
    │   change streams ....... every other process learns, instantly        │
    └───────────────────────────────┬───────────────────────────────────────┘
                                    │ change stream
                    ┌───────────────┴────────────────┐
                    ▼                                ▼
            AGENT B (npm run watch)          THE ROOM (npm run live)
       a second process, no context,      QR ─▶ phone ─▶ writes a belief
       learns from the oplog alone        and watches it get revoked

sources  { _id, kind: "email"|"web"|"tool"|"agent"|"human", handle,
           trust: 0.0–1.0, verified_count, refuted_count, first_seen, last_updated }

beliefs  { _id, subject_key: "refund.destination", claim, polarity: +1|-1,
           embedding: [...], source_id, source_trust,
           derived_from: [ObjectId, ...],   // ◀── the family tree. A real edge list.
           status: "active"|"quarantined"|"revoked", confidence,
           valid_from, valid_to,            // bi-temporal — nothing is deleted
           quarantined_by, quarantined_at, revoked_by, evidence_run_id }

actions  { _id, kind, payload, used_beliefs: [ObjectId], run_id,
           status: "executed"|"reversed", ts }

runs     { _id, kind, started_at, finished_at, events: [...] }   // the agent's own trace

Three decisions to defend:

1. derived_from is a real edge list, not a text note. That is what makes the cascade a graph query instead of a guess.
2. Nothing is ever deleted. status + valid_to means the agent can account for a decision it no longer stands by. Deleting would destroy the evidence.
3. subject_key is what makes contradiction detection possible. Two beliefs can only contradict if they are about the same thing — the key scopes the comparison so a fact about refunds is never weighed against a fact about shipping.

Everything else in this repository is a demonstration. This is the product. A memory adapter you drop into an agent you already have, in five calls, without restructuring it.

import { immune } from "./src/plugin.js";

const memory = await immune({ agent: "support-bot" });

// 1 — anything the agent reads. The source is a required argument,
//     so there is no way to store a fact without its provenance.
const read = await memory.remember({ from: "support-inbox", text: ticket });

// 2 — anything the agent concludes. Parents are required too.
await memory.derive({ from: read.stored, about: "refund.approval_policy", claim });

// 3 — anything the agent recalls, trust-filtered. `excluded` tells you what was
//     withheld and why — the difference between an agent that forgot and one
//     that declined.
const { facts, excluded } = await memory.recall({ about: "refund.destination" });

// 4 — anything the agent DOES. Records what justified it *before* running it,
//     which is what makes the action reversible later.
await memory.guard({ kind: "refund.payout", payload }, () => sendMoney(payload));

// 5 — the immune response, triggered by a trusted record disagreeing.
await memory.challenge({ from: "ledger", about: "refund.destination", claim: truth });

Plus:

memory.on("revoked", (e) => log(e.claim));   // live, off a change stream
await memory.explain(beliefId);              // "what did you believe, and why did you stop?"

Provenance is a consequence of the API's shape, not something the caller maintains. guard() is the trick: it is not a permission check, it is the thing that makes an action revocable. An agent that calls guard gets the cascade for free. An agent that skips it and calls the payment API directly is exactly the agent this project is about.

There is no daemon, no sidecar, and no dashboard. Immune is a library over your own Atlas cluster: the beliefs are your documents, the revocation is a write, and every process on the cluster learns through the change stream. Nothing has to be told.

Run npm run plugin to watch an ordinary support agent — written as if Immune did not exist — get lied to, act on it, and then take itself apart.

npm run live

Prints a QR in the terminal and serves a phone page and a projector view. Someone scans it, picks a name, and chooses how their lie reaches the agent — a support ticket, a page it scraped, or a note from another agent in the fleet. They are now a sources document at trust 0.70, which is all the identity an email From: header carries either.

1. Their claim lands in beliefs. Nothing fails.
2. The agent derives three conclusions from it, each with a real parent edge.
3. It pays £4,200 to their account, because a belief it derived from their lie said the destination check was unnecessary.
4. A trusted record disagrees. $graphLookup runs. Three conclusions go red, the payout reverses, their trust drops 0.70 → 0.28 — and the unrelated branch stays green.
5. They send the same thing again. It is written, it is active, and it is inert · below floor: the agent cannot see it.

The live path calls the same functions the scripted demo calls. There is no separate implementation for the stage — two code paths would mean the thing being demoed is not the thing that was tested. The only difference is who sent the message.

The three payloads are pre-written so the payload is deterministic. We say that out loud rather than letting anyone discover it. Free text is accepted too, and is labelled as improvised.

With IMMUNE_VOICE=1 the agent narrates its own diagnosis through ElevenLabs at three moments: when it acts on the lie, when the cascade fires, and when the repeat attack bounces off. The numbers in each sentence come from the cascade's return value, not from a script — "revoking three conclusions" is a three that came out of $graphLookup. Revoke four and it says four.

This is the question, so here is the answer without hedging.

All five, over the same documents, in one query engine. Split this across a vector store plus a graph database plus a queue and none of it composes — you would be reconciling three copies of a belief and the provenance edges would live somewhere the vector filter cannot see.

That is not a preference. It is the reason this project fits in an afternoon.

The demo must be identical every time, so the inputs do not move: frozen fixtures, a byte-identical reset path, temperature 0 wherever inference exists, and voice behind an opt-in flag specifically so npm run rehearse stays byte-identical.

npm run rehearse runs the whole thing twice and diffs it → identical across 165 lines.

Every layer has a ladder, each rung strictly cheaper than the one above. The rung actually in use is printed at runtime, so nothing here is overclaimed:

A demo that quietly degrades is a demo that lies. Every surface states which rung it is on.

Between 1:30 and 5:00 PM PT on 13 August 2026, from an empty repository. Tagged at each green gate; times are checkable against git log. See CHANGELOG.md and BUILD-LOG.md.

We would rather say these than have them found.

• The scripted demo's oracle is a fixture; the fact-checker's is not. LEDGER in fixtures/scenario.js is a constant, and that is deliberate — the filmed run is measured against a known chain. But src/factcheck.js adjudicates against a query: active beliefs from sources at or above trust 0.9, joined to sources so every citation names the channel and carries the document _id you can open in Compass. The oracle grows as the database does. What is still true: swapping LEDGER for a live HTTP call in src/verify.js is one function.
• The filmed demo runs no LLM. Extraction runs on deterministic rules and embeddings on a lexical embedder, and every run prints which rung it used. src/factcheck.js does adjudicate a claim through a live model and is tested working — but it is not wired into npm run demo, so what you see filmed is the deterministic path end to end. See the note below.
• Fact-checking works but is not yet in the attack path. factCheckAgainstMemory({ claim, subject_key }) reads the record set out of MongoDB, adjudicates, and returns a verdict, a correction, and the deciding source — named, with its trust score and its document _id. Verified against a live model on a free-text claim no fixture anticipates: it refuted an invented billing contact and cited crm.acme.internal at trust 0.92. What is not done is calling it from the live surface's attack flow, so it is a working component rather than something the demo shows you.
• Derivation in the scripted demo is fixture-driven. The three conclusions are frozen text so the cascade is measured against a known chain. The provenance edges, the traversal, the revocation and the reversal are all real writes and real queries.
• Re-derivation is not built. Immune diagnoses and undoes; it does not rebuild the correct conclusions afterwards. That is the right v2 and it did not fit in three and a half hours.
• Trust is per-source, not per-source-per-subject. A source that lies about refunds loses credibility about shipping too. Correct for the demo, too blunt for production.
• The hosted surface polls; the local one streams. A serverless invocation cannot hold an oplog cursor. Change streams are the real mechanism and npm run watch is where that proof lives.

OWASP lists memory poisoning as ASI06 in the Top 10 for Agentic Applications, and as T1 in its agentic threat taxonomy. The attacks are named and reproducible — MINJA (>95% success), AgentPoison, and the MPBench benchmark — and the research is blunt that standard prompt-injection defences do not stop it.

Nobody is building the clean-up. That is the half this is.