Claude Code needs a permission budget
The first time Claude Code saves you half a day, the obvious temptation is to widen the lane.
Give it more files. More tools. More context. Let it run longer. Let it fix the follow-up issue while it is already in there.
I think that is exactly the moment to slow down.
The scarce resource in a production agent workflow is not speed. It is permission. Every serious Claude Code run needs a budget for what the agent may read, edit, call, spend, and decide before a human reviews the evidence.
Without that budget, “autonomy” becomes a vague compliment. The agent did more. It crossed more boundaries. It touched more hidden dependencies. Sometimes that is fine. Sometimes it quietly moves risk into review, security, billing, data handling, or deployment.
A useful permission budget is boring on purpose. That is the point. It turns a fast coding run into something a team can inspect without reconstructing the whole session from chat history and vibes.
The autonomy trap
Successful runs create pressure for bigger runs.
Claude Code fixes the bug, so you ask it to clean the neighboring code. It handles the tests, so you let it adjust a fixture. It spots a config mismatch, so you let it inspect the service next door. The work still feels connected, but the risk has changed.
A local parser fix is one kind of work. Reading production logs is another. Changing a test is different from changing the behavior the test was meant to protect. Calling an MCP tool that can reach an internal system is not the same as opening another file in the repo.
The model may experience all of these as steps toward the goal. Your workflow should not.
This is where teams get into trouble. They do not wake up and decide to give an agent too much reach. They start with a useful run, then reward usefulness with more access. A week later, nobody can say which part of the system Claude Code is allowed to affect without asking first.
That is not an autonomy strategy. It is permission drift.
What the budget should cover
A permission budget answers six questions before the run starts.
Read scope: what can Claude Code inspect?
Edit scope: what can it change?
Tool scope: which MCP tools or commands can it call?
Spend scope: how long can it run, and how many retries are allowed?
Decision scope: what can it decide without a human?
Stop rules: what forces the run to pause and ask?
The best version is small enough to paste into the task prompt. For example:
Goal: fix the failing invoice export test.
Allowed reads: invoice export module, its tests, linked ticket PAY-1842.
Allowed edits: invoice export module and tests only.
Allowed commands: npm test -- invoice-export.
Allowed tools: read-only ticket lookup. No production logs.
Retry budget: two attempts after the first failure.
Stop if: auth, billing, customer data, schema changes, deployment, or another service appears relevant.
Output: changed files, commands run, why each boundary was enough, checks, rollback note.
That template looks almost too plain. Good. Production controls usually do.
The value is not the wording. The value is forcing the team to choose the boundary before Claude Code starts making the work look easy.
Read access is still access
Teams worry about write access first, which makes sense. A bad patch is visible. A bad inference from too much read access is harder to spot.
If Claude Code can read tickets, logs, incident notes, runbooks, architecture docs, and customer-adjacent data, it can build a story. The story may be right. It may also be a confident collage of context that was never meant to be combined.
I have seen this pattern in financial-services systems without agents. A note from one incident becomes a general rule. A temporary mitigation gets copied into a new change. A dashboard comment is treated as evidence after the person who wrote it has forgotten the caveat. Agents make that drift faster.
So read scope needs the same discipline as edit scope.
A practical rule:
Every read permission needs a named reason.
“The agent wanted more context” is not a reason. “The failing test references PAY-1842, so the agent may read that ticket and its acceptance criteria” is a reason. It gives the reviewer something to check.
This matters even more with MCP. A tool that reads a ticket, a tool that searches docs, and a tool that queries a live system should not be bundled into one friendly label called “context.” They carry different risks.
Hard stops belong in the prompt
“Be careful” is not a control.
A production prompt should name the zones where the agent must stop. My default list is blunt:
Stop before touching:
- authentication or authorization
- billing, payments, or cost controls
- customer data or regulated data
- secrets and credentials
- database migrations or destructive operations
- deployment, infrastructure, or cloud configuration
- external MCP tools outside the task contract
That does not mean Claude Code can never help with those areas. It means crossing into them changes the task. A new task needs a new decision, not a quiet expansion of the current run.
The wording I like is:
If the fix appears to require one of these areas, stop and explain the pressure at the boundary. Do not work around the limit.
That last sentence matters. Helpful agents are very good at working around limits if you leave the goal vague enough. A permission budget tells the agent that reporting the boundary is a successful outcome, not a failure.
The review packet is part of the budget
A permission budget should also say what evidence the run must leave behind.
For Claude Code, I want the final handoff to answer a few simple questions:
What was the task contract?
Which files did the agent read?
Which files did it change?
Which tools or commands ran?
Why was each tool allowed?
What evidence changed the patch?
Which checks passed?
Which checks did not run?
What would be rolled back?
Where did the agent feel boundary pressure?
This is where a lot of agent workflows quietly fail. The diff may be fine, but the path to the diff is foggy. The reviewer sees green tests and a confident explanation, but not the decision trail.
That is expensive. It pushes work onto the human at the worst possible moment, when the team wants to merge and move on.
A clean review packet lowers the cost of saying yes. It also makes it easier to say no without drama. If the run touched a forbidden area, skipped a check, or needed a wider tool, the reviewer can see it quickly.
Increase autonomy only after the loop is visible
There is a decent case for giving Claude Code more autonomy over time. I am not arguing for tiny toy tasks forever.
But the order matters.
Do not widen the lane because the last run looked impressive. Widen it because the last run was reviewable.
Can the team see what the agent read? Can it see why tools were called? Can it tell where the task boundary held? Can it compare cost against evidence gained? Can it roll back the change without a detective story?
If the answer is no, more autonomy will probably create more confusion, not more throughput.
The rule I use is simple:
Increase Claude Code autonomy only after the review loop can explain the previous level of autonomy.
That is slower than the demo culture around coding agents. It is also how teams keep trust after the novelty wears off.
A small permission-budget template
If your team is starting to use Claude Code on real repositories, begin with this version:
Task:
Allowed reads:
Allowed edits:
Forbidden areas:
Allowed commands:
Allowed MCP tools:
Time or token budget:
Retry limit:
Stop-and-ask triggers:
Required evidence:
Rollback note:
Human approval needed before:
Put it next to the prompt. Keep it short. Make the agent repeat the boundary back before it starts if the task is risky.
Then review two things at the end: the patch and the path. Did the code change make sense? Did the run stay inside the budget? You need both answers before the work becomes production work.
For a compact pre-flight version of these controls, use the Claude Code production checklist. For the fuller operating model around permissions, MCP blast radius, evals, observability, review packets, rollback, and team adoption, see Claude Code: From Vibe Coding to Production.