Put agent security before the rollout
The risky moment is not when an AI agent fails in a demo.
The risky moment is when the demo works, people like it, and the team starts widening access before anyone has written down the operating model.
That is how Claude Code moves from one careful engineer to a team habit. It is how an internal assistant gets an MCP server. It is how a retrieval bot starts touching ticket queues, customer records, release notes, policy documents, and workflow tools. Nobody wakes up and decides to build an ungoverned agent platform. They remove one bit of friction at a time.
Then security arrives late and everyone acts surprised that the controls feel bolted on.
This is the reason I am selling these two books together. Claude Code: Building Production Agents That Actually Scale is about the delivery loop around coding agents: task contracts, scoped files, review packets, tests, rollback notes, and human approval. Securing Enterprise AI Agents is about the authority loop around enterprise agents: identity, tool governance, RAG boundaries, MCP security, audit evidence, policy gates, and revocation. If your team has to care about both, the Enterprise AI Agents in Production bundle is the cleanest path.
the rollout should start with authority
Most agent rollouts start with capability.
Can it edit code? Can it answer from internal documents? Can it call the tool? Can it create the ticket? Can it update the record? Can it summarize the meeting and draft the follow-up?
Those are useful questions. They are also incomplete.
The first production question should be about authority: what is this agent allowed to do, under whose identity, for which job, using which tools, with which evidence, until when?
That question sounds like security language. It is also delivery language. A Claude Code run without a clear file scope is hard to review. An enterprise agent without a named identity is hard to audit. An MCP server without method-level boundaries is a production risk wearing a convenience badge.
If the authority model is vague, the agent is not ready for wider rollout. It may still be worth testing. It may still be useful for one trusted user. But it is not ready to become a team dependency.
give Claude Code a smaller box
Claude Code is a good place to learn this discipline because the work is visible.
A coding agent reads files, proposes changes, runs commands, and hands back a patch. That feels familiar because engineers already know how to review code. The trap is that the patch is only the visible artifact. The important question is whether the run stayed inside the box you meant to give it.
For a serious task, I want the box written down before the run starts:
Task contract:
Read scope:
Write scope:
Allowed commands:
Approval triggers:
Expected tests:
Rollback requirement:
After the run, the review packet should show what actually happened. Which files changed? Which commands ran? What failed? Did the agent ask for more permission? Did the human approve a scope change? Which test result proves the risk was covered?
This is not paperwork for its own sake. It is how you keep speed from turning into guesswork.
A smaller box also makes the agent more useful. The prompt gets sharper. The review gets faster. The rollback note is easier to write. The team spends less time arguing about whether the agent was “safe” in the abstract and more time checking whether this specific run stayed inside this specific boundary.
enterprise agents need the same habit
Enterprise agents make the same problem less visible.
The output may be a polished answer, a ticket comment, a recommended decision, a drafted email, a routed exception, or a data lookup. The work can look harmless while the authority behind it is too broad.
That is where security teams should push early. Not by killing every pilot, and not by turning the first version into a compliance project. Push by asking for the minimum control record before the rollout expands:
Agent owner:
Business process:
Data sources:
Tools and MCP methods:
Runtime identity:
Approval gates:
Denied actions logged:
Retention and audit path:
Revocation owner:
Expiry or review date:
If nobody can fill that in, the agent is still an experiment. That is fine. Call it an experiment. Do not sell it internally as production-ready.
The pattern is the same as Claude Code. Narrow the job. Name the authority. Record the run. Review the evidence. Keep a way back.
do one hard check before widening access
Before you give an agent to another team, another repo, another data source, or another tool, run one check.
Ask a senior engineer, platform owner, security lead, or incident responder to answer this from the record:
Why was the agent allowed to do what it just did?
No Slack archaeology. No asking the person who ran the pilot. No “we think it only had read access”. Answer from the system of record.
If the team can answer, you have the start of an operating model. If the team cannot answer, you have a useful demo with a missing control layer.
That missing layer is cheaper to add before rollout than after people depend on the agent. Once the agent is embedded in delivery, every new control feels like a slowdown. Before rollout, it is just the shape of the product.
buy the operating model before you need it
If your immediate problem is Claude Code in real repositories, start with Claude Code: Building Production Agents That Actually Scale. Kindle readers can buy it on Amazon here: Claude Code on Amazon Kindle.
If your main problem is delegated authority, MCP security, RAG governance, agent identity, policy gates, audit trails, and regulatory pressure, read Securing Enterprise AI Agents or get it directly on Leanpub.
If your team owns both the coding-agent rollout and the enterprise control model, get the Enterprise AI Agents in Production bundle. One book helps the agent produce reviewable work. The other helps the organization prove the agent had bounded authority while doing it.