No approval, no autonomy

A production AI agent stops being a helper once it can act.

If it can read internal data, call tools, change code, open tickets, modify records, or trigger workflows, the team has delegated authority to software. The interface may still look like chat. The risk no longer behaves like chat.

That is why I like a blunt rule for agent rollouts: no approval, no autonomy.

I do not mean a heavyweight committee for every run. I mean a small approval packet that exists before the agent moves from suggestion to action. It should explain who owns the agent, what job it may do, which tools it can call, what needs a human, where the audit trail lives, and when the permission expires.

This is the bridge between the two books I am selling now. Claude Code: Building Production Agents That Actually Scale is about the delivery loop: task contracts, scoped files, evals, review packets, rollback notes, and human approval around coding agents. Securing Enterprise AI Agents is about the control loop: identity, delegated permissions, MCP boundaries, RAG governance, audit evidence, policy gates, and incident readiness. If your team owns both sides, the Enterprise AI Agents in Production bundle is the cleaner starting point.

Autonomy starts before the first action

Teams often talk about autonomy as if it begins when the agent presses the button.

That is too late.

Autonomy begins when the team decides the agent is allowed to press the button at all. It begins when a tool is connected, a token is issued, a file path is exposed, a retrieval source is added, or a workflow endpoint becomes callable.

A Claude Code run that can edit a repo has already crossed a boundary. An enterprise support agent that can read customer records has crossed one too. An MCP-backed agent that can call internal tools has crossed another. None of those decisions are inherently wrong. They just need an approval record strong enough to survive review.

The risky version is familiar. The agent starts as a demo. Someone connects one useful tool. Then another. Then a broader credential. Then a convenience exception because the pilot is moving fast. By the time security asks what the agent can do, the answer is a pile of Slack messages, local config, and assumptions.

That is not an operating model. That is archaeology.

The approval packet should be small enough to use

The packet does not need to be a novel. If it is too long, nobody will update it and nobody will read it during an incident.

For most agent workflows, I want these fields visible before the agent acts:

Agent owner:
Business or engineering job:
Allowed data sources:
Allowed tools and methods:
Allowed write actions:
Actions that require human approval:
Identity used by the agent:
Run record location:
Expiry or review date:
Rollback owner and rollback path:

That is enough to change the conversation.

Instead of asking, “Do we trust the agent?” you ask, “Do we approve this agent, under this identity, for this job, with these tools, until this expiry point?”

That second question is less glamorous. It is also answerable.

Claude Code needs this at run level

For Claude Code, the approval packet can live close to the work. It belongs in the task contract, the pull request description, or the review packet that accompanies the diff.

A useful Claude Code approval record says what the agent was asked to do, which files it could read or change, which commands it could run, which permissions changed during the run, which tests passed, what the reviewer should look at, and how to roll back the change.

Attach approval to the run, not to a vague belief that the tool is safe.

A documentation cleanup should not inherit the same permission shape as a migration. A refactor should not inherit debug access from yesterday. A one-off shell command should not quietly become normal. Approval has to match the job in front of the agent.

This is where many teams get Claude Code wrong. They focus on whether the prompt is good enough. The prompt matters, but the approval boundary matters more. A good prompt inside an over-broad environment is still an over-broad environment.

Enterprise agents need this at system level

Enterprise agents need the same habit, but the packet usually lives at a higher level. The question is not only what happened in one run. It is whether the agent has standing authority to act inside a business process.

If the agent can retrieve internal knowledge, call an MCP server, open a ticket, approve a request, update a record, or send a message to a customer, you need system-level evidence. Who owns it. What data it can see. Which tool calls are allowed. Which actions need a person. How logs are retained. How the team revokes access. What happens when the agent is wrong.

This is where security teams are useful when they arrive early. Not as the department of no, but as the people who force the authority model into daylight.

The worst pattern is letting the pilot become production by drift. The best pattern is boring: named owner, scoped identity, clear tools, approval gates, logs, expiry, and rollback.

Boring wins during incident review.

The one-minute auditor test

Here is the test I would use before expanding an agent rollout.

If an auditor, incident responder, or senior engineer asks, “Why was this agent allowed to do that?” can you answer in one minute from the system of record?

Not from memory. Not from a chat thread. Not from the person who happened to configure it three months ago.

From the record.

If the answer is yes, you have the beginning of a control loop. If the answer is no, the agent may still be useful, but the organization cannot explain the authority it gave away.

That is the buying problem behind both books. Teams do not need more hype about agents. They need a way to make agent work reviewable, governable, and reversible without killing the speed that made the agent attractive in the first place.

Start with one workflow

Pick one agent workflow you actually want to scale. Do not start with the platform strategy. Start with the next workflow that will touch real code, real data, or a real business process.

Write the approval packet for that workflow. Keep it short. Make the owner, scope, tools, human gates, audit trail, expiry, and rollback visible. Then run the agent only inside that boundary.

If your immediate problem is getting Claude Code work through review without guesswork, read Claude Code: Building Production Agents That Actually Scale. Kindle readers can go straight to Amazon: get the Claude Code book on Amazon Kindle.

If your immediate problem is delegated authority, identity, MCP security, RAG governance, audit trails, and policy gates, read Securing Enterprise AI Agents or get it directly on Leanpub.

If you own both the delivery loop and the control loop, get the Enterprise AI Agents in Production bundle. One book helps you make the agent useful. The other helps you prove the authority around it was deliberate.