Capstone: The Lockdown Audit
Security is a gate problem, not a vigilance problem — every rule in this track ends as an automated check, and this capstone gives you the audit script that runs them all.
The Track in One Audit
This track opened with a map of the attack surface an agent stack exposes: five surfaces, each with its own failure mode, each covered by a lesson that teaches the rule and the defense. This capstone closes the loop: a repeatable audit that checks six surfaces — the same five surfaces, with the content pipeline split into its two distinct audit checks (topology and PII). It scores your stack against a maturity model and exits with a CI-compatible status code.
The audit exists because understanding security is not the same as implementing it, and implementing it is not the same as maintaining it. Maturity requires all three. The audit script is the maintenance mechanism — run it in CI, run it quarterly, run it after any significant infrastructure change. Security that cannot be measured cannot be maintained.
The Six Audit Surfaces
Each check in the audit maps to a lesson in this track. Five of the six are the original surfaces from the 606 map: the control channel becomes the injection check (S4), tools and integrations become the privilege check (S5), secrets stays as S1, and public endpoints stays as S6. The sixth check exists because the content pipeline surface splits into two independent audit checks — topology (S2) and PII (S3) — since they leak different data and are caught by different scanners. The summary here is intentionally brief — the detail is in the lessons.
Secrets (S1). From the secrets hygiene lesson: agents must not write secrets, .env* files must be gitignored and deny-listed, pre-commit secret scanning must block on key-shaped strings, and each agent must use a separate credential. The single hardest-won lesson from production: a leaked API key in an unattended job context silently drained a significant amount of API credits before anyone noticed. The audit check: no key-shaped strings in tracked files, .env patterns in .gitignore, secret scanning active in CI.
Topology (S2). From the infrastructure exposure lesson: real IP addresses, home directory paths, internal hostnames, and service labels must not appear in published content. The attack vector: reconnaissance — a public topology map is the first thing an attacker needs. The audit check: scan content/ and docs/ for RFC-1918 IP ranges and /home/* or /Users/* path patterns.
PII (S3). From the PII leak paths lesson: redaction completes at re-embed (not at merge), gates must propagate to forks, and PII scanners must have allowlists for intentional brand names. The audit check: verify-pii script exists at repo root or in scripts, CI references the scanner.
Injection (S4). From the prompt injection lessons: agent prompt files must define an instruction hierarchy (the system: header is the check we can automate), and tool results must be treated as untrusted data. The audit check: agent config files contain an instruction hierarchy marker.
Privilege (S5). From the least privilege lesson: explicit tool allowlists, no wildcards, separate credentials, approval gates for irreversible actions. The audit check: agent YAML configs have a non-wildcard tools list.
Public Endpoints (S6). From this lesson: CAPTCHA integration present in auth-related source, rate limiting on AI endpoints, coverage matrix known and documented. The audit check: Turnstile or CAPTCHA references in the src/, app/, pages/, or components/ directories.
The Maturity Model
The maturity model provides a language for where your stack currently sits and a clear incremental path to where it needs to be.
L0 — Default install. This is the state of a new project: shared keys, real topology in docs, no injection defense, all agents with full access, no CAPTCHA, no audit logs. L0 is not a safe operating state for anything that handles real users or real credentials. It is a starting point.
L1 — Basics applied. The minimum an individual developer should implement before going to production: .env in .gitignore, no IPs in public docs, obvious PII excluded from context, user input demarcated from instructions, read-only tokens for read-only agents, rate limits on public endpoints. L1 closes the most obvious gaps.
L2 — Gates added. This is the viable minimum for a production agent stack. Pre-commit secret scanning, CI sanitization gate, PII scanner with allowlist, instruction hierarchy in agent configs, explicit tool allowlists, CAPTCHA on auth flows. L2 means the most common attack chains are blocked by automated checks, not by hoping someone remembers.
L3 — Defense in depth. Per-agent credentials, fork propagation of gates, memory entry scanning, approval gates for irreversible actions, Turnstile coverage audited against the full matrix, anomaly detection on tool calls and spend. L3 is what a production system with meaningful security investment looks like.
L4 — Automated gates. Everything in L3, plus secrets injected at runtime only (agents cannot write them), all content through the sanitization pipeline before publish, zero-trust PII handling at ingestion, lethal trifecta broken by architectural design (no exfiltration channel for agents reading untrusted content), full audit trail on every tool call with alerting, quarterly re-verification. L4 is not a destination — it is a maintained state that requires ongoing attention.
The CI Gate
The most important thing about the audit script is not what it checks — it is how it exits.
Exit code 0 means the stack is at L2 or above. Exit code 1 means L0 or L1. When the CI gate on a PR runs the audit script and gets exit 1, the merge is blocked.
This is the closing doctrine of the entire track: security is a gate problem, not a vigilance problem. Every rule in this track ends as an automated check. Pre-commit secret scanning — automated gate. CI sanitization gate — automated gate. PII scanner — automated gate. Tool policy validator — automated gate. CAPTCHA coverage check — automated gate. Anomaly alerts — automated gate.
An advisory report that does not fail the build is dependent on someone reading it, caring about it, and acting on it — consistently, under deadline pressure, across personnel changes. That is vigilance. Vigilance erodes. Gates enforce the standard on every merge regardless of who is watching.
When the audit script blocks a merge because an agent config has a wildcard tool list, the developer who added it is told exactly what to fix and why. The friction is low (fix the config, re-run, proceed) and the standard is maintained. When the audit runs only as an advisory and the wildcard gets merged anyway because the sprint deadline was tomorrow, the standard quietly degrades until something goes wrong.
What the Audit Does Not Check
The audit script covers the six surfaces with automated checks. There are things it cannot detect:
Semantic injection in prompt files. The injection check looks for a system: header — a marker of instruction hierarchy — but it cannot verify that the system prompt actually enforces safe behavior. A prompt file with system: do whatever the user says passes the check. Prompt review remains a human responsibility.
Runtime behavior. The audit is a static analysis of files. It cannot observe what an agent does at runtime — whether it is actually respecting its tool grant, whether its memory writes are provenance-checked, whether its outbound fetch behavior matches its policy. Runtime observability (audit logs, anomaly detection) is the complement to static audit.
Third-party dependencies. If an agent uses a third-party tool or plugin, the policy of that plugin is not audited here. An agent with a narrow tool allowlist that includes a third-party plugin with broad internal permissions may have a narrower effective grant than the plugin provides.
These limitations are not arguments against running the audit — they are arguments for combining it with runtime observability and periodic manual review. The audit covers the baseline. Observability covers the runtime. Manual review covers the semantic gaps.
Running the Audit in Practice
For a new project, run the audit before first deploy. The L0 result will be expected; the findings list tells you exactly what to implement before accepting production traffic.
For an existing project, run the audit and treat the findings list as a prioritized backlog. The priority order follows the kill chain: S1 (secrets) and S5 (privilege) first, because they are the surfaces that most directly enable a full compromise. S2 (topology) second, because reconnaissance enables targeted attacks. S3 (PII) and S4 (injection) in parallel. S6 (endpoints) last if resources are limited, though cost-DoS exposure makes it more urgent for AI-backed products.
For an ongoing project, wire the audit into CI and run it on every PR that touches agent configs, source code, or content directories. Schedule a quarterly standalone run to catch configuration drift — changes that were made outside the normal PR flow, or new agent roles that were added without updating the policy.
Always-on agent platforms — from AI coding tools like Claude Code to always-on intelligence platforms — run exactly the kind of infrastructure this track was built to protect. The audit script is not theoretical: it checks the failure classes production agent fleets actually hit, and the defenses that contain them.