Claude Code permissions should fail closed

The dangerous Claude Code run rarely starts with something dramatic.

It starts with a reasonable task. Fix the flaky export. Update the migration. Trace why the invoice job is timing out. Then the agent asks for one more file, one more command, one more MCP tool, one more bit of context from a system the team did not mean to include.

That moment is the real permission design.

If the answer is “sure, whatever helps”, the team has not given Claude Code a permission model. It has given the agent a polite suggestion.

For production work, I want Claude Code permissions to fail closed. When the run needs something outside the contract, it should stop, explain the pressure, and wait for a human decision. No quiet widening. No rummaging through adjacent systems because the next clue might be there.

That sounds strict until you have to reconstruct a bad run.

A permission prompt is not a security boundary by itself

A prompt can help. It is not enough on its own.

If you tell Claude Code “do not touch billing” but also expose a broad MCP server with billing tools, you have built a control that depends on the model remembering your intent at the exact moment the task becomes difficult.

That is too much faith for a production system.

The better pattern is boring:

Allowed reads: src/payments/exporter, tests/payments/exporter, ticket PAY-1842
Allowed edits: src/payments/exporter and tests/payments/exporter only
Allowed commands: npm test -- payments/exporter
Allowed tools: read-only ticket lookup
Stop before accessing billing config, customer data, deploy tools, migrations,
secrets, incident notes, or any MCP tool outside the list.

The prompt names the boundary. The tool layer should enforce as much of it as possible. The review packet then records whether the run pressed against the boundary.

That last part matters. If Claude Code never reports boundary pressure, reviewers have no way to learn where the system is brittle.

Treat MCP as blast radius, not convenience

MCP makes Claude Code useful because it connects the agent to the work: tickets, docs, logs, test systems, repo tools, and internal workflows.

It also changes the blast radius.

A docs lookup is not the same risk as a live database query. A read-only ticket tool is not the same as a tool that can change issue state. A local test command is not the same as a deployment command. The model may treat all of them as steps toward a solution. Your permission design should not.

I like separating tools into three buckets:

• Safe by default: local reads, local tests, docs search, scoped ticket reads.
• Needs explicit approval: wider repo reads, generated migrations, logs with customer context, non-standard commands.
• Usually blocked in coding runs: production data, secrets, billing controls, deploys, account changes, write-capable operational tools.

Those buckets will vary by team. The important bit is that they exist before the run starts.

The stop is part of the workflow

A lot of teams treat agent pauses as friction. I think that is backwards.

When Claude Code stops and says, “The fix may require billing config, which is outside scope”, the workflow is working. The task has changed. A human needs to decide whether to widen the run, split the task, or bring in someone who owns that system.

That is the same instinct I trust from financial-services engineering: controls are useful when they interrupt the exact shortcut that feels reasonable under pressure.

A fail-closed pause should capture four things:

Boundary hit: what the agent tried to access or infer
Why it matters: the production or customer risk
Options: continue with approval, narrow the task, or stop
Evidence so far: what the agent has proved without crossing the line

This turns a permission denial into a decision record. It also gives reviewers better signal than a neat end-of-run summary that says everything stayed in scope.

Reviewers need to read the permission story

When a Claude Code pull request arrives, reviewers should not look only at the diff and test output.

They should ask:

• What permissions did the run start with?
• Which files and tools did it actually use?
• Did the agent ask for anything outside the contract?
• Were any MCP tools available that were not needed for the task?
• Did the evidence prove the change without relying on hidden context?
• Is there a rollback note if the permission decision was wrong?

That may feel heavier than normal code review, but only because normal code review often hides the path to the patch. With agents, the path matters. A small diff can come from a messy run, and a messy run can teach you where your permission model is weak.

Start narrower than feels comfortable

The first team-wide Claude Code setup should be deliberately underpowered.

Give it the smallest useful toolset. Make the first few runs earn wider access. Watch where engineers keep asking for exceptions. Turn repeated exceptions into named workflows with owners, logging, and review.

Do not begin with a heroic agent that can see half the company and then try to add governance later. That is how teams end up with impressive demos and nervous production meetings.

A safer adoption path looks like this:

small scoped run -> boundary log -> review packet -> policy adjustment -> wider run

The loop is slower at first. It gets faster because the team learns which permissions are genuinely useful and which ones just make the agent look smarter while making the system harder to trust.

Make permission pressure visible

If your team is already using Claude Code, add one field to the review packet this week:

Permission pressure:
What did the agent need that was outside the original task contract?
What did it do when that happened?

That field will tell you more than another broad debate about whether coding agents are safe. You will see the actual pressure points in your repo, your tools, and your process.

The free Claude Code production checklist covers the larger operating loop: permissions, MCP tool access, evals, observability, review packets, and rollback.

For the full system, I wrote the Claude Code book for teams moving past solo experiments and into repeatable production use. The landing page points to the Amazon Kindle edition as the main purchase option.