GitHub now supports coding agents that can interpret an issue, inspect a codebase, modify multiple files, run tests, respond to failures, and open a pull request for human review. All of that happens asynchronously, with limited human involvement at each step.
That’s a governance problem, not just a productivity feature.
The accountability gap
For decades, software accountability mapped neatly to human activity: a developer wrote the code, another reviewed it, CI verified it. An AI coding agent inserts a new actor between intent and implementation. The question shifts from “can AI write acceptable code?” to “who is accountable when AI-generated code ships a bug, introduces a vulnerability, or drifts from the architecture?”
The answer can’t be “the AI.” The organization that owns the software remains accountable for its production behavior regardless of who, or what, generated the implementation.
️ Assistants vs. agents: the distinction that matters
A coding assistant generates suggestions inside a developer-directed interaction. The developer reviews the output and decides what happens next. An agent operates at a higher level: it receives a task, plans changes across multiple files, executes tests, diagnoses failures, and creates pull requests with less continuous human involvement.
The risk profile changes when AI moves from generating suggestions to taking actions. Microsoft’s guidance identifies agent sprawl, excessive permissions, tool misuse, prompt injection, and data leakage as risks that require centralized visibility and governance.
What a stronger accountability record looks like
Recording only “developer X approved pull request Y” leaves gaps. A more complete production chain looks like this:
- Business intent defines what the change is supposed to accomplish.
- Authorized agent performs the implementation with scoped permissions.
- Model and context are recorded as part of provenance.
- Automated verification covers SAST, dependency analysis, secret scanning, and tests.
- Human decision is made with sufficient evidence, not just a review button.
- Release control enforces policy before deployment.
- Production owner carries accountability for the resulting software.
SLSA’s Source Track is relevant here: it provides a framework for establishing evidence about when a source revision was created, who or what created it, and which technical controls were enforced.
⚠️ Common failure modes
The source article from The Code Registry identifies several patterns that trip up engineering teams adopting agents:
- Trusting generated tests to prove generated code (they often share the same assumptions).
- Reviewing the diff instead of evaluating architecture impact.
- Granting agents permissions broader than the task requires.
- Treating a human approval event as equivalent to informed assurance.
- Ignoring provenance, which makes incident investigation harder.
- Measuring pull request volume instead of escaped defects and architecture drift.
OWASP flags prompt injection as a major risk for agentic systems: every file, issue description, comment, and dependency metadata the agent reads is a potential instruction surface, not just the prompt a developer types.
The practical framing for operators
If you’re running a small engineering team and starting to use agents in your workflow, the governance question boils down to: what is the maximum autonomy acceptable for this risk class? A formatting change can probably be governed through automated policy. A cryptographic implementation needs specialist review. A production authorization change needs both security approval and release controls.
Risk-based delegation lets you capture AI productivity without treating every software change as equally consequential. The goal isn’t to prohibit autonomy. It’s to make autonomy proportional to the stakes.

