# From read-only to write actions: release an AI agent's changes in stages > Release AI agent write actions in stages: proposals, approved execution with receipts, narrow automatic actions, server-side limits and evidence to advance. Canonical URL: https://techtideai.io/blog/ai-agent-write-actions-staged-release Markdown URL: https://techtideai.io/blog/ai-agent-write-actions-staged-release.md Publisher: TechTide AI, Columbus, Ohio (https://techtideai.io) Author: Alex Cinovoj, Founder & CTO, TechTide AI ยท CTO & Co-Founder, CPG Playbook Type: Field Note Published: 2026-10-29 Collection: October 2026 editorial collection (a label, not the publication date) Reading time: 4 min Topics: AI agent write access, MCP tool annotations, excessive agency, agent approval workflow Site index: https://techtideai.io/llms.txt Offer summary: https://techtideai.io/offers.md --- The first release of an AI assistant connected to internal systems should usually be read-only. It answers questions, finds records and explains what it found. Sooner or later the team asks for the next step: let it create the ticket, update the record or send the reminder. That step changes the risk more than any model upgrade, because the assistant can now change the world rather than describe it. I would release write actions in stages, each with evidence before the next. The stages are not about trusting the model more over time. They are about learning, with real cases, which actions are safe to automate and under what conditions, while keeping a person in control of everything else. The approach below applies to agents built on the Model Context Protocol and to other tool-calling designs. Specific controls depend on your platform and the systems the agent connects to. ## Start from what the protocol does and does not promise The [MCP tools specification](https://modelcontextprotocol.io/specification/2025-11-25/server/tools) 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. ## Name the failure you are designing against The [OWASP Top 10 for LLM applications](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/) 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. ## Stage one: proposals only 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. ## Stage two: approved execution with receipts 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. ## Stage three: narrow automatic actions 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. ## Enforce limits in the server, not the prompt 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. ## Move between stages on evidence 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. ## Report what the agent did 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. [Send the project brief](https://techtideai.io/contact). ## Sources - [MCP tools specification](https://modelcontextprotocol.io/specification/2025-11-25/server/tools) - [OWASP Top 10 for LLM applications](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/) ## Related Field Notes - [Connecting Claude to internal systems: scope a read-only MCP release](https://techtideai.io/blog/claude-mcp-read-only-first-release) ([Markdown](https://techtideai.io/blog/claude-mcp-read-only-first-release.md)): How to scope a first Claude MCP integration around read-only questions: narrow tools, the user's own access, source links, freshness and an evaluation set. - [The MCP server security checklist I run before handoff.](https://techtideai.io/blog/mcp-server-security-checklist) ([Markdown](https://techtideai.io/blog/mcp-server-security-checklist.md)): An MCP server is two products: a tool surface and a security surface. The checklist we run before handoff, covering auth, tenancy, arguments, and audit. - [Prompt injection is an access-control problem.](https://techtideai.io/blog/prompt-injection-defense) ([Markdown](https://techtideai.io/blog/prompt-injection-defense.md)): You cannot prompt your way out of prompt injection. Defend it like access control: scoped credentials, typed tools, allowlists, and a human gate on writes. - [Legal matter closeout: reconcile the checklist before changing access](https://techtideai.io/blog/legal-matter-closeout-workflow) ([Markdown](https://techtideai.io/blog/legal-matter-closeout-workflow.md)): A proposed matter-closeout workflow that reconciles the checklist across systems and reviews access before anything changes, under the firm's own rules. All Field Notes: https://techtideai.io/blog