Read-only first: designing safe write actions and approvals in an AI connector

Why start read-only

Read-only does not mean low value. Answering questions from live data across several systems is often most of the benefit, and it can be rolled out to more people with less review. When writes do arrive, they arrive into a connector that the team already trusts and understands.

Anthropic's documentation reminds users that connector tools can read data, create, modify, or delete data, and take actions on a user's behalf. A wrong answer from a read tool is a bad answer someone can check. A wrong write changes your records.

Starting read-only lets a team learn how the assistant actually uses the connector, which questions it handles well, and where it picks the wrong tool, before anything can change. It also makes the first security review much shorter. Add writes once you know which ones people really need.

Label every tool honestly

MCP lets each tool carry annotations describing its behavior. OpenAI's plugin documentation describes three: readOnlyHint, set to true only when the tool cannot change state; destructiveHint, true when a tool can cause outcomes that are irreversible or hard to reverse; and openWorldHint, true when a tool reaches the public internet or open-ended external entities.

Assistants use these to decide when to ask before acting. OpenAI states they help choose confirmation and safety behavior but do not replace authorization, validation, or confirmation in your server. The MCP specification adds that clients must treat annotations as untrusted unless they come from trusted servers. Treat them as guidance for the assistant, never as your only control.

Keep a person in the loop

Confirmation works best when the prompt is specific. Show the record, the field, the old value, and the new value, so the person approving can actually tell whether the change is right.

The MCP tools specification says that for trust, safety, and security there should always be a human in the loop with the ability to deny tool invocations. Both assistants provide this at the client level. Anthropic tells users to review tool approval requests and choose Allow always only for tools they trust to run unsupervised.

Be careful with features that act autonomously. Anthropic notes that during Research, Claude can invoke connector tools without further approval, and advises disabling tools that can take write actions. Plan your write tools so they are safe to turn off in those modes.

Design rules for write tools

• One action per tool. Create a ticket and close a ticket are separate tools, never one with a mode flag.
• Strict input schemas. Reject unknown fields and validate every value against the source system's rules.
• Preview, then commit. Return a summary of exactly what will change, and require an explicit confirmation before writing.
• Idempotency keys. Require a unique key per request so a retry never runs the action twice.
• Server-side permission checks. Confirm the signed-in user may make this change to this record on every call, using identity from the verified token.
• Limits. Cap how many records one call can change, and rate limit writes per user.
• Prefer reversible actions. Draft instead of send, archive instead of delete, where the business allows.
• Log every write with the user, tool, inputs, and outcome, without logging secrets.

Guard against injected instructions

The MCP security guidance and both vendors' documentation return to the same point: the model can be wrong or be misled, so the server must be safe anyway. Keeping writes narrow, confirmed, and checked server-side is what makes that true.

Anthropic warns that malicious content can contain hidden instructions meant to make Claude take unintended actions. Documents, emails, and records your read tools return are untrusted text. Never let content returned by one tool silently trigger a write in another, and keep writes behind confirmation so a person sees what is about to happen.

Example: a safe create-ticket tool

Suppose support staff want Claude or ChatGPT to open tickets in your help desk. A safe first write tool would do only that: create one ticket, with a title, a description, a priority from a fixed list, and the customer it belongs to.

The server checks that the signed-in user may create tickets for that customer, rejects any field it does not recognize, and requires an idempotency key so the same request cannot create two tickets. The tool is annotated as not read-only and not destructive, since a new ticket is easy to close. Before writing, the assistant shows the ticket details and asks the person to confirm.

Every call is logged with the user, the ticket created, and the result. Only once that tool has run well for a few weeks would you add a second one, such as updating a ticket's status, with its own checks and tests.

A rollout order that works

Launch read-only with a pilot group. Collect the actions people ask for. Add the lowest-risk, most reversible write first, behind confirmation, and test it with requests it must refuse as well as those it should complete. Then add the next one. This is how Prestyj builds write actions into custom MCP servers and ChatGPT plugins: read-only by default, with each write added on request and tested before it goes live.