Confidence: medium. Evidence: production telemetry · case study · controlled study. Last substantive change: 2026-07.
Autonomous production multiplies both the volume of code to secure and the number of ways it can be attacked, including through the agent's own context and skills. Security is where the factory finds, validates, contains, and discloses risk, and where the threat model grows to include the agent itself.
The conclusion
Security must live both inside the generation loop and independent of it, and the factory's own skills, context, tools, and dependencies are attack surface. Agents find and fix vulnerabilities in-loop, but validation and containment must be independent of the agent that produced (or could sabotage) the code.
This rests on three findings, one of them shared with Verification.
1. Security must be inside the loop and independent of it. The in-loop find-and-fix pattern works at scale, but the producer cannot be the authority. This is the same lesson the sabotage study taught Verification, read through a security lens: 94% of developers missed deliberate agent sabotage and 56% merged it even after a correct alert. A builder agent can be deliberately adversarial, so validation must be independent. Cloudflare's fleet harness makes this concrete with a two-model split: a discovery system (VDH) and a separate validation system (VVS), which drove false positives from roughly 40% down to roughly 11% across 128 to 145 repositories.
2. Discovery scales; triage and disclosure are the bottleneck. Project Glasswing surfaced roughly 23,019 estimated vulnerabilities (including 6,202 high-or-critical) in about a month, moving the constraint from finding to validating and disclosing. But discovery value is regime-dependent: against hardened, well-audited curl, the same class of tooling yielded a single low-severity CVE. Large unaudited surfaces yield much; hardened ones little. Budget for validation and disclosure capacity, not just discovery.
3. The agent's own supply chain is attack surface. Skills, context, tools, and dependencies the agent consumes can carry payloads, be poisoned, or be injected at runtime. An audit of 13,728 marketplace skills found 17 confirmed zero-days; "payload-less" attacks subvert an agent through a skill's structure alone. The lethal trifecta (untrusted content, private data, an exfiltration channel) shows up as indirect prompt injection, where an agent's own context window is the attack vector. Treat every skill, tool, and dependency as untrusted until attested.
How the thinking got here
Static scanning, then agentic discovery, then validated find-and-fix loops, then the realization that skills, context, dependencies, and the agent runtime are themselves supply-chain attack surface. In parallel, "scale discovery" gave way to "triage and disclosure are the bottleneck."
Credible alternatives, and when each is right
| Approach | Right when |
|---|---|
| Traditional AppSec gates | mature pipeline; agent output is a minority of changes |
| Single security agent | low volume; discovery, not validation, is the need |
| Two-model find then validate | scaling discovery without drowning in false positives |
| Formal or kernel-level enforcement | high-assurance containment of agent actions |
| Human red team | novel, high-stakes, adversarial-design review |
When it fails
The 9-second database deletion (an irreversible action completed before any human could intervene, because "can execute" was never gated by "may execute") is the same failure Verification records, seen from Security: containment must be architectural, not an approval prompt. Indirect prompt-injection exfiltration shows the newer surface: the agent behaves helpfully while following attacker instructions embedded in its own context.
What we still don't know
How do we establish provenance for the agent's own supply chain? Audits show the risk and frameworks name it, but no adopted attestation standard exists. This advances when a provenance or attestation approach is deployed in the field with measured reduction in the skill and dependency attack class. Relatedly, how independent must the validator be from discovery? This is the same independence question Verification asks about graders.
What would change our mind
Evidence that a single in-loop security agent achieves high precision on hardened targets and resists injection of its own context would weaken the independence requirement. Not observed.
How we approach it (operator note)
ContextStack runs containment-first (isolated, ephemeral, scoped credentials, no production secrets in reach), a two-stage find-then-validate loop with an independent validator, and treats skills and dependencies as a supply chain with provenance and least-authority capabilities. One operator's current choice; revisited if a precise, injection-resistant single agent or an adopted provenance standard emerges.
Sources: Anthropic find-and-fix; Project Glasswing; Semia skill audit; payload-less skills (Zhejiang); The Grand Software Supply Chain of AI Systems (KTH); Stenberg/Mythos-curl; "Can Human Developers Detect AI Agent Sabotage?" (shared with §11); Cloudflare vulnerability harness. Full evidence and lineage in the Security subsystem.
Evidence and further reading
- The find-and-fix loop playbook
- Project Glasswing: ~23k vulnerabilities in ~a month
- Semia: auditing 13,728 agent skills
- Exploiting agent supply chains via payload-less skills
- The Grand Software Supply Chain of AI Systems
- Mythos finds a curl vulnerability (deflationary counter-voice)
- Cloudflare: Build your own vulnerability harness
- Can Human Developers Detect AI Agent Sabotage?
- Noma Security: GitLost, leaking private repos via GitHub's AI agent