The pull request now has more than one actor

Code review used to be messy in familiar ways. A developer made a change. Another developer reviewed it. Maybe the reviewer missed something. Maybe the tests were thin. Maybe the approval was rushed because release pressure won.

Not ideal, but the social model was clear enough: a person proposed a change, another person accepted the risk, and the delivery system moved it toward production.

AI assisted software work bends that model.

A coding assistant may draft the function. An agent may modify several files. A developer may accept a suggestion without fully understanding the dependency impact. Another tool may generate tests that mostly confirm the generated behavior. A bot may open the pull request. A human may click approve because the diff looks ordinary.

The mistake is treating that as normal code review with faster typing.

The security issue is not that AI wrote code. The issue is that authority, intent, evidence, and accountability can spread across humans, tools, prompts, repositories, CI jobs, and deployment systems without anyone naming the actors.

That is how code review stops being review and becomes theater with green checks.

The author field is not enough

Most software delivery workflows have a convenient fiction: the pull request author is the person accountable for the change.

That was already imperfect. Pair programming, copied snippets, dependency updates, generated clients, and bot commits all complicated authorship before AI showed up.

AI makes the gap harder to ignore.

A useful actor model for AI pull requests should answer a few boring questions:

  • Who requested the change?
  • Who generated or materially shaped the code?
  • Who accepted the generated output into the branch?
  • Who reviewed the security and business impact?
  • Who can override failed checks?
  • Which identity caused CI, secrets, deployments, or release automation to run?
  • Who owns the change after merge?

Those are not academic questions. They decide whether an incident review has a real trail or a confusing pile of commits, bot accounts, and approvals.

If an AI agent can open a pull request, update it after comments, trigger CI, and request review, the organization needs to know whether that agent is acting as a drafting tool, a contributor, or a delegated operator.

Those are different risk shapes.

Separate assistance from authority

A coding assistant suggesting a helper function inside an IDE is one thing. An agent that edits authentication middleware across services is another. A tool that can also run tests, inspect failures, change configuration, and retry until checks pass is different again.

The control should not be based on whether AI was involved. That question is already too blunt.

The better question is: what authority did the AI assisted workflow have?

Drafting authority means the tool can propose code, but a human must select, modify, and commit it under normal development controls.

Branch authority means the tool can write to a branch or open a pull request, but cannot approve, merge, change protection rules, or access broad secrets.

Workflow authority means the tool can trigger jobs, call developer platforms, update tickets, or coordinate release steps.

Production authority means the change can reach customers, data, infrastructure, or privileged business workflows.

Security review should get stricter as the authority increases. Not louder. Stricter.

That is the same argument behind treating the merge point as a governance boundary. The earlier Zero Drama Security piece on AI generated code governance made this point from the code generation side: prompt policing is weaker than controlling what is allowed to merge. AI pull requests need the same discipline, but with clearer actor evidence.

Review evidence has to change

A reviewer cannot responsibly approve what they cannot see.

That does not mean every prompt needs to be archived forever. Broad prompt retention can create privacy and confidentiality problems of its own. It does mean the pull request should carry enough context for review.

Useful evidence may include:

  • the stated purpose of the change
  • whether AI generated or modified material parts of the diff
  • the human owner accepting responsibility for the branch
  • impacted components, permissions, data flows, and public interfaces
  • security relevant files touched, such as auth, tenancy, logging, crypto, billing, or admin workflows
  • tests added or changed, including whether they were generated
  • CI jobs triggered and privileged resources reached
  • exceptions, overrides, or manual approvals used

This is not paperwork for its own sake. It is the minimum context needed for a reviewer to decide whether the change deserves normal review, deeper review, or a different release path.

The worst version is a beautifully formatted AI pull request description that says almost nothing. Polished summaries can hide uncertainty. A good summary tells the reviewer where to look, what changed, and what risk changed with it.

CI is part of the actor model

Many teams focus on the pull request and forget what happens after it is opened.

CI/CD is where software change receives delegated power. Tests run. Secrets are injected. packages are built. artifacts are signed. infrastructure plans are generated. deployments may become possible.

If an AI assisted branch can trigger the same privileged pipeline as trusted human authored code, then the pipeline becomes part of the AI control surface.

This is especially important where every pipeline can read broad credentials. Zero Drama Security has covered why CI/CD secrets become delegated authority, not just values stored somewhere safe. AI assisted changes make that point sharper.

A sensible design may restrict which branches can access sensitive jobs, require human approval before privileged workflows run, separate test credentials from deployment credentials, and log which actor caused each job to execute.

That slows some work down. Good. Some work should slow down at the boundary where generated change meets privileged automation.

The tradeoff is speed with named ownership

Teams adopting AI coding tools often want the upside without adding ceremony. That instinct is reasonable. If every AI assisted change requires a special committee, developers will route around the process or stop being honest about tool use.

The answer is not a giant AI code review board.

The answer is a small set of explicit operating rules:

  • low risk suggestions can flow through normal review
  • sensitive components require declared AI involvement and stronger reviewer context
  • agents get scoped identities, not borrowed human ambiguity
  • generated tests do not replace human review of intent
  • merge protection remains the production boundary
  • CI privilege is granted by branch, actor, and action, not convenience

This is governance that fits the workflow instead of pretending the workflow did not change.

If your software delivery process is already absorbing AI generated pull requests faster than ownership, evidence, and CI boundaries can keep up, Zero Drama Security services can help turn that into an operating model instead of another policy nobody follows.

The goal is not to make AI coding scary. It is to stop pretending a pull request has only one author, one intent, and one accountable actor when the delivery chain now says otherwise.

Code review still works.

It just needs to review the actors, not only the diff.