An AI coding assistant deleted a repo’s input-sanitization pattern while “fixing” it, and days later an autonomous red agent found the resulting injection and walked out with Jira API tokens. The lesson isn’t “AI writes bad code” — it’s that AI-authored commits are landing inside CI/CD trust boundaries that were designed assuming a human wrote the diff.
- 🎯 The bug was a downgrade, not a typo: the autofix removed an existing safe pattern and expanded untrusted input straight into a
run:shell block — a regression a diff-level reviewer skims right past. - ⚠️ The blast radius was CI secrets: a crafted GitHub issue title executed arbitrary commands on the runner, exfiltrating the Jira API token and friends. Workflow secrets are the soft underbelly of every repo.
- ⚡ Attacker and defender were both agents: the red agent hit a bash error, diagnosed it, rewrote the payload, and succeeded — the same act-observe-retry loop I build into production agents, pointed at offense.
- 🔍 Provenance is the missing signal: almost nobody tracks “this commit was AI-authored” as a review priority, yet that’s exactly the label that should raise the bar, not lower it.
- 📊 Autofix relocates the bottleneck, it doesn’t remove it: faster remediation is real, but an unreviewed machine patch to a security-critical workflow is a net-new attack surface.
Read the Wiz writeup for the full kill chain; the HN discussion has the usual fight over whether to blame the tool or the pipeline.
The wider reaction is landing cautionary rather than panicked. The Register frames it as a systemic AI-on-AI pattern surfaced by a sanctioned red-team test, not evidence that autofix is broken, while Cyber Kendra leans harder on the irony of a fix tool shipping the vulnerability and argues teams should treat AI-generated workflow commits as untrusted code. Both land in the same place: the review bar for machine-written diffs should go up, not down — and in most pipelines right now, it’s drifting the other way.