Why Coding-Agent Governance Needs More Than Approval Gates

Human approval is an important control for coding agents, but it cannot carry the full weight of governance. Effective governance also limits agent access, enforces rules during execution, manages exceptions and preserves a record of what happened.

Your most productive engineer this quarter might not be a person. Point Claude Code or GitHub Copilot’s coding agent, for example, at an issue and it reads the repository, writes the code, runs the tests and opens the pull request in minutes.

That speed can break the review cycle. Someone who used to read one 200-line diff a day now faces 10 agent-authored pull requests before lunch. As volume increases, so does the risk that a developer approves a change without fully reviewing it, relying on tests the agent may have written itself. This is where governance comes in.

Governance defines what an agent is allowed to do on its own, where human judgment is still required and what evidence must remain afterward. A coding agent needs four types of control:

• Permissions: The repositories, branches, files and deploy targets the agent can access or change
• Checks: Runtime rules that inspect each action and determine whether they should be allowed, require approval or be blocked
• Exceptions: A documented, expiring path for legitimate work that falls outside those rules
• Audit: A record of what the agent did, under which identity, with whose approval

Image generated with ChatGPT

These controls do not need to live in one place to be effective. Permissions may be enforced through identity and access controls, checks through CI, exceptions through existing approval workflows and audit through pipeline and system logs.

What matters is whether those controls work together well enough to answer a few basic questions: What could the agent do? What did it actually do? Which actions required human approval? And can you demonstrate that after the fact?

That is the foundation of coding-agent governance: not another approval step, but a system of boundaries, checks and evidence that can keep up with the speed of automated development.

Permissions Define What the Agent Can Touch

A coding agent should only have access to the exact systems and actions it needs for the specific task it’s doing—nothing more.

If an agent is updating documentation, for example, it may need permission to edit the docs/ folder on a feature branch. It does not need permission to push directly to main or fire the production deploy.

The problem starts when teams give agents credentials with much broader access than the task requires. The OWASP Top 10 for LLM Applications calls this excessive agency: more permission or autonomy than the task requires.

Coding agents can make mistakes. They can generate a destructive command, misunderstand an instruction or follow malicious content hidden in an issue, comment or README. This isn’t a model-quality problem, and a smarter model only argues more persuasively for the wrong command. But a bad instruction can only cause serious damage if the agent has permission to carry it out.

So limit access based on the task, not the tool:

• Give the agent its own identity rather than using a developer’s credentials.
• Limit access to only the repositories, files and actions the task requires.
• Allow specific actions the work needs (read files, run the test suite, open a pull request) instead of raw platform access.
• Use a disposable branch like agent/issue-482, and protect main with a rule the agent’s identity can’t bypass.

Security teams call this “least privilege,” which NIST defines as granting only the privileges a task needs. You already apply it to people. The difference with coding agents is speed and autonomy. Because they can take actions on their own, limiting what they are allowed to touch becomes even more important.

Checks Assess Risky Actions Before They Run

Permissions define what an agent it capable of doing. Checks decide whether a specific action should actually be allowed.

A check is a rule evaluated during the agent’s work and can allow the action automatically, require human approval or block it entirely.

For example, file reads and a sandboxed npm test might auto-approve. Dependency manifests and environment files may require human approval, and so does any arbitrary shell command. Force-pushing a shared branch or touching production may be blocked.

The mechanisms already exist in tools you run. In Claude Code, for example, hooks and permission settings allow Bash(npm test) while prompting on Bash(git push*), and most agent CLIs expose an equivalent. On the CI side, a GitHub Actions environment with required reviewers holds a deploy job until a named person approves it, and GitLab and Azure Pipelines do the same.

The goal is not to put a human approval step in front of every action. If developers are asked to approve routine behavior constantly, they will eventually stop reviewing those requests carefully.

Checks work best when they match the level of risk: low-risk actions proceed automatically, higher-risk actions require review and unacceptable actions are blocked. That keeps human attention focused on the decisions where it actually matters.

Pro Tip: Watch the ratio of approvals to denials per agent. A gate that never denies anything is either perfectly scoped or never actually read.

Exceptions Need an Owner

A policy that can only say “no” won’t survive real work. Governance rules need a controlled way to handle legitimate work they were not designed to allow. An exception is documented, time-boxed permission to proceed despite a blocking rule, with a named person responsible for approving it. An exception should not remove the rule entirely.

Say the agent must bump a pinned dependency to patch a CVE, but the rule guarding package-lock.json blocks the edit. Don’t delete the rule. Grant a 48-hour exception from a named owner for that one file on that one branch.

Record who asked, what got unblocked, why and when it expires. Once the work is complete, the extra permission should disappear automatically.

Exceptions should also be reviewed over time. If teams repeatedly request the same exception, that may be a sign that the underlying policy needs to change. If the policy system itself fails, the agent should not treat that as permission to continue. It should fall back to stricter rules or stop until the check can be completed.

The goal is to make exceptions possible without turning them into permanent loopholes.

The Audit Is the Receipt

Governance is not just about stopping risky actions. It’s also about keeping reliable evidence of what the agent did and who approved it.

Where checks try to prevent unsafe actions, audit logs create a record showing what actually happened. Log every action: the identity that ran it, the prompt behind it, the tools that fired and the human who approved any sensitive steps. A receipt you can’t edit is the only one worth keeping.

Most of it already exists. A workflow run records who ran what and who approved, and the pull request timeline records the merge. Ship both to an append-only store so they outlive your retention window.

Regulators want that traceability: Article 14 of the EU AI Act requires effective human oversight of high-risk systems, and NIST’s AI Risk Management Framework and ISO/IEC 42001 ask for documented evidence.

Good audit records, from a governed workflow, let you answer questions with evidence rather than relying on someone’s memory.

Build the Gate into the Workflow

The strongest gates are structural. A per-action prompt interrupts one action, but a phase boundary between planning and implementation stops everything downstream and is harder to click past. Reading the plan before any code exists means approving intent, and wrong intent is cheaper to fix than a bad merge.

Progress built its Forge CLI, one example of an agentic SDLC tool, around that shape. Its task flow keeps planning separate from the code it produces, so the human checkpoint lands between phases instead of mid-run.

What matters is that the agent’s pull requests take the path your human changes do: the same protected branches and peer review, secret scanning included. An agent that can merge around that path just breaks your own rules faster than anyone can catch it.

Four Questions Before You Scale Coding Agents

Before expanding the use of coding agents, ask:

1. Can you list everything the agent’s credential can reach? If it lives in a spreadsheet someone maintains, the scope is wider than the task.
2. Which actions wait for a human? If nothing does, or the prompt fires so often nobody reads it, you’ve trained a rubber stamp.
3. Who owns the exceptions? If the answer is “whoever is on call,” the exceptions own you.
4. Can you produce the receipt? If you can’t show who approved a change and when, the agent is running ahead of its controls.

Coding agents can execute software work at a speed that makes manual oversight alone difficult to scale. Governance is what lets coding agents run at full speed.

The goal of governance is to put controls at the right layers: constrain authority with permissions, classify actions with checks, route unusual cases through managed exceptions and preserve the evidence through audit. Then use human approval where human judgment actually adds value.

Governance should be repeatable, documented and built into the development environment rather than dependent on individual memory. Whether you buy an AI governance platform or wire the four controls from tooling you own, build it once as configuration in the repository, not tribal knowledge.

That is what makes coding agents easier to scale safely: the next agent starts with the same boundaries and controls already in place.

Learn More About Progress Forge Orchestration

If you’re ready to move from isolated AI coding tasks to repeatable engineering workflows, Progress Forge (formerly Progress Agent Harness) is designed for exactly that shift. It orchestrates the AI coding agents your team already uses through structured workflows with visibility, governance and human review built in.

Explore the Progress Forge Early Access Program to see how it can help you put these ideas into practice.

Request a Demo