The prompt is not the control plane

A better prompt can make an agent behave better for a while. It cannot carry the whole safety model.

That matters when Claude Code is changing a real repository. It matters even more when an enterprise agent can call MCP tools, read internal data, update records, open tickets, or trigger workflows. The prompt says what you want. The control plane decides what the agent is allowed to do when the wording gets stretched, the context is incomplete, or the task turns out to be bigger than it looked.

If the agent can act, the prompt is only the beginning.

Prompts are soft boundaries

A prompt can set the shape of the work:

Only inspect these files.
Do not change permissions.
Ask before calling external tools.
Return a review packet before merge.

That is useful. I use this kind of language constantly with coding agents because it makes the expected behavior visible.

But a prompt is still a soft boundary. It sits inside the same conversation as the task, the exception, the failing test, the tempting shortcut, and the human who wants the work finished before lunch. A soft boundary helps honest work stay tidy. It does not replace a hard boundary when the agent has real authority.

For Claude Code, the hard boundary might be file scope, command approval, sandboxing, branch protection, review packets, and rollback-first prompts. For enterprise agents, it might be service identity, MCP method allowlists, data scope, policy gates, audit logs, rate limits, and revocation.

Different surfaces. Same lesson.

The control plane answers the boring questions

The control plane does not need to sound grand. It needs to answer questions a reviewer can use.

Who is the agent acting as?
Which tools can it call?
Which data can it read?
Which actions need approval?
Where are the logs?
How do we revoke access?
What evidence must the agent return before a human approves the result?

Those questions are boring in the best possible way. They turn agent work from a confident demo into an operating system for trust.

Without them, teams end up using prompt wording as a substitute for authority management. That is fragile. The agent may follow the instruction today and drift tomorrow because the task changed, the context grew, or someone added a new tool that nobody reviewed as a permission change.

Claude Code exposes the delivery loop

Claude Code makes this easy to see because the work lands as code.

A good run should start with a task contract, stay inside a scoped set of files, run the checks it claims to run, and return a packet that explains what changed, what was tested, what was not tested, what risk remains, and how to roll back.

That is a delivery control plane. It keeps the agent useful without turning the reviewer into a passenger.

This is the reason Claude Code: Building Production Agents That Actually Scale focuses on task contracts, scoped edits, review packets, evals, observability, rollback, cost control, and human approval. The point is not to make Claude Code look magical. The point is to make the work inspectable enough that a serious team can use it.

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

Enterprise agents expose the authority loop

Enterprise agents have the same problem with a wider blast radius.

The output may be a short summary, a ticket comment, a CRM update, or a workflow decision. The real risk is the authority behind that output: which identity acted, which data was read, which MCP method was called, which approval was skipped, and whether the team can prove any of it later.

A prompt that says “be careful with customer data” is not a security boundary. A control plane that limits data access, logs tool calls, requires approval for risky actions, and gives the owner a revocation path is a boundary a team can operate.

That is the territory covered in Securing Enterprise AI Agents: identity, MCP boundaries, RAG governance, policy gates, audit evidence, incident response, and revocation. If your agent can touch enterprise systems, the security model is part of the product.

LeanPub readers can get it here: Securing Enterprise AI Agents on LeanPub.

Read the two books together if you own both loops

Many teams are now dealing with both loops at once. They want Claude Code or a similar coding agent to speed up delivery, and they want internal agents to help with knowledge work, support, operations, compliance, or customer workflows.

That is not two unrelated problems. It is one operating problem in two places.

The delivery loop asks whether the agent can change work without weakening review. The authority loop asks whether the agent can act across systems without weakening control.

If your team owns both, start with the Enterprise AI Agents in Production bundle. One book helps you run Claude Code inside a reviewable engineering loop. The other helps you keep enterprise agent authority bounded, logged, and revocable.

A strong prompt is worth writing. Just do not mistake it for the system that keeps the agent honest.