Agentic coding is also a security decision

A Claude Code rollout usually starts with delivery pressure.

Someone wants tests written faster. Someone wants a gnarly refactor broken into smaller patches. Someone wants the agent to inspect a repo, call a tool, explain the failure, and get a pull request into review before the afternoon disappears.

That is reasonable. I like tools that remove boring work. But the moment an agent can read a repo, call MCP tools, run commands, write code, and produce evidence for a reviewer, the question is no longer only “does this help engineering move faster?”

The question becomes: “what authority did we just delegate, and can we prove it was used safely?”

That is where Thomas De Vos’s two AI agent books fit together. Claude Code: Building Production Agents That Actually Scale is about the engineering operating loop. Securing Enterprise AI Agents is about the control model around that loop. If your team is moving from demos into real work, you probably need both views.

Production agent delivery and security control loop

The delivery loop is not enough

A good Claude Code workflow has a shape to it:

Task contract
Scoped files and tools
Patch
Targeted tests
Review packet
Rollback note
Human approval

That sounds like engineering discipline, and it is. It keeps the agent from wandering through a repo with a broad instruction and a lot of confidence. It gives the reviewer something better than a cheerful summary. It makes the work repeatable.

But there is a second loop sitting beside it:

Identity
Permissions
MCP boundaries
Data exposure
Policy gates
Audit evidence
Incident response
Kill switch

That second loop is the security decision. It decides what the agent may touch, which tools it can call, which data it can see, who owns the risk, and what happens when the agent crosses the line by accident.

If the delivery loop runs without the security loop, you get fast patches with unclear authority. If the security loop runs without the delivery loop, you get policy documents that do not match how engineers actually work. Production agents need the two loops to meet.

Claude Code turns prompts into authority

A prompt can look harmless:

Fix the customer sync issue and update the tests.

Inside a real codebase, that prompt can imply a lot. The agent may need to inspect logs, read tickets, call an MCP server, run a test command, edit code, update config, or summarize customer impact. None of that is automatically bad. It just needs a boundary.

A production prompt should be closer to this:

Investigate customer sync failures for EU accounts.
Allowed reads: sync worker, sync tests, ticket PAY-4317, and error examples pasted below.
Allowed edits: sync worker and sync tests only.
Allowed commands: targeted unit tests and lint for this package.
Blocked: production data, migrations, queue configuration, secrets, deploy config, and write capable MCP tools.
Stop if: the fix needs a schema change, live customer examples, or a wider service boundary.
Evidence required: failing test, passing targeted tests, files changed, assumptions, residual risk, and rollback note.

That prompt is longer because the task is no longer just a request. It is a delegation. It says what Claude Code may do on behalf of the human, and where the human has to take back control.

The Claude Code book goes deep on this operating model: task contracts, scoped permissions, hooks, evals, observability, review packets, cost controls, and rollback. The point is not to make the agent timid. The point is to make the work inspectable.

MCP makes the security question sharper

MCP is useful because it gives agents access to real context and real tools. It is also where a coding assistant starts to behave more like a business system.

A repo-only agent can make a bad patch. An agent with MCP access might read tickets, browse internal docs, query observability, inspect build systems, open pull requests, or touch workflow tools. That can be exactly what the team needs. It can also turn a narrow coding task into a permissions problem.

For every MCP server, ask one blunt question:

What business capability does this give the agent?

Do not stop at “read Jira” or “query logs.” Say what the tool really exposes. Customer escalation detail. Incident context. Payment workflow state. Deployment evidence. Production-like telemetry. The risk is not the connector name. The risk is the authority behind it.

This is where Securing Enterprise AI Agents becomes relevant for engineering teams, not only security teams. The book covers delegated authority, AgentSecOps, identity, RAG governance, MCP control, audit evidence, and policy gates. Those topics sound formal until an agent run touches regulated context or a reviewer asks who approved a tool call.

Review packets should satisfy engineering and security

A review packet that only says “tests pass” is too thin for production agent work.

For Claude Code, the reviewer needs engineering evidence:

Original task
Files inspected
Files changed
Diff summary
Commands run
Tests added or updated
Test results
Known gaps
Rollback note

Security and risk need a few more things:

Delegating user
Agent identity
Permissions used
MCP tools called
Sensitive actions denied
Data boundaries touched
Approvals requested
Residual risk owner
Incident or rollback trigger

You do not need a heavy process for every small task. A docs typo does not need an incident model. But once the agent touches production-adjacent code, regulated data, workflow automation, or write capable tools, the review packet becomes evidence.

That evidence protects the team later. If a change causes trouble, nobody wants to reconstruct the run from memory and vibes. They want to know what the agent saw, what it changed, what it assumed, which tools it used, and how the reviewer decided to accept the risk.

The buying decision is really a rollout decision

If your team is experimenting with Claude Code on personal branches, start with the delivery loop. Learn how to write task contracts. Keep tool access narrow. Ask for review packets. Make rollback part of the prompt before the agent writes code.

If your team is rolling agents into shared repositories, internal tools, regulated workflows, or customer-adjacent systems, add the security loop now. Do not wait until the first scary run. Decide how identity, permissions, MCP boundaries, audit evidence, and incident response work while the blast radius is still small.

The two books split that problem cleanly:

Fast agents are useful. Fast agents with unclear authority are expensive later. Build the delivery loop, secure the authority around it, and make every serious run leave enough evidence that another human can trust the result.