№ 01 TALK · AI NATIVE DEVCON 2026

Who gets
the keys?
Not the agent.

Trust and Authority in Software Factories. Human review after the code exists was never the control. At agent speed, judgment moves upstream into intent and architecture, enforcement moves into the deployment pipeline, and the keys to production belong to neither the agent nor the human. They belong to the pipeline — and only if the pipeline is the most protected thing in the system.

№ 02 THE SLIDES

Most of your pipeline survives agents. Code review doesn’t.

Sixteen slides, the complete deck. Built around three questions about the delivery pipeline you already have: what to keep, what to change, and what to add now that agents write the code.

Who Gets the Keys? Trust and Authority in Software Factories

  • Keep. The backbone that already works: fast feedback from local through source, build, test, deploy, and production telemetry, with static and dynamic analysis, dependency and secrets scanning. Seconds before commit, minutes in the pipeline, hours in production.
  • Change. Human review moves ahead of the code, to intent and architecture, while AI reads every diff and routes the risky ones to a person. Agents write the tests now, so the tests themselves have to earn trust.
  • Add. Four failure modes that exist only once an agent is in the loop, grouped as TAKO: prompt injection, untrusted context, data poisoning, and the agent’s own read of production telemetry. Plus slopsquatting, where attackers pre-register the package names models hallucinate.
  • Evidence over approval. Signed attestations, provenance down to the spec ID and model version, mutation score instead of coverage, and intent verification in both directions, checked by an independent validator that sees only the spec.
  • Authorship is not authority. The agent writes code, tests, and fixes, and proposes spec and pipeline changes. It never holds deploy keys, standing cloud credentials, or the ability to loosen its own guardrails. The pipeline holds the key, and earns it only by being the most protected thing in the system.
  • The issue tracker is untrusted input. Three incidents, each defeating a stronger guardrail than the last. Invariant Labs, May 2025: no guardrail at all, and a hidden instruction in a public issue leaked private-repo data out through a public pull request. Cline’s “Clinejection”, February 2026: an issue-triage agent shared a build cache with the nightly release job, which restored the poisoned cache and gave up the publish token. Noma Security’s “GitLost”, July 2026: a read-only agent with filtered output, and one word still got past it. The guardrail changed each time. The reach did not.
  • Drift detection. Production, pipeline, and spec drift, plus a separate alarmed break-glass path, all watched from a security account the pipeline cannot touch.
Open the slides →

16 slides · opens in Google Slides

№ 03 COMPANION REPO

Nineteen bad changes tried to ship. None of them did.

Claude Code wrote a small export service. Fifteen checks guard it, and every deliberately bad change trips exactly one of them, by name. Clone it and watch them fail in your own environment.

PaulDuvall/who-gets-the-keys

  • Fifteen checks, fail-fast. Secrets, dependency allowlist, workflow hardening, install, lint, typecheck, infrastructure as code, SAST, SCA, traceability, commit signatures, slide parity, a guardrail ratchet, tests, and mutation score. Every failure prints one line naming the check.
  • Nineteen bad changes, each stopped by a named check. A test that asserts nothing, an invented package name, a hard-coded secret, a cache shared with a deploy job, an unattested artifact reaching deploy, an irreversible change without approval, and a poisoned GitHub issue, among others.
  • Authority boundaries enforced, not described. The agent writes code, tests and docs, and proposes spec and pipeline changes in a separate directory. It cannot sign commits, write to the spec, deploy, hold cloud credentials, or loosen its own guardrails.
  • The deck is the source of record. The slides are pinned in the repository, and a check fails if the practice table drifts from them. A second table records every place the build departs from the talk, and why.
git clone \
  https://github.com/PaulDuvall/who-gets-the-keys.git
cd who-gets-the-keys
npm ci --ignore-scripts
npm run checks
npm run scenarios
View the repository →

MIT licence · TypeScript · Node 24

№ 04 PATTERNS & CODE

The patterns behind the talk are in the open.

Everything the talk describes as codified — rules, hooks, context files, orchestration — is public and forkable. Start here rather than from the slides.

№ 05 SPEAKER & WRITING

Two decades of making CI/CD work — now applied to agent-written code.

Paul Duvall is the founder of Redacted Ventures and author of Continuous Integration, winner of a 2008 Jolt Award. Previously he held director roles at AWS spanning DevSecOps, security engineering, and security innovation. Before AWS he co-founded Stelligent, an AWS-focused DevOps engineering firm acquired twice, and is an AWS Hero alumnus. Since 2023 he has built extensively with AI coding agents.

AUTHORED
  • Continuous Integration: Improving Software Quality and Reducing Risk · Addison-Wesley · Martin Fowler Signature Series · 2008 Jolt Award
  • DevSecOps on AWS series · continuous security and continuous compliance

More writing at paulmduvall.com ↗.

FREE · 5 MIN

Where does your pipeline actually stand?

Fifteen questions on the gates, hooks, and evidence around your agent-written code. You get a readiness score, the specific patterns to apply, and a 30-day action plan, emailed immediately.

Take the scorecard →
№ 06 QUESTIONS FROM THE TALK

Disagree with any of it? Say so.

If something in the talk does not survive contact with your pipeline, that is the useful conversation. Send the specifics and you will get a direct answer, not a pitch. Typical response within one business day.

Response time
< 1 business day
Time zones
US business hours