A coding copilot suggests. A coding agent acts. That one-word difference is the whole governance problem.
Through 2025 most engineering teams governed AI as if it were a smarter autocomplete: a suggestion appears, an engineer accepts or rejects it, a human keystroke sits between the model and the repository. By 2026 that assumption is broken. Background agents open branches, run test suites, refactor across files, file pull requests, and in some setups merge them. The human is no longer in the loop by default. They are on the loop, supervising, or off it entirely.
When we are asked to help a team in Hamburg or across the DACH region get this under control, the first thing we look for is whether anyone has actually defined what an agent is allowed to do without a person present. Usually no one has. The policy still assumes a human at the keyboard.
Key takeaways
- A copilot suggests; an agent acts. Governance written for suggestions does not cover autonomous actions.
- Define an agent's scope as an explicit allowlist with least privilege, never a denylist.
- Place human gates where risk concentrates, and keep a human on every merge to production.
- An agent is never the owner. Assign a named, accountable team to each agent and everything it ships.
What makes an agent different from a copilot
The distinction is not model quality. It is autonomy and blast radius. A copilot proposes a change inside an editor a developer is already watching. An agent takes a goal and executes a sequence of actions toward it, often touching systems no single reviewer is watching in real time.
| Property | Copilot (assistive) | Agent (autonomous) |
|---|---|---|
| Trigger | Human keystroke | Goal, schedule, or webhook |
| Human position | In the loop, per suggestion | On the loop, or absent |
| Scope of action | One file, one cursor | Many files, commands, external calls |
| Failure visibility | Immediate, in-editor | Delayed, in CI or production |
| Who owns the output | The accepting developer | Often undefined |
That last row is where incidents come from. When a suggestion ships, the developer who accepted it owns it. When an agent ships, ownership has to be assigned deliberately, because there was no single moment of human acceptance to pin it to.
The three questions to answer before agents run unattended
Before any agent runs without a person watching each step, an engineering organization needs a clear answer to three questions. If you cannot answer them, you are not governing agents, you are hoping.
- What is the agent allowed to touch? Which repositories, branches, environments, credentials, and external services are in scope, and which are explicitly out.
- Where does a human have to approve? Which actions an agent may take freely, which require review before they take effect, and which it may never take.
- Who owns the result? The named person or team accountable for what the agent ships, regardless of how autonomously it was produced.
These map to a simple control surface: scope, gate, owner. The rest of this article is how to make each one concrete.
Scope: define the blast radius before the first run
An agent's blast radius is the set of things it can change or reach. Most default agent setups have a far larger blast radius than anyone intended, because the agent inherits whatever permissions its credentials carry.
We recommend defining scope as an explicit allowlist, not a denylist. A denylist assumes you can enumerate every dangerous action in advance. You cannot. An allowlist assumes the opposite: the agent may act only within an enumerated boundary, and anything outside it requires a human.
| Scope dimension | Tight default | Why |
|---|---|---|
| Repositories | Named repos only | Stops cross-project surprises |
| Branches | Feature branches, never main | Keeps a human merge gate |
| Environments | Non-production by default | Production access is a separate, audited decision |
| Credentials | Scoped, short-lived tokens | Limits damage if the agent misbehaves |
| External calls | Allowlisted endpoints | Prevents data leaving to unvetted services |
The principle is the same one security teams have used for service accounts for years: least privilege. An agent is a non-human actor with credentials. Treat it like one.
Gates: decide where a human must stand
A gate is a point where an agent's action stops until a human approves it. The art is putting gates where risk concentrates, not everywhere, because a gate on every action turns an agent back into a slow copilot and the team will route around it.
We sort agent actions into three tiers:
- Free actions the agent may take and complete on its own: reading code, running tests, drafting changes on a feature branch, opening a draft pull request.
- Gated actions that require human approval before they take effect: merging to a protected branch, changing dependencies, touching infrastructure or migrations, anything that reaches production.
- Forbidden actions the agent may never take: handling secrets in plain text, deploying to production unattended, modifying access controls, acting outside its scoped repositories.
The merge gate is the most important one. As long as a human reviews and merges, the existing code-review discipline still applies, and the agent is a very fast contributor rather than an unsupervised committer. Most teams should keep that gate closed for a long time.
Accountability: an agent is not an owner
The most damaging idea we hear is that the agent is responsible for its output. It is not. An agent cannot be on call, cannot be questioned in a post-incident review, and cannot be accountable to a customer. Responsibility has to land on a person or a team.
This is not only good operational sense. Under the EU AI Act, human oversight of AI systems is a governance expectation, not a nice-to-have, and oversight is meaningless if no human is actually answerable for what the system did. "The agent wrote it" is not a defence. It is the absence of one.
Practically, we assign accountability the same way teams assign code ownership: every agent has a named owning team, every change an agent ships inherits that team's ownership until a reviewer takes it on, and the owning team is responsible for the agent's scope, gates, and behaviour over time.
A starter operating model for agents
If we were standing up agent governance for an engineering organization in 2026, this is the minimum we would put in place before the first unattended run.
| Control | Concrete form |
|---|---|
| Agent registry | A list of every agent, its purpose, scope, and owning team |
| Scoped credentials | Short-lived, least-privilege tokens per agent |
| Branch protection | Agents push to feature branches; humans merge |
| Action tiers | Free / gated / forbidden, written down and enforced |
| Audit trail | Every agent action logged: what, when, on whose authority |
| Kill switch | A documented, tested way to stop an agent immediately |
None of this is exotic. It is the operating discipline teams already apply to deployments and service accounts, extended to a new kind of actor.
What this is not
This is not an argument against agents. Used inside a clear boundary, agents are the most significant productivity shift in engineering since CI. The teams that win will not be the ones that ban them, nor the ones that let them run unscoped. They will be the ones that can say, in one sentence, what each agent may do and who answers for it.
It is also not a call for a large new bureaucracy. The controls above fit on a page. The work is not volume, it is clarity: deciding the boundary on purpose instead of discovering it during an incident.
Our view
The shift from copilot to agent is a shift in who operates your codebase. Governance that was written for suggestions does not cover actions. The organizations that treat an agent as a credentialed, scoped, owned actor, with a human standing at the gates that matter, will scale agents safely. The ones that treat an agent as a faster autocomplete will find out the difference the hard way, in production.
Decide the blast radius, place the gates where risk lives, and put a name on the result. That is the whole job.
Sources
- EUR-Lex, Regulation (EU) 2024/1689 (EU AI Act), Article 14 on human oversight, accessed 2026-06-10
- NIST,
AI Risk Management Framework (AI RMF 1.0), accessed 2026-06-10 - OWASP,
OWASP Top 10 for Large Language Model Applications, accessed 2026-06-10
Frequently asked questions
- What is the difference between an AI coding copilot and an AI coding agent?
- A copilot suggests changes inside an editor a developer is watching, with a human keystroke between the model and the repository. An agent takes a goal and executes a sequence of actions toward it — opening branches, running commands, filing or merging pull requests — often with no human in the loop. The difference is autonomy and blast radius, not model quality.
- What should an AI coding agent be allowed to do without human approval?
- Define scope as an explicit allowlist using least privilege. Agents should freely read code, run tests, and draft changes on feature branches. Merging to protected branches, changing dependencies, touching infrastructure or migrations, and anything that reaches production should require a human gate. Handling secrets, deploying unattended, and acting outside scoped repositories should be forbidden.
- Who is accountable when an AI agent ships broken code?
- A named person or team — never the agent. An agent cannot be on call, questioned in a post-incident review, or accountable to a customer. Assign each agent an owning team, and have every change it ships inherit that ownership until a reviewer takes it on. Under the EU AI Act, human oversight requires a human who is genuinely answerable for what the system did.
- What is the minimum governance needed before running coding agents unattended?
- An agent registry, scoped short-lived credentials, branch protection so humans merge, written free/gated/forbidden action tiers, an audit trail of every agent action, and a tested kill switch. These controls fit on a page; the work is clarity, not bureaucracy.
