Before the agent gets more access, write the review path

The pressure usually arrives quietly.

A coding agent did a useful job, so someone wants to let it touch more of the repository. An internal agent answered a support question well, so someone wants it to update the ticket next time. A workflow agent saved an hour, so the team wants to connect another tool.

That is the moment to slow down. Not because the agent is bad. Because useful agents attract permissions, and permissions change the kind of system you are running.

Before the agent gets more access, write the review path.

Access changes the job

A Claude Code session that can read three files and propose a patch is one thing. A session that can edit across the repository, run shell commands, update configuration, and open a pull request is another thing.

The same is true outside the codebase. An enterprise agent that summarizes a policy page is one thing. An agent that can call MCP tools, query customer data, write to a CRM, open tickets, or trigger a workflow is a different system.

The dangerous habit is treating both versions as the same agent with a bigger prompt.

The prompt still matters. I use tight task instructions all the time. But the prompt is not where access should be approved. A permission change needs a review path that a tired human can follow when the work is finished and something feels slightly off.

The review path is four questions

I like to keep this boring. If the review path becomes a governance theatre document, nobody will use it.

Start with four questions:

What task did we approve?
What authority did the agent receive?
What evidence did it return?
Who can approve, reject, or roll back the result?

Those four questions work for Claude Code. They also work for enterprise agents.

For Claude Code, the authority might be scoped files, commands, network access, branch permissions, test execution, and whether the agent can create a pull request. The evidence might be a review packet: changed files, inspected files, commands run, test output, known gaps, risk, and rollback path.

For an enterprise agent, the authority might be identity, data scope, MCP method access, action limits, approval gates, logging, and revocation. The evidence might be a run record: data sources read, tools called, actions taken, approvals requested, approvals skipped, and links to logs.

Different surface. Same discipline.

More autonomy should leave more evidence

A weak rollout does the opposite. The agent gets more access while the evidence stays vague.

You see summaries like this:

Updated the implementation and ran the tests.

That is not enough when the agent had broad authority. Which implementation? Which files? Which tests? What failed first? What did it inspect but leave unchanged? Did it touch configuration? Did it call a tool with wider reach than the task required? What is the rollback path?

For enterprise agents, the vague version is worse:

Processed the customer request successfully.

That hides the part a reviewer actually needs. Which customer data did it read? Which system did it update? Which identity did it use? Which policy allowed the action? Where is the log? What happens if the action was wrong?

Autonomy without evidence is just a faster way to lose the plot.

Claude Code is a good place to practise this

Claude Code makes the review path visible because the work usually lands as a diff.

Before giving the agent more room, ask it to return a packet like this:

Approved task:
Files allowed:
Files changed:
Files inspected but not changed:
Commands run:
Test results:
Evidence missing:
Risk left behind:
Rollback path:
Human review focus:

That packet does two useful things. It helps the reviewer inspect the work, and it forces the team to notice when the agent has quietly outgrown the original task.

This is the operating style behind Claude Code: Building Production Agents That Actually Scale. The book is for teams that want Claude Code to be more than an impressive demo. It covers task contracts, scoped edits, review packets, evals, observability, rollback-first prompts, cost control, and human approval.

Kindle readers can get it here: Claude Code on Amazon Kindle.

Enterprise agents need the same habit with stricter boundaries

The enterprise version has a wider blast radius because the diff may be hidden behind a workflow.

An agent might answer in plain English while calling tools that touch regulated data, internal records, support workflows, finance-adjacent processes, or customer systems. The output can look harmless while the authority behind it is not.

So the review path needs to include the control surface:

Agent identity:
Business owner:
Data sources allowed:
MCP methods allowed:
Actions allowed without approval:
Actions requiring approval:
Audit log location:
Revocation path:
Incident owner:

If those fields feel too heavy, the agent probably should not have the extra access yet. The answer is not to block the work forever. The answer is to keep the authority narrow until the review path catches up.

That is the core of Securing Enterprise AI Agents: identity, MCP boundaries, RAG governance, policy gates, audit evidence, incident response, and revocation. If an agent can act across enterprise systems, security is not a side review at the end. It is part of the product design.

LeanPub readers can get it here: Securing Enterprise AI Agents on LeanPub.

The useful rule

Do not ask, “Can the agent handle more access?” as a yes-or-no question.

Ask this instead:

If this agent uses the new access badly, can a human see what happened, stop the next run, and undo the damage?

If the answer is yes, you have something worth scaling. If the answer is no, you do not need a longer prompt. You need a clearer review path.

Teams that own both sides can treat this as one operating model. Claude Code needs reviewable delivery. Enterprise agents need bounded authority. The Enterprise AI Agents in Production bundle puts those two problems next to each other: one book for agentic coding in a real engineering loop, one book for securing agents that act across enterprise systems.

The agent can get more access. Just make the path back to human judgment obvious before it does.