Claude Code permissions should have a budget

The risky Claude Code setup is rarely dramatic.

It starts with a sensible task. Fix this test. Refactor this module. Add a small endpoint. Then the agent asks for one more permission, one more file, one more shell command, one more MCP tool. Each request feels reasonable in isolation.

That is how the blast radius grows.

I do not think teams should respond by banning agentic coding. That would be a waste. Claude Code is useful because it can hold context, edit across files, run tests, and produce a reviewable patch. The problem is letting that usefulness turn into open-ended authority.

A better pattern is to give each run a permission budget.

What a permission budget means

A permission budget is the operating envelope for one agent run.

It says:

• which files or directories the agent may touch
• which tools it may call
• which MCP servers are allowed for this task
• how much time and token spend is acceptable
• which commands are safe without approval
• when the run must stop and ask for a human decision
• what evidence must appear in the final review packet

This sounds boring. Good. Boring is what you want near production code.

The important shift is that permission is no longer a vague yes or no. It becomes a bounded resource, like CPU, cloud spend, deploy access, or database write privileges.

Start with scope, not trust

A lot of agent safety conversations start with trust. Do we trust the model? Do we trust the tool? Do we trust the developer who launched it?

I prefer a plainer question: what can this run actually change?

For a normal bug fix, the answer might be one package, one test folder, and one config file. For a dependency upgrade, it might include lockfiles and CI config. For a migration, the scope can be wider, but it should be named before the agent starts.

Claude Code can still read enough context to understand the task, but write access should be tighter than read access. A run that can inspect the whole repo does not automatically need permission to edit the whole repo.

That distinction matters once MCP enters the picture. A file edit is one kind of risk. A tool that can create tickets, query internal systems, update infrastructure, or touch customer data is another.

MCP tools need a separate allowance

MCP servers make agent workflows powerful. They also make the permission story easier to get wrong.

A coding agent with local file access can make a bad patch. A coding agent with the wrong MCP tools can make a bad patch and change the surrounding world.

So I would not give a run a generic “MCP allowed” flag. I would name the allowed servers and actions:

The first column is not harmless, but it is easier to review. The second column may be valid in mature systems, but it needs a harder approval gate.

If a team cannot explain why a run needs a tool, the tool should not be in the budget.

Spend limits are safety limits too

Cost loops are easy to treat as a finance problem. They are also an engineering signal.

A Claude Code run that burns through too many tokens, retries the same failing test, or keeps widening its plan is telling you something. Maybe the task is underspecified. Maybe the codebase has hidden coupling. Maybe the agent is stuck and is now improvising.

Put a ceiling on that.

For example:

• stop after two failed attempts at the same test
• stop after a named token or time budget
• stop before editing files outside the approved scope
• stop before adding a new dependency
• stop before changing public API behavior
• stop before touching auth, payments, infrastructure, or data deletion code

A stop rule is not a sign the agent failed. It is how the team keeps control of the work.

I learned this lesson the hard way in normal engineering long before coding agents arrived. The dangerous work is often the work that keeps feeling “nearly done” while it eats the afternoon and quietly changes shape. Agents just make that loop faster.

The review packet is part of the budget

A permission budget should also say what the agent owes the reviewer at the end.

For a production-minded Claude Code run, I want the review packet to include:

1. files changed and why
2. commands run
3. tests run and results
4. risks or assumptions
5. behavior changes
6. rollback plan
7. anything the agent wanted to do but did not have permission to do

That last item is useful. If the agent wanted broader access, the reviewer should see the request after the patch, not discover the widened scope later in the diff.

This connects to the production checklist idea: the output is code plus evidence. If you want a compact version of that operating model, I keep one here: Claude Code production checklist.

A simple permission budget template

Here is a starter template I would put into a team prompt or runbook.

Task:
- one sentence describing the intended change

Allowed write scope:
- list files/directories the agent may edit

Allowed read scope:
- list repo areas, docs, tickets, or logs the agent may inspect

Allowed tools:
- shell commands allowed without approval
- MCP servers/actions allowed for this task

Stop and ask before:
- new dependencies
- schema changes
- auth/payment/security changes
- production data access
- infrastructure changes
- repeated failing attempts

Evidence required:
- summary of changes
- test commands and results
- known risks
- rollback note

The exact template matters less than the habit. Name the boundary before the run starts. Review the evidence after it ends.

Teams need different budgets for different work

One budget will not fit every task.

A documentation cleanup can have a wider file scope and a lighter test requirement. A payment flow change should have narrow write access, stronger human review, and a rollback note. A refactor in a shared library should include dependency checks and downstream tests. A security-sensitive change should probably split discovery, patching, and approval into separate runs.

This is where Claude Code becomes a team practice rather than a solo productivity trick.

The question is not “Can the agent do it?” The better question is “What budget would make this safe enough to attempt?”

The sales pitch for discipline

Permission budgets slow the first run down a little.

They speed everything after that up.

Reviewers get smaller diffs. Teams get fewer surprise changes. Cost loops become visible earlier. MCP tools stop feeling like a magic bag of side effects. New joiners learn how the team uses agents without copying one person’s habits from a terminal scrollback.

That is the kind of Claude Code adoption I trust: useful, bounded, observable, and easy to reverse.

If you are trying to move from impressive demos to production-ready Claude Code workflows, I wrote the field guide for exactly that problem: Claude Code: From Vibe Coding to Production. The Kindle edition is live on Amazon, and the book is built around the operating patterns teams need after the demo works.