Treat agent autonomy like a production privilege

The wrong way to discuss agent autonomy is to ask, “How much can we let the model do?”

That question is too loose for production work. It turns autonomy into a personality test for the model. The model seems careful, so it gets more access. The demo works, so the tool list grows. A few good runs later, nobody remembers which boundary moved first.

A better question is dull and much safer: “Which production privilege does this task deserve?”

That framing changes the work. Claude Code no longer gets broad repository freedom because it produced a good patch yesterday. An enterprise assistant does not get action access across business systems because the answer quality improved. Each run gets a scoped privilege, a reason, an expiry point, evidence, and a way to stop.

autonomy is a grant, not a vibe

Teams often treat autonomy as a mood.

This agent feels safe. That workflow feels risky. This repo is probably fine. That MCP server looks dangerous. Those instincts are useful at the start, but they do not survive contact with shared systems, tired reviewers, incident pressure, and the normal drift of successful tools.

Production teams need a grant model instead.

A grant says what the agent may do for this run:

actor: Claude Code or enterprise agent
purpose: the task it was delegated
scope: files, data, systems, and tools allowed
blocked scope: places it must not touch
approval: actions that need a human
expiry: when the grant ends
evidence: logs, commands, diffs, tool calls, checks, and rollback notes
owner: the person accountable for the grant

That sounds formal, but it can be lightweight. A task contract in a Claude Code prompt can carry the same idea. So can a policy wrapper around an MCP tool. So can a review packet at the end of the run.

The important part is that autonomy becomes something visible. People can inspect it, narrow it, revoke it, and learn from it.

Claude Code should earn scope per task

Claude Code is most useful when the task is narrow enough to review and real enough to matter.

That is the sweet spot: one bounded change, clear files, explicit commands, a review packet, and a rollback note. The agent can move quickly inside that fence. If it needs a wider fence, it should stop and say so.

A practical task contract might look like this:

Work only in src/billing/reconciliation and tests for that module.
Do not edit auth, migrations, deployment config, or shared payment abstractions.
If the fix needs one of those areas, stop and explain why.
Run the focused tests and report anything skipped.
Return a review packet with changed files, commands, risks, and rollback.

That small contract does a lot of work. It gives the agent enough room to help. It gives the reviewer a claim to verify. It also prevents a common failure pattern: a clean looking patch that quietly changed the blast radius.

The point is not to make Claude Code timid. The point is to make speed reviewable.

enterprise agents need the same treatment around tools

The same pattern applies outside the repository.

An enterprise agent may answer questions, call MCP tools, update records, route tickets, draft customer responses, query internal documents, or trigger workflows. The risky part is often not the text it returns. The risky part is the authority behind the answer.

Before expanding tool access, ask what privilege the agent is receiving:

Can it read customer data?
Can it write to systems of record?
Can it call external tools?
Can it combine data from separate domains?
Can it act without a human approval step?
Can it keep access after the run ends?

If those answers are vague, the rollout is not ready for more autonomy. A better prompt will not fix an invisible permission model.

This is where agent security becomes operational. You need identity, tool governance, logs, approval gates, revocation, and incident handling. Otherwise, you are asking people to trust a system they cannot inspect when it matters.

a simple autonomy review before the next rollout

Before the next agent rollout or Claude Code workflow expansion, take one hour and review three recent runs.

For each one, write down the grant the agent actually had. Do not write the grant you wish it had. Write the real one.

What could the agent read?
What could it change?
Which tools could it call?
Which checks ran?
Which approval happened before action?
When did access expire?
Where is the evidence?
How would we reverse a bad run?

The uncomfortable parts are the useful parts. Maybe the agent had access to a whole repo for a change that needed two files. Maybe an MCP tool allowed broad reads because nobody narrowed the policy. Maybe the run produced a good output, but the logs would be useless during an incident.

That is not a reason to stop using agents. It is a reason to give autonomy a shape before it grows by accident.

two books for the same production problem

I wrote the two books because delivery and security keep meeting in the same place.

Claude Code: Building Production Agents That Actually Scale is for the engineering side of that problem: task contracts, scoped edits, review packets, evals, observability, rollback, cost controls, and human approval. If you want Claude Code to work inside real repositories without turning every review into archaeology, start there.

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

Securing Enterprise AI Agents is for the authority side: identity, MCP boundaries, RAG governance, policy gates, audit evidence, incident response, and revocation. If the agent can act across business systems, this is the book for the control model around that action.

If your team owns both the delivery path and the risk path, the Enterprise AI Agents in Production bundle is the cleaner starting point.

The practical rule is simple: do not give an agent autonomy you cannot describe, review, and revoke.

If the privilege is visible, the team can move faster without pretending the boundary does not matter.