A prompt-injection
immune system
for the DataHub metadata graph.

The attack corpus is labeled, seeded demo input — that part is honest and explicit. What isn't contrived is the victim: a stock LangChain agent built with the unmodified build_langchain_tools(client) pattern that DataHub's own Agent Context Kit ships as its reference LangChain integration, hijacked live before the cure. And the 3 held-out injections come from public prompt-injection corpora that the rule was never tuned on.

Then nothing breaks. verify.py separates the two claims: Part A is an LLM-independent graph-state gate (reset → scan → cure → assert the payload and any base64/hex encoding of it is gone from every readable surface) — deterministic, no LLM in the path. Part B, the hijack demo, is reported but never gates. No model choice can break the proof.

A classifier can't be audited by a judge in five minutes and can't run in CI with zero dependencies. The scored rule is stdlib-only, deterministic, explainable per-hit, and measured: a 0.063% flag rate over 38,031 public catalog descriptions it did not write, all 24 flags adjudicated false positives — while still generalizing 3/3 to held-out public payloads. It also clears an 18-item near-miss gauntlet built from the detector's own vocabulary, but that gauntlet is an adversarial probe we wrote, not a false-positive rate; the 38k corpus is the number an adopter can budget against.

First, how often: 24 flags in 38,031 public catalog descriptions we did not write — a 0.063% rate, and all 24 were false positives. But the rate tracks length — 0.003% under 200 characters, 4.663% over 2,000 — so the descriptions most likely to trip it are the long hand-curated ones you'd least like to lose. That is the case for the gates, not against them.

Then, what it costs. On the seeded demo corpus every hit is fixture-backed, so the cure excises exactly the injected span and leaves the rest intact. On your catalog there are no fixtures, so the default is the lossy one: the flagged field is replaced wholesale with [field quarantined by Antigen pending human review] plus an inert banner pointing at the forensic incident. Opt into --excise-span and the cure cuts the enclosing sentence instead of the raw match — it over-removes on purpose, because detect returns the earliest rule match rather than the payload, so a literal span cut would leave the second clause of a two-clause payload sitting in the field. It still falls back to whole-field quarantine whenever the survivor trips the detector, because Antigen must never write text its own detector would flag. Either way: fail-safe, not guaranteed lossless.

Nothing is deleted and no entity is removed — the pre-cure text stays in DataHub's native aspect version history, so every affected field is recoverable by reading the prior version back and re-emitting it — recoverable, not a one-click undo. It is also exactly why cure is dry-run by default on any live target, why --apply is a separate decision, why --max-mutations N refuses the N+1st write instead of executing it, and why you are meant to read the plan — produced by the real engine, not a mock — before you approve it.

Yes — the live path runs against a real DataHub instance (datahub docker quickstart, GMS v1.7.0) with mutation and document tools enabled. seed_catalog.py builds a 13-dataset ecommerce catalog with real lineage, seed_corpus.py poisons it, and the sweep reads 15 entities + 2 KB documents. (That entity count is not stable and isn't meant to be — it is whatever search had indexed at that moment; live runs recorded 15, 17 and 78, and the offline corpus in the terminal above is 44. The loci count is the stable one.) Run seed_catalog.py --scale 60 and the same sweep reads 78 entities across two search pages (offset=0, then offset=50) and flags the same 15 loci. Every SDK call of that run — 1,547 records, 250 of them Agent Context Kit tool calls, 0 failed — is checked in at docs/live-tool-transcript.json. Offline, the same engine runs against an in-memory transport double: the detector and the surface-completeness assertions are the real ones, so every number reproduces on any laptop in seconds.

The rule is open (Apache-2.0) on purpose — this is a defense-in-depth control, not a secret. Evasion pressure is exactly why the zero-width Cf-strip pre-pass exists, why the cure also checks base64/hex re-encodings of removed payloads, and why antigen rescan re-hashes certified entities so any later edit is re-flagged. A standing control that raises the cost of attack beats no control at all — the current state of every shipped catalog-agent stack.

But yes — and we know of one that is cheap. See the next answer; we would rather you heard it from us.

A clean scan is not proof of a clean catalog. Antigen reads dataset descriptions through get_entities, which HTML-sanitises and truncates every description at 1,000 characters (DESCRIPTION_LENGTH_HARD_LIMIT). The search tool returns the same text untruncated. So a payload placed past character ~997 of a dataset description reaches an agent and never reaches the detector.

The attacker picks the length, which is what makes it a bypass rather than a quirk of long fields. On our own shipped attack corpus: all 12 of 12 payloads flag on raw text, but prefixing 1,050 characters of ordinary warehouse boilerplate takes the entity-description payloads to 0 of 8. The same read path strips HTML, so a payload inside a <p title="…"> attribute or an HTML comment scores 3–4 raw and 0 through get_entities.

Scope it honestly — this is one locus, not the whole product. Only the dataset/entity-description locus is affected. Curated column descriptions (read from editableSchemaMetadata via the base SDK) and KB documents (read via grep_documents) are not truncated. Two further limits, in our favour and stated anyway: a tag with over 100 characters between < and > is not stripped and still flags, and a base64 data-URI is not a sanitisation bypass at all — the detector scores it 0 either way, because it does not decode base64.

And it is self-inflicted, not an SDK limitation. SdkGateway._paged_urns already calls search, gets the untruncated description back, keeps only the URNs and discards the text — then get_entities re-reads it and truncates. We had the full text on call one. The fix is ours and small: read dataset descriptions from datasetProperties / editableDatasetProperties, the technique _merge_editable_columns already uses for columns. It is not shipped — the code is frozen for this evidence pass, and that read path underpins every detection figure published here.

Until then: the column and KB-document paths are unaffected, search-based enumeration returns full text, and a payload long enough to exploit this makes the description conspicuously long — length is itself a review signal. Measured, with the reproduction, in docs/false-positive-revert.md and docs/THREAT-MODEL.md.