Governing Agentic AI at Scale: Securing AI-Generated Code in the CI/CD Pipeline

Treat an AI coding agent as a new kind of contributor: its changes go through the same pipeline as everyone else's, with extra evidence about which agent made the change, from which task, with which permissions, and which person owns the risk. CI/CD is the right place for that control, because the pipeline already decides what builds, what is tested, what ships and what rolls back.

Most delivery controls still assume a human engineer wrote every commit and understood it. Coding agents break that assumption in three ways: they produce more changes, their code looks plausible whether or not it is right, and they often hold credentials to the repository and the build system. This guide covers where the controls belong, how to give agents an identity and a paper trail, how to scale review by risk, and what to measure.

Why AI-generated code changes the risk model

• Volume. An agent can open more pull requests in a day than a reviewer can read carefully, so review quality drops exactly where scrutiny matters.
• Plausibility. Generated code compiles, follows conventions and reads well. A subtle bug, an insecure default or a missing edge case looks the same as correct code at a glance.
• Dependencies. Agents suggest packages. A misspelled or invented package name is an opening for typosquatting, and every new dependency widens the supply chain.
• Credentials. An agent that can push to a branch and trigger CI holds real power. A compromised tool, or a prompt injection hidden in an issue or a file, can use it.

None of this means banning coding agents. It means the pipeline has to know which changes came from an agent and treat them according to what they touch.

Where the controls belong

Give each agent an identity, not a shared token

Every agent should act under its own identity with the narrowest scopes it needs: the repositories it works in, the branches it may push to, never the permission to merge into a protected branch on its own. Deployments should use short-lived credentials rather than keys an agent can copy.

In the CI/CD we built for alice/ai, GitHub Actions reaches AWS through OIDC, and DEV and PROD run as separate pipelines. A deployment assumes a role for the length of the run; no long-lived production key exists for an agent, or anyone else, to leak. Removing access is a change to that role.

Record provenance on every change

Reviewers, auditors and incident responders all need to tell agent changes from human ones later.

• Mark agent-written commits. In our own repositories, commits an AI agent wrote carry a co-author trailer naming the agent, so the history separates agent changes from human ones without guesswork.
• Link the task. Each agent pull request should reference the ticket or instruction it came from, so a reviewer can check the change against the intent.
• Sign and attest builds. Build provenance, as described by the SLSA framework, records what was built, from which source, by which pipeline, so a release can be traced back to the change that produced it.

Scale review by risk

Reading every agent diff line by line does not scale, and skimming them is worse than useless. Gate changes by what they touch:

CODEOWNERS rules and branch protection make most of this enforceable today: the agent can open the pull request, but only the right person can merge it.

Tests are the real gate

A reviewer judges whether code looks right; tests show whether it behaves right, which is the property generated code is most likely to get wrong. Require tests for every behaviour an agent changes, and run them on every pull request. The projects we deliver lean on this: Graspr has Playwright covering its flows end to end, and the Zeno backend runs its suites with Jest and supertest. For rules that must never regress, check that the test fails when the rule is broken, not only that it passes when the code is right.

Watch the pipeline, not only the code

A compromised or misdirected agent shows up in what it does before it shows up in an incident:

• repositories, files or branches outside its usual scope
• new dependencies, especially unfamiliar or freshly published ones
• changes to CI workflows, permissions or branch protection
• secrets appearing in a diff or a log, which a secret scan on every pull request should block
• runs at unusual times or in unusual volume

Alert on each of these, and keep agent credentials short-lived so that any compromise expires on its own.

Measure agent changes separately

The DORA metrics still apply: deployment frequency, lead time for changes, change failure rate and time to restore service. Split them by author. If the change failure rate rises, you need to know whether agent changes, human changes or both are driving it. Add two numbers specific to agents: review time per agent pull request and the revert rate of agent changes. A falling review time with a rising revert rate means reviewers have started rubber-stamping.

Common mistakes

• Letting agents share one bot token with broad repository and CI permissions.
• No way to tell agent commits from human ones after the fact.
• Reviewing agent changes by volume rather than by risk.
• Accepting suggested dependencies without checking the package name and source.
• Letting an agent merge or release on its own because its tests passed.
• Dashboards that report delivery metrics without separating agent and human work.

Where to start

Begin with identity and provenance: a separate, least-privilege identity per agent, a mark on every agent commit, required tests and scans on every pull request, and a human code owner for anything risky. Then add risk-based gates and agent-specific metrics. That is the same groundwork we lay when we build AI agents for clients, and the monitoring that keeps it honest is part of how we operate the systems we ship.