From read-only to write actions: release an AI agent's changes in stages

The MCP tools specification says there should always be a human in the loop with the ability to deny tool invocations, and that clients must consider tool annotations untrusted unless they come from trusted servers. The schema defines annotations such as readOnlyHint, destructiveHint, idempotentHint and openWorldHint, and describes them explicitly as hints that are not guaranteed to describe the tool's behavior faithfully.

That is a useful reminder. An annotation saying a tool is read-only is not a control. The control is the credential the tool runs with and the checks in the server that executes the action.

The OWASP Top 10 for LLM applications describes excessive agency as a risk with three common causes: excessive functionality, excessive permissions and excessive autonomy. A staged release addresses each one. Expose only the actions needed for the current stage, give each action only the permissions it needs, and require approval until there is evidence that a specific action can run without it.

In the first write stage, the agent proposes actions but cannot execute them. Each proposal shows the exact change: the target record, the fields and their new values, or the full text of the message. A person approves, edits or rejects it, and the system executes approved proposals through the normal application logic.

This stage produces the evidence for everything after it. Record each proposal, the decision and any edits. A high edit rate on a particular action tells you the agent is not ready to perform it unsupervised.

Next, the agent can execute an action after a person approves the specific proposal. The approval should be bound to the exact parameters shown; if anything changes between approval and execution, approval is required again.

Every execution produces a receipt: what was changed, by which tool, under whose approval, with the before and after values where possible. Receipts make it possible to review what happened and to reverse it if needed.

Only when the evidence supports it, allow specific low-impact, reversible actions to run without per-action approval. Examples might include adding an internal note or creating a draft that a person will review later. Define each such action narrowly, with limits on volume and scope, such as only records the requesting user owns.

I would keep actions that send external messages, move money, delete data or change permissions under per-action approval indefinitely unless there is a strong reason and a documented decision to change that.

Instructions in a system prompt are not access control. Each tool should run with credentials scoped to its stage and purpose, and the server should check every call: the user's own permissions, allowed record types, rate limits and the stage's rules. Text the agent reads from documents or messages should never be able to expand what a tool may do.

Keep a switch that disables write actions quickly without disabling the read-only assistant. Test that switch before each stage begins.

Agree the criteria for moving a specific action to the next stage before collecting the evidence: a minimum number of reviewed proposals, a low edit and rejection rate, no serious errors, and a working reversal path. Move one action at a time, not the whole tool set.

Move back when something changes. A new model version, a changed prompt, a new data source or an incident affecting the action should return it to an earlier stage until fresh evidence is collected.

The business owner should see a regular summary: proposals made, approvals, edits, rejections, automatic actions executed, reversals and incidents, per action. That report is how the team decides whether to expand, hold or reduce what the agent may do.

The acceptance condition I would agree for each stage: the exposed actions match the stage, credentials are scoped per action, every write has a receipt, the disable switch works, and the criteria for the next stage are written down before it starts.

Bring the read-only assistant you have and the first actions your team wants it to take.