Permission changes are releases

The first version of an agent is rarely the dangerous one.

The dangerous version is the one that grows quietly.

It starts with a useful Claude Code workflow that can read a repo and suggest a patch. Then someone adds a broader file scope. Then a command gets allowed because the engineer is tired of approving it. Then an MCP server appears because it saves time. In the enterprise version of the same story, a read-only assistant gets a ticket queue, then a customer data source, then a workflow tool, then a write path that nobody calls a write path in the rollout meeting.

That is how agent authority expands. Not in one dramatic decision. One helpful exception at a time.

This is the practical overlap between the two books I am advertising. Claude Code: Building Production Agents That Actually Scale is about keeping coding-agent work reviewable: task contracts, scoped changes, tests, review packets, and rollback notes. Securing Enterprise AI Agents is about keeping delegated authority governable: identity, MCP controls, RAG boundaries, policy gates, audit evidence, and revocation. If your team owns both problems, the Enterprise AI Agents in Production bundle gives you the shared operating model.

The permission change is the risk event

Most teams review the first agent carefully. They look at the prompt, the model, the tool list, the pilot group, and the demo path.

Then the real work begins, and the control gets softer.

A developer asks Claude Code to touch one more directory. A platform engineer adds another MCP method. A security exception becomes a normal setting. A product owner asks the agent to update tickets instead of drafting comments. An internal assistant gets access to a second knowledge base because the first one was useful.

Each change feels small. That is exactly why it needs a release habit.

The question is not “can the agent do this?” The question is:

What new authority does this permission create, and how will we prove it stayed inside the boundary?

If nobody can answer that, the permission is not ready.

Claude Code makes the pattern visible

Claude Code is a clean place to learn this because the permission boundary is usually concrete.

Can the agent read this directory? Can it edit generated files? Can it run migrations? Can it call a local tool? Can it touch authentication code? Can it update tests only, or production code too?

Those choices change the shape of the run. They also change the review burden.

A small documentation fix does not need the same gate as a change to payment logic. A refactor inside one module does not need the same evidence as a task that edits CI, secrets handling, or deployment scripts. If the agent gets permission to run commands that mutate state, the reviewer needs more than a cheerful summary.

For Claude Code work, I would record permission changes in the task contract before the run starts:

New permission requested:
Why it is needed:
Files or tools affected:
Allowed commands:
Denied commands:
Expected tests:
Approval owner:
Rollback note:
Expiry or review date:

That template looks boring. Good. Boring is what you want when an agent is about to change real code.

Enterprise agents hide the same problem

Enterprise AI agents make permission changes harder to see.

A new data source can look like better retrieval. It may also cross a confidentiality boundary. A new MCP method can look like a productivity improvement. It may also turn a safe answer bot into an action-taking system. A shared service identity can look easier to operate. It may also make audit trails vague enough to be useless during an incident.

This is where agent security has to be practical. Do not wait until the rollout is large enough to need a committee. Ask for a permission-change record while the agent is still small enough to fix.

For an enterprise agent, I would want this before widening access:

Permission being added:
Business reason:
Agent identity:
Data classification:
Tool or MCP method:
Read or write impact:
Approval gate:
Telemetry required:
Revocation path:
Review date:

The point is not to slow every pilot down. The point is to stop quiet authority creep. If the agent needs more power, fine. Name it, test it, approve it, observe it, and keep a way back.

Test the bad run before you celebrate the good one

A lot of agent demos prove the happy path. That is not enough for a permission change.

Before a new permission goes live, run the boring negative checks:

• ask the agent to do something just outside scope
• ask it to use the wrong tool
• ask it to retrieve data it should not need
• ask it to continue after the approval boundary
• ask it to act when the runtime identity lacks the right authority
• ask it to explain what it did from the logs alone

Those checks are not theatre. They tell you whether the boundary is real or just written in a prompt.

This matters even more in regulated environments. I have spent enough time around financial-services systems to know that the incident review will not care that the demo looked responsible. It will ask who approved the authority, what the agent could reach, what evidence was retained, and how quickly the team could revoke access.

Build that answer before the permission goes live.

Buy the operating model if this keeps coming up

If your team is putting Claude Code into real repositories, start with Claude Code: Building Production Agents That Actually Scale. Kindle readers can buy it here: Claude Code on Amazon Kindle.

If your team is rolling out enterprise agents with MCP tools, RAG, delegated authority, audit expectations, and policy gates, read Securing Enterprise AI Agents or get it directly on Leanpub.

If the same group owns coding-agent delivery and enterprise-agent security, get the Enterprise AI Agents in Production bundle. Permission changes are where speed and governance meet. Treat them like releases before they become incidents.