Giving your agent write access, safely

Reading data is where most agents start. Acting on it, sending a message, updating a record, creating a ticket, is where they become useful, and where a mistake reaches someone else. Here is a calm way to give an agent write access.

Start read-only

Connectors can expose operations that read and operations that write, depending on what the service’s API offers. You decide which ones your agent may use. Begin with reading only:

Chat
  ✓ Search messages
  ✓ Retrieve messages
  ✗ Send messages

CRM
  ✓ Read contacts and deals
  ✗ Update deals

An operation you have not enabled never becomes a tool, so the model cannot call it, whatever the prompt says.

Add one write at a time

1. Pick the smallest useful action. Creating a draft is gentler than sending; adding a note is gentler than changing a deal stage.
2. Enable it in development first. Each environment has its own configuration, so production stays read-only while you test.
3. Request only the scope it needs. Narrow OAuth scopes mean your users approve less, and the provider enforces the limit too.
4. Test it in staging with test accounts. Confirm the model calls it when it should, and leaves it alone when it should not.
5. Enable it in production. Then watch the first real uses closely.

Design the decision into your app

Agent200 executes what you allow. Whether a person confirms an action first is a product decision, and it belongs in your application. Common patterns:

• Draft, then confirm. The agent prepares the message or change; the user approves it in your interface; your app makes the request that performs it.
• Separate the steps. One request with read tools gathers and proposes; a second request with the write tool runs only after approval.
• Write tools for narrow tasks only. Pass a write tool only to the requests whose task needs it.

Enable reading broadly, writing narrowly, and deleting rarely.

Three layers stay in place

Even with writes enabled, every action still needs your configuration, the end user’s authorization and the provider’s permission. Read more in three layers of permission behind every tool call, or on the Security page.