Treat the agent budget as a security budget
Every serious agent run has a budget, even when nobody calls it that.
A developer gives Claude Code a task. The prompt limits the files, the tools, the commands, the time, the patch size, the test scope, and the review evidence. A security architect may describe the same run with different words: identity, delegated authority, data exposure, MCP capability, approval gates, audit trail, and rollback ownership.
Those are not two budgets. They are one budget seen from two sides.
That is the practical reason to read Thomas De Vos’s two books together. Claude Code: Building Production Agents That Actually Scale explains how to run Claude Code inside real engineering work. The Kindle edition is available from the book page, with LeanPub as a secondary format. Securing Enterprise AI Agents explains how to put boundaries around agent authority. The Enterprise AI Agents in Production bundle is for teams that need the delivery loop and the control loop in the same operating model.
The budget starts before the prompt
A bad agent run often starts with a vague instruction:
Fix the onboarding bug and clean up anything related.
That sounds efficient. It is also a blank cheque.
The agent may inspect code outside the bug, run commands that change local state, follow a dependency trail into another service, touch configuration, or make a tidy refactor nobody asked for. It may still produce a patch that looks useful. The problem is that the team cannot easily say what authority it spent to get there.
A better run starts with a budget:
Task: fix the onboarding retry bug.
Allowed reads: onboarding service, retry tests, pasted error trace.
Allowed edits: onboarding service and retry tests only.
Allowed commands: targeted unit tests for this package.
Blocked: secrets, migrations, deploy config, production data, write capable MCP tools.
Evidence required: failing test, passing test output, files changed, assumptions, rollback note.
Stop if: the fix needs schema changes, customer examples, or another service boundary.
This is still an engineering prompt. It is also a security control.
The budget tells Claude Code where the work lives, what it can spend, and where the human has to take back control. It turns a broad request into a bounded delegation.
MCP spends budget faster than teams expect
MCP is where the budget metaphor becomes uncomfortable.
A repo-only coding agent can still cause damage, but the blast radius usually appears in the diff. Once MCP tools enter the run, the agent may reach ticket systems, observability, internal docs, build tools, cloud resources, policy systems, or workflow automation.
The connector name is rarely enough. “Read Jira” might include customer escalation detail. “Query logs” might include production-like telemetry. “Search docs” might expose architecture decisions and incident notes. “Open PR” might put the agent one step away from CI and release flow.
For each tool, ask two questions before the run starts:
What business capability does this give the agent?
How much of today's task budget should it be allowed to spend?
Some tools should be cheap. Reading a narrow public API spec may be fine. Some should be expensive. Anything that touches customer context, regulated workflows, auth, payments, production data, deployment paths, or write capable systems should require a named reason and a visible receipt.
The point is not to make agents useless. The point is to stop pretending that every tool call has the same price.
Review packets are the receipt
If the agent spends authority, the review packet is the receipt.
For small work, that receipt can be light:
Task
Files changed
Tests run
Known gaps
Rollback note
For production-adjacent work, the receipt needs more:
Delegating human
Agent profile or tool mode
Files and data sources inspected
MCP tools requested and used
Commands run
Approvals requested
Sensitive actions blocked
Patch summary
Test evidence
Residual risk
Rollback trigger
Owner decision
This is where engineering and security should stop arguing over separate documents. The reviewer needs enough information to trust the diff. The security or risk owner needs enough information to understand what the agent was allowed to do. The same run record can serve both needs if the team designs it that way.
A review packet also changes behavior before the run happens. When the prompt says “evidence required,” the agent has to work in a way that can be explained later. That is a useful constraint.
The buying decision depends on the budget you are trying to fix
If your team struggles with Claude Code drifting out of scope, over-editing, producing thin summaries, skipping rollback notes, or making reviewers nervous, start with the Claude Code book. It focuses on the delivery budget: task contracts, permission scope, hooks, evals, observability, cost controls, review packets, and rollback.
Start with the Claude Code book. The public purchase path goes through the Kindle edition on Amazon from the book page.
If your team already has agents touching internal tools, RAG systems, MCP servers, regulated workflows, or customer-adjacent processes, start with Securing Enterprise AI Agents. It focuses on the authority budget: identity, delegated authority, RAG governance, MCP security, policy gates, audit evidence, and incident response.
Read Securing Enterprise AI Agents.
If the same rollout has to satisfy both engineering delivery and security review, the bundle is the cleaner purchase. One book helps the team make the agent useful. The other helps the organization decide how much authority the agent may spend.
Get the Enterprise AI Agents in Production bundle.
A simple rule for the next run
Before the next serious agent run, ask this:
What are we willing to let the agent spend today?
Then write the answer into the task contract. Files. Commands. Tools. MCP capability. Data. Time. Patch size. Review evidence. Approval gates. Stop rules. Rollback.
That one question keeps the conversation honest. Engineers get a sharper Claude Code workflow. Security gets a visible boundary around delegated authority. Reviewers get a receipt instead of a story.
Fast agents are useful. Budgeted agents are safer to scale.