injection-guard

name	injection-guard
version	0.13.0
implements_spec	0.6.0
description	Generate or audit a prompt-injection defense that satisfies AgenticApps core spec §14 for the project's tech stack. Three subcommands: `init` (greenfield scaffold — detect stacks, materialise the trust-classification enforcement (TS ESLint rule / Go analyzer), the `fenceUntrusted` + canary helpers, the untrusted-input registry, and the attack-matrix regression test behind consent gates, then write the `injection_guard:` metadata block), `scan` (brownfield audit → .injection-scan-report.md; finds tenant-untrusted values reaching prompts without a trust marker, ranked by confidence), and `scan-apply` (apply high-confidence findings — add markers, scaffold missing enforcement assets — with per-file consent). Use when adding or auditing an LLM prompt-building path, tenant-untrusted tagging, prompt fencing, output validation / canary checks, tool-dispatch allowlists, or a §14 prompt-injection regression test in a new or existing service. The shared attack-family corpus and per-stack templates live in ./corpus, ./templates, and the per-subcommand procedure in ./init, ./scan, ./scan-apply. Host-neutral — /injection-guard on Claude, $injection-guard on Codex.

injection-guard — AgenticApps prompt-injection scaffolder + auditor

This skill implements the generator obligation in core spec §14 (the static-enforcement, registry, fencing, output-validation, and dynamic-test machinery of §14.2–§14.7) for AgenticApps projects that build LLM prompts from non-self-authored values (callbot, cparx, fx-signal-agent, and future LLM-bearing projects). It is a host-neutral skill: when invoked, you (the agent) follow the procedure prompts below using the Read, Grep, Write, and Edit tools.

It is the prompt-injection sibling of the observability skill in this repo: same install surface (install.sh / install-codex.sh), same migration chain, same consent-gated init / scan / scan-apply shape. §14 was generalized from fx-signal-agent's REQ-SEC03 / D-05 / D-06 the way §10 was generalized from the observability wrapper (see ADR-0016 in agenticapps-workflow-core).

Architecture-first (read before scaffolding)

Per spec §14, detection is the weakest layer. This skill does NOT scaffold a heuristic "does this input look malicious" classifier as a primary control. The load-bearing assets it generates are, in priority order:

1. Trust separation (§14.1, §14.4) — call-site classification + fenceUntrusted.
2. Output validation + canary (§14.5).
3. Least privilege (§14.6) — allowlist + confirmation, where tools are dispatched.

Static enforcement (§14.2) and the dynamic attack-matrix test (§14.7) exist to keep those guarantees from eroding; they are not themselves the guarantees.

Dispatch

The skill takes one positional argument (the subcommand) and delegates to a sub-skill prompt:

Subcommand	Sub-skill prompt	Purpose
init	./init/INIT.md	Greenfield scaffold of all §14 enforcement assets per stack, behind consent gates.
scan	./scan/SCAN.md	Walk prompt-building globs, find untrusted values reaching prompts without a marker → .injection-scan-report.md.
scan-apply	./scan-apply/APPLY.md	Apply high-confidence findings (add markers, scaffold missing assets) with per-file consent.

If the subcommand is omitted, default to scan (the safest no-op operation; produces a report without modifying anything).

Routing-table structural invariant: every Sub-skill prompt path in the table above MUST exist on disk inside this skill directory. Dispatch resolves routed paths relative to the skill root; a missing routed path means the subcommand is unrunnable. Mechanical check:

grep -oiE '\./[a-zA-Z/_-]+\.md' injection-guard/SKILL.md | sort -u | while read rel; do
  abs="injection-guard/${rel#./}"
  [ -f "$abs" ] && echo "  OK $rel" || echo "  MISSING $rel"
done

Resolution rules

Per spec §10.7.1 (reused here), all target paths in this skill are resolved against the language module root (the directory containing the stack's manifest — package.json, go.mod, …), not the project root. The init and scan procedures detect module roots from each stack's templates/<stack-id>/meta.yaml path_root. Multi-root repos (e.g. fx-signal-agent's 7 roots) are handled per root; --allow-partial lets a run scaffold the roots it can and report the rest.

The shared attack-family corpus

The attack-family corpus is defined once at ./corpus/injection-attacks.json and emitted into each host so every stack tests the same families (§14.7). Minimum families: instruction-override, role-reassign, system-prompt-probe, data-exfiltration, delimiter-structure. Hosts extend their emitted copy with real attempts seen in logs; they do not edit the canonical corpus here.

Stack templates

Each stack at ./templates/<stack-id>/ carries a meta.yaml (detection signals

• prompt-building globs + target paths + parameters). The §14 TypeScript assets are runtime-agnostic and shared once in ./templates/_ts-common/ (fence-untrusted.ts, eslint-rules/, the vitest tests); each TS stack's meta.yaml references it via shared_assets: _ts-common. Go assets are not shared (single Go stack) and live in ./templates/go-fly-http/.

Stack ID	Manifest	§14.2 binding	Assets source
ts-cloudflare-worker	package.json	ESLint rule (no-untagged-tenant-strings-in-prompts)	_ts-common (vitest)
ts-cloudflare-pages	package.json	ESLint rule	_ts-common (vitest)
ts-supabase-edge	supabase/config.toml	ESLint rule	_ts-common (+ Deno test wrapper on emit)
ts-react-vite	package.json	ESLint rule	_ts-common — but see warning below
go-fly-http	go.mod	go/analysis analyzer (untrustedprompt)	go-fly-http/ (promptguard + analyzer + cmd runner)

The TypeScript ESLint rule ships the v2 variant that also flags indirect const msgs = [...] / identifier construction (closing the documented §14.2 v1 gap), behind the checkIndirect option so v1-only repos can opt down.

ts-react-vite is special-cased. Prompt building in a browser bundle is itself a §14 finding (HIGH): a client-side prompt exposes the system prompt and canary to the user and usually ships the model API key to the browser. scan and init MUST surface the stack's applicability_warning and recommend moving prompt construction server-side; they MUST NOT report a clean §14 posture for a client-side prompt path. The primitives still scaffold (defense-in-depth), but detection ≠ approval.

Conformance with spec §14

This skill satisfies §14's generator-facing obligations:

1. Trust classification + static enforcement (§14.1–§14.2) — init scaffolds the call-site marker convention and the per-language CI enforcer; scan finds unmarked untrusted→prompt flows.
2. Untrusted-input registry (§14.3) — init emits the registry doc + its refresh command; scan reconciles it against discovered call sites.
3. Runtime trust separation (§14.4) — init emits the fenceUntrusted helper.
4. Output validation + canary (§14.5) — init emits the canary helper and the output-validation hook.
5. Least privilege (§14.6) — init emits the tool-dispatch allowlist + confirmation scaffold where the host dispatches tools; records N/A for single-shot surfaces.
6. Dynamic regression test (§14.7) — init emits the attack-matrix test seeded from ./corpus/injection-attacks.json, with model-drift pinning.
7. Consent — scan-apply shows per-file diffs and requires explicit confirmation; never auto-applies (fail-closed: a dirty/hand-modified asset is skipped and reported, never overwritten).

When to invoke

User intent	Subcommand
New LLM-bearing project; wire §14 defense from scratch	init
Existing project; audit injection surface, no changes	scan
Existing project; apply scan-found high-confidence gaps	scan-apply
Project has no LLM prompt-building path	none — declare §14 N/A per §09

The migration that propagates this skill into host repos is migrations/0023-prompt-injection-defense.md in this repo, consumed by the migrations framework (per ADR-0013).