A new permission means a new approval

The approval you gave at the start of a Claude Code run covered a specific task and a specific scope. The moment the agent widens that scope, you are working with an authorization you never gave.

This happens quietly. The agent starts on a bug fix in one module, decides the shared config needs updating, edits a file outside the approved set, adds a dependency, or calls an MCP tool that was not part of the plan. The summary mentions it in passing. The diff looks reasonable. The reviewer approves.

Nobody noticed that the original approval was for a narrower change. The agent treated the first yes as a blanket yes and granted itself the extra authority.

The fix is a rule that sounds pedantic until you watch the drift it prevents: a new permission means a new approval. Not a note in the summary. Not a line in the changelog. A stop, a request, and a human decision before the expanded work continues.

This is the seam where the two books I keep pairing meet. Claude Code: Building Production Agents That Actually Scale is about the delivery side: task contracts, permission budgets, stop rules, review packets, evals, observability, rollback, and human approval. Securing Enterprise AI Agents is about the authority side: identity, delegated permissions, MCP and RAG boundaries, audit evidence, policy gates, and incident response. Scope drift is an authority problem dressed up as a coding decision. If your team owns both sides, the Enterprise AI Agents in Production bundle is the cleaner starting point.

A one-time approval is not a blanket authorization

The original task contract named a scope. Maybe it was one module, a handful of files, a small allowlist of commands, and no external tools. That boundary was the authorization.

Scope drift is the agent solving the real problem as it sees it. The problem got wider somewhere along the way. The dependency needed updating. The fix touched a shared helper. The test setup required reading a config the agent was not supposed to read. The agent is rarely being malicious. It is being thorough, and thoroughness is exactly what makes the drift easy to miss.

The final diff can look clean while the path that produced it crossed an authority boundary. That is the failure mode. You are not only reviewing whether the code works. You are also reviewing whether the agent stayed inside the authority you actually granted. Those are different questions, and the diff only answers one of them.

What counts as a new permission

Write the boundary down before the run, then treat anything outside it as a new permission:

A file outside the approved scope.
A new dependency.
A command type not in the allowed set.
An MCP tool or method not in the original plan.
A change to shared config, auth, billing, migrations, or policy code.
A second attempt after a denied tool call.
Access to a data class the task owner did not approve.

That list is not exhaustive. The point is to decide upfront what the run is allowed to touch, then notice when it reaches further.

Before the next real Claude Code run, use the free production checklist to set the scope, the stop conditions, and the approval boundaries before the agent starts.

The approval event, not the approval note

The wrong reaction to scope drift is to let it happen and mention it in the summary. “I also updated the shared config” is not transparency. It is a confession filed after the fact.

Transparency is stopping before the config gets touched and asking whether the expanded scope is approved. The approval event has a shape:

Stop the run before the expanded work continues.
State what changed and why the scope grew.
Request explicit approval for the new scope.
Name the owner who accepts the expanded authority.
Log the decision in the run record.
Continue only after the human says yes.

This is not about distrust. It is about keeping the authorization honest as the work changes. Vague trust does not survive scope drift, and the agent that was trustworthy on a narrow task is the same agent that will quietly widen the next one.

Scope drift is an authority problem

Here is where delivery and security stop being separate conversations. A scope expansion is a change in authority. The agent that was allowed to edit one module is now asking to edit shared config, call a tool that reaches production data, or read files the human requester might not be allowed to see.

Security teams have language for this. Delegated authority, least privilege, separation of duties. Engineering teams usually call it “the agent went a bit further than expected” and move on. That gap in vocabulary is why scope drift turns into incidents.

The same rule applies on both sides. The original delegation covered a specific identity, a specific set of tools, and specific data classes. When the agent reaches beyond that, the delegation no longer covers the action. A new permission means a new approval, and the approval needs a named owner who can explain it later.

How reviewers enforce it

Reviewers should not have to read the agent’s mind. Give them two lists to compare: the approved scope, and what the run actually touched.

• Compare approved files against files changed.
• Flag any command, tool call, or MCP method outside the original set.
• Treat unapproved scope expansion as drift, not initiative.
• Ask why the agent needed the wider scope. The answer is usually useful, and it often points at a real problem the task contract missed.

A clean diff with an unapproved file change is still drift. Approving it because the code looks fine is how teams slowly lose track of what their agents are actually allowed to do.

A small template for the next run

Before the next serious Claude Code run, fill this in and keep it next to the review packet:

Approved scope
Files and packages the run may touch:
Commands allowed:
MCP tools and methods allowed:
Data classes the run may access:

Stop conditions
Treat as a new permission if the agent:
  - edits a file outside the approved set
  - adds or updates a dependency
  - runs a command not in the allowed set
  - calls an MCP tool or method not in the plan
  - touches auth, billing, migrations, or policy code
  - retries after a denied tool call

Approval event
Stop. Request. Name the owner. Log the decision. Continue only after yes.

After a few runs, the pattern gets easier to enforce and the drift gets easier to catch. The teams that widen agent autonomy safely are not the ones with the loosest rules. They are the ones whose rules actually match what the agent did.

Build the approval boundary into the loop

If your current problem is keeping Claude Code inside the scope you actually approved, start with Claude Code: Building Production Agents That Actually Scale. The landing page routes Kindle readers to the Amazon edition: get the Claude Code book on Amazon Kindle.

If your problem is the authority model around enterprise agents, read Securing Enterprise AI Agents or go straight to Leanpub. It is built for teams dealing with delegated authority, MCP and RAG boundaries, audit evidence, policy gates, and incident-ready records.

If your team owns both the delivery loop and the authority model, get the Enterprise AI Agents in Production bundle. One book helps you build agent work people can review. The other helps you keep the authority behind it honest.