{ "version": "0.8.0", "id": "injection-lexicon", "description": "Prompt-injection pattern lexicon: the four pattern families a detector matches against untrusted text, and the severity family each belongs to. Data only. The variant building that feeds these patterns (normalisation, homoglyph folding, rot13, unicode-tag escalation) and the buried-payload heuristic are engine behaviour and are deliberately NOT described here.", "owasp": "LLM01", "label_format": "{class}: {detail}", "pattern_id_space": { "$comment": "Stable, commons-owned identifier for each pattern. It exists because an expected.json in conformance/ has to name a finding, and the two runtimes that seed this repository do not name the same pattern the same way: llm-security calls it `override: ignore previous instructions`, the Python guard calls it `override:ignore-previous`. Without a shared key no fixture can be written at all, including for the patterns whose regex is byte-identical in both.", "field": "families[].patterns[].id", "adopted_from": "llm-ingestion-pipeline-security src/llm_ingestion_guard/injection_lexicon.json (lexicon version 1.0, repo v0.3.4, commit 0bf0729) — the `id` field of its port of the same source table. Adopted verbatim rather than invented: the guard's port already carries both names (`id` and `desc`), so the mapping is read from verified source data rather than constructed here.", "matching_method": "Each commons pattern was matched to a guard pattern by comparing this file's `label` to the guard's `desc`, with em-dash normalised to hyphen (the two differ only by that character, in the eight hitl-trap entries). 83/83 matched, one-to-one.", "stability": "An id is a stable identifier. Changing one is a BREAKING change for any consumer matching on it, and requires a major bump of this file.", "aliases": "Each pattern carries an `aliases` object naming what each seeding runtime calls it today. A runtime renames its own label by changing its alias here; the `id` does not move. The two aliases do NOT have the same evidentiary status — see alias_evidence.", "ratification": { "status": "ratified by both seeding runtimes", "date": "2026-08-09", "llm_security": "Ratified as-is, including the 0.2.0 proposal in commit 7b70f5b, by coord reply on 2026-08-09. They treat an id change as breaking on the same terms this file does.", "llm_ingestion_pipeline_security": "Ratified by coord reply on 2026-08-09. The id space was adopted verbatim from their port, so ratification confirms rather than adopts.", "$comment": "This replaces a `not_yet_confirmed` field carried through version 0.4.0, which said neither runtime had agreed. Both have. `id` is now a ratified cross-runtime contract rather than this repository's proposal, and conformance fixtures may name findings by it." }, "alias_evidence": { "llm_ingestion_guard": { "verified": true, "method": "The guard's coverage matrix asserts on this exact string: coverage.py builds one case per lexicon pattern passing `pattern.id` as the expected value, and its probe compares that against the set of `label` fields on the findings the guard actually returns. The id is therefore demonstrably what a guard finding carries." }, "llm_security": { "verified": "at table level only", "method": "Every one of the 83 alias strings was compared to the `label` field of the corresponding entry in injection-patterns.mjs at b0de0ca: 83/83 exact, in array order. So this alias is certainly the pattern's name in the source table.", "still_not_verified": "That a llm-security FINDING carries this string. The finding producer is now known - scanners/lib/output.mjs:finding(), line 32 - and it emits `title`, not `label`; there is no `label` key in the finding shape at all. Nothing connects a pattern's table label to the title a scanner passes in. The SARIF profile derives rule ids by slugging the title, so it inherits the same gap. Match on `id`, not on this alias.", "asymmetry": "This is why the two aliases are recorded separately rather than averaged: the guard's alias is verified at the level that matters (its coverage matrix asserts the finding carries that exact string), and this one is verified one level short of it." } } }, "$comment": "Extracted without behaviour change from llm-security/scanners/lib/injection-patterns.mjs. Seeded 2026-08-09 from an operator dump delivered through the local coord mailbox; re-verified the same day against the module file itself at commit b0de0ca, which corrected two transcription artefacts the dump had introduced (see source_fidelity.retracted). Only the four pattern arrays are data. checkCognitiveLoadTrap (the buried-after-2000-chars logic) and scanForInjection's variant building are ENGINE logic that never moves here; they are absent by intent, not by omission. Array order is preserved exactly as in the module.", "provenance": { "source_repo": "llm-security", "source_files": [ "scanners/lib/injection-patterns.mjs" ], "source_exports": [ "CRITICAL_PATTERNS", "HIGH_PATTERNS", "MEDIUM_PATTERNS", "HYBRID_PATTERNS" ], "source_delivery": "operator dump 2/2, coord message from llm-security, 2026-08-09; superseded by a direct read of the module at the pinned commit below", "source_commit": "b0de0ca6d86ce697f39669d177c2c2654c280128", "source_remote": "ssh://git@git.fromaitochitta.com/open/llm-security.git", "verified": "differentially, against the module file at b0de0ca - all 83 patterns compared on source, flags and label, in family and array order, 2026-08-09. See source_fidelity.", "evidence_limits": [ "Family severities are not a field in the source. Three of the four are named by the constant they live in; the hybrid family's is set by the engine at the point of match. This file records the value and where it is set, but a consumer that changes how it buckets matches can still diverge without contradicting any value here.", "Whether a consumer applies these patterns to raw or to normalised text is engine behaviour and is not fixed by this file. Two runtimes matching identical patterns against differently normalised text will still disagree on identical input." ] }, "dialect": { "name": "ecmascript", "$comment": "Patterns are ECMAScript regular-expression source text, exactly as the source literals spell it. Flags are declared per pattern in a `flags` field and never inlined as `(?i)` or `(?m)`; a pattern with no `flags` key carries no flags. All 83 patterns compile in Node with their declared flags, in Node with `u` added, and in Python `re` with the equivalent re.I / re.M.", "flags": { "i": "case-insensitive", "m": "multiline: ^ and $ match at line boundaries" }, "features_used": [ "negative lookahead: (?!...)", "lookahead assertion: (?=...)", "non-capturing groups: (?:...)", "bounded quantifiers: {n,m}", "unicode escapes: \\uXXXX" ], "translation_notes": [ "Python (`re`): compile with re.I where flags contain `i` and re.M where they contain `m`. No rewriting is needed; verified by compiling all 83.", "Nine patterns contain `\\/` - a redundant escape that a JavaScript regex LITERAL requires and that `RegExp.prototype.source` preserves. It is kept rather than normalised away because both seed runtimes accept it (Node bare, Node under `u`, and Python `re`), so removing it would break byte-identity to buy nothing. Engines that reject unknown escapes (Go `regexp`, RE2) MUST report these patterns as unsupported rather than skip them silently - a skipped pattern is an invisible false negative.", "`\\w` and `\\b` are ASCII-only in ECMAScript without `u` but Unicode-aware in Python on `str`. Input that mixes non-ASCII word characters with these patterns can therefore match differently between runtimes. This is a real portability seam. It is recorded rather than normalised, because normalising it would change behaviour in the seed runtime.", "No pattern in this file contains a non-ASCII byte. The source module's regex literals are pure ASCII throughout - invisible code points, Cyrillic look-alikes and accented Latin are all written as \\uXXXX in the literal, and this file reproduces that spelling. An earlier version of this note claimed the leetspeak and multi-language patterns embed accented Latin directly; that was wrong in both halves (the leetspeak patterns are ASCII-only, and the one accented pattern is escaped at source). See source_fidelity.retracted." ] }, "normalisations": [], "normalisations_note": "Empty by result, not by omission: all 83 patterns are byte-identical to the source module, so there is no transformation to declare. Through version 0.3.0 this array held one entry; it was retracted as false in 0.4.0. See source_fidelity.", "source_fidelity": { "$comment": "This file applies NO transformation to the pattern text. All 83 patterns are byte-identical to the RegExp literal source in llm-security/scanners/lib/injection-patterns.mjs - but READ THE COORDINATE BELOW, because it moved in version 0.7.0. Through 0.6.0 the coordinate was the original extraction commit b0de0ca. In 0.7.0 one pattern (hybrid-xss:script-tag) was RE-EXTRACTED at b1ba1fb, so the coordinate for a 83/83 claim is now b1ba1fb and the count against b0de0ca is 82/83. The `normalisations` array is empty because there is nothing to declare, not because the question was skipped.", "patterns_total": 83, "patterns_byte_identical_to_source": 83, "byte_identical_against_commit": "b1ba1fb", "byte_identical_against_commit_date": "2026-08-11", "byte_identical_against_commit_$comment": "The missing coordinate on `patterns_byte_identical_to_source`, added in 0.7.0 when that count stopped referring to a single commit for the whole file's life. The key and its value are unchanged - 83 patterns, byte-identical - and this field states WHICH source commit they are identical TO. Against the original extraction commit b0de0ca the count is 82/83; the one difference is the re-extracted pattern recorded in post_extraction_drift.", "method": "The module was imported in Node from a read-only clone of the public remote at b0de0ca, and every entry compared in array order on three axes: RegExp.prototype.source, RegExp.prototype.flags, and label. Family membership, array order and per-family counts were compared at the same time. Nothing was read by eye. In 0.7.0 the single re-extracted pattern was verified the same way against b1ba1fb (injection-patterns.mjs:170); the other 82 were not re-imported, so their identity rests on the b0de0ca run plus the measured fact that `git diff b0de0ca..b1ba1fb -- scanners/lib/injection-patterns.mjs` changes exactly one `{ pattern, label }` line - the script-tag one - and otherwise only adds five comment lines. Exactly one commit in that range touches the file at all (90f576f).", "class_membership_verified": { "zero_width_class": [ "U+200B", "U+200C", "U+200D", "U+FEFF" ], "cyrillic_class": [ "U+0430", "U+0435", "U+043E", "U+0440", "U+0441", "U+0456", "U+0443" ], "$comment": "The classes inside `unicode:zero-width-in-word` and `homoglyph:cyrillic-latin-mix`, enumerated mechanically from the module bytes. Note that the zero-width class does NOT include U+00AD even though codepoints/carriers.json lists U+00AD as a zero-width carrier, and that the Cyrillic class is a 7-member set distinct from the 13-member CYRILLIC_CONFUSABLES list in that same file. The three sets are deliberately different in the seed implementation and are NOT reconciled here." }, "retracted": [ { "id": "unicode-escape-invisible-and-confusable", "was": "A `normalisations` entry, present through version 0.3.0, asserting that this file rewrote raw code points as \\uXXXX escapes in `homoglyph:cyrillic-latin-mix` and `unicode:zero-width-in-word`, and carrying byte_identical_to_source: false.", "why_retracted": "False against the module. The source literals already write those code points as \\uXXXX; nothing was ever rewritten, and both patterns are byte-identical to source. The stored pattern text was correct all along - only the account of where it came from was wrong.", "cause": "The seed dump rendered the module's escape sequences as the literal code points they denote. Reading that as the source spelling, this repository re-escaped them and arrived at the correct bytes by way of an incorrect story. This is transcription drift, and it is why the file is now verified against the module rather than against a dump.", "evidence_status": "The differential result recorded for the retracted claim - Node over 173 adversarial inputs in bare and `u` mode (692 comparisons) and Python `re` over 118 inputs (236 comparisons), zero differences - stands as a true statement about raw-versus-escaped equivalence. It is simply no longer load-bearing here, because no such transformation is applied." }, { "id": "french-escape-inverted", "was": "`multi-lang:french` carried the character class spelled with raw accented Latin: pr[eé]c[eé]dentes?.", "why_retracted": "The same transcription inversion in the opposite direction. The module writes pr[e\\u00e9]c[e\\u00e9]dentes? with escapes; this was the only one of the 83 patterns not byte-identical to source. Corrected in 0.4.0 to the module's spelling, which makes the count 83/83.", "behaviour_impact": "None. The two spellings are the same regular expression. Verified by compiling both forms and comparing match presence and offsets in Node (bare and `u` mode) and in Python `re` over accented, unaccented, uppercase and non-matching French inputs - identical results throughout." } ], "post_extraction_drift": { "$comment": "The record of source drift AFTER the original extraction, and of how it was closed. Through 0.6.0 this block described an OPEN divergence: llm-security had moved one pattern and commons had not followed. In 0.7.0 that one pattern was re-extracted and the divergence is closed. The block is kept rather than deleted because a consumer diffing this file against b0de0ca still needs the coordinate that explains the one mismatch it will find.", "status": "resolved in 0.7.0 by re-extraction", "extracted_from_commit": "b0de0ca", "extracted_from_commit_date": "2026-08-09", "count_at_extraction": 83, "drift": [ { "pattern_id": "hybrid-xss:script-tag", "source_commit": "90f576f", "source_commit_date": "2026-08-10", "change": "llm-security dropped the closing-tag requirement: ]*>[\\s\\S]*?<\\/script> became ]*>, closing a recall hole where `