Skip to content
Connector Scout
–saved records

Permissions explainer · Documentation verified · v1.0

Read-only vs. write-capable AI connectors: what changes when AI can take action

A connector review has two different questions: what can it see, and what can it change? The moment a connector can act, the second question needs its own answer — what can it change, on whose behalf, and who agreed to it? This guide is about that second question — the practical difference between an assistant that reads your systems and one that writes to them.

Written and researched by Christian Stewart, Founder and EditorUpdated 16 Sept 2026Version 1.0

Quick answer

A read-only connector can retrieve context but should not change the connected system. A write-capable connector can create, update, send or delete something outside the chat. The important shift is not simply “more permission”: the assistant can now cause side effects, so tool scope, source-system rights, workspace policy, approvals, reversibility and logs all start to matter.

Retrieval is not action
Search, read, sync and deep research return information. Create, update, send and delete change something outside the conversation.
Write-capable is not unrestricted
A connector can only invoke the specific tools it exposes, on the resources the authorizing account can already reach.
The source system is the ceiling
Controls in an AI host narrow what is possible. They never grant more access than the connected account already has in the source system.
Approval behavior varies
Automatic, needs approval, always ask, manual confirmation and blocked all exist, and the default differs by platform, surface and action.
readOnlyHint is a hint
MCP tool annotations are supplied by the server. They describe intent, not enforced behavior, and should not be trusted from an unvetted server.

This page answers one narrow question: what actually changes when an AI connector moves from reading information to creating, updating, sending or deleting things. For the account, scope and revocation review that decides whether a connection is allowed at all, see how to evaluate connector permissions. For the case where those tools come from a specific Model Context Protocol server, add the MCP server security checklist.

Retrieval versus side effects

The dividing line is not sensitivity, and it is not effort. It is whether anything outside the conversation is different afterwards. A retrieval-only connector can still expose highly sensitive material — which is exactly why read-only is a boundary on effects, not a statement that the connection is low risk.

Retrieval: nothing outside the chat changes

  1. Step 1

    Connected app

    A mailbox, file store, tracker or CRM the assistant is authorized to reach.

  2. Step 2

    Assistant reads or searches

    It retrieves the records or passages it needs to answer the question.

  3. Step 3

    Answer in chat

    The output stays inside the conversation. Nothing in the source system changed.

Action: something outside the chat changes

  1. Step 1

    Connected app

    The same authorized system, reached with the same account.

  2. Step 2

    Assistant invokes an action

    It calls a specific tool — create, update, send or delete — with arguments it chose.

  3. Step 3

    External system changes

    A record exists, a field differs, a message left your domain, or something is gone. Other people and systems can see it.

The same connected app, read side and action side.
RetrievalAction
Search a mail thread and summarize the decisionSend a reply to the thread
Read an issue and its commentsChange the issue status or assignee
Read a document to answer a questionEdit, rename or delete that document
Summarize an account's recent activityUpdate the account's stage or owner

The vocabulary, defined

These are the terms used throughout Connector Scout, including in the compatibility matrix, so a classification means the same thing on every page.

Retrieval side — Search, Read, Sync, Deep research
Getting information out of the connected app. Sync additionally means content is indexed ahead of the question rather than fetched at the moment you ask.
Action side — Create, Update, Send, Delete
Changing the connected app or emitting something from it. These are the capabilities we count when we classify a connection as action-capable.
Interactive surface — Interactive
An embedded or interactive component rendered inside the assistant. It is a user-interface capability, not a side-effecting action, so we never count it as write access.

Four shapes of effect

Additive
Something new exists: a draft, a note, a task, a comment, a new record. Nothing prior was overwritten, so recovery usually means deleting what was added — but an additive write can still be externally visible or noisy.
Mutating
An existing value changes: a field, a status, an assignee, a document body. Recovery depends on whether the source system keeps version history or an audit trail.
Emitting
Something leaves the system: an email, a message, a published page. A delivered message cannot be recalled reliably once other people or systems have received it.
Destructive
Something is removed or overwritten beyond easy recall. Recovery depends entirely on the source system's trash, retention or restore behavior.

These four shapes describe effects, not a risk score. Context decides severity: creating a calendar invite for fifty external guests is additive and highly visible, while deleting a scratch file is destructive and trivial.

Effective action authority has four layers

“Write-capable” is not one switch. Whether a specific action can actually run is the intersection of four separately configured things.

Effective authority

Effective authority = exposed tool ∩ source-system permission ∩ AI-host policy ∩ invocation approval

  1. Layer 1

    What the connector exposes

    Which tools exist at all?

    An assistant can only call the operations a connector or MCP server publishes. Some integrations are search and reference only; others publish tools that create or update information. A remote MCP server's tools can read, create, modify, delete or take other actions depending entirely on what its author implemented. Source: Anthropic (opens in a new tab)

  2. Layer 2

    What the connected account can do

    Whose rights are being used?

    Actions run against the authorizing user or service account. Anthropic states this directly for Claude: even when a write tool is allowed in Claude, the user still needs the underlying permission in the source system, and restricting tools in Claude never grants more access than the source system permits. This layer is the ceiling. Source: Anthropic (opens in a new tab)

  3. Layer 3

    What the AI host or workspace policy allows

    Has an administrator narrowed it?

    Hosts add their own gate on top. Claude Team and Enterprise owners can restrict actions organization-wide — for example allowing email search and summarization while blocking send, or Drive reads while blocking create and edit. ChatGPT workspace admins can configure app action control and filter for apps with write actions to disable them as a group. Source: Anthropic (opens in a new tab), OpenAI (opens in a new tab)

  4. Layer 4

    What approval the surface requires

    Who confirms this specific call?

    The last layer applies per invocation. Claude tool permissions can be set to Always allow, Needs approval or Blocked. ChatGPT's default Important actions behavior allows reads automatically but asks first for actions with meaningful external effects, actions that expose sensitive information, or actions that are hard to undo. Source: Anthropic (opens in a new tab), OpenAI (opens in a new tab)

How the layers combine in practice.
SituationResult
The connector exposes a send-email tool, but the authorizing mailbox account cannot send from that address.No send. Layer 2 stops it, regardless of what the tool list advertises.
A user can edit the file themselves, but the workspace policy blocks connector write actions.Read-only through the assistant. The person keeps their own rights in the app.
The tool exists, the account is permitted and policy allows it, but the action needs approval at invocation.The action waits for a human to confirm it, and does not run unattended.
All four layers allow it.The write proceeds. This is the case worth designing for deliberately: logs, ownership and a recovery path should already exist.

Connector Scout model

This four-layer model is Connector Scout's explanatory framing, not vendor terminology. No provider publishes it in this form. We use it because each layer is separately documented and separately configurable, and treating them separately makes an approval decision auditable.

What our current dataset shows

These counts are generated from the central connection records at build time, so they move whenever a record is corrected or re-verified.

Tracked relationships
48
Retrieval + actions
37
Retrieval only
11
No documented connection
0
Research pending
0
Applications × platforms
16 × 3

Most recent verification across the set: 9 Sept 2026. For the full grid, cell by cell, open the AI connector compatibility matrix.

Current examples from verified records

A sample drawn automatically from the freshest published records, showing both classifications where each platform has one. Each row links to the record, which carries the precise wording, limitations and sources.

Sampled from central connection records: classification, documented actions and verification date.
PlatformApplicationClassificationDocumented actionsVerified
ChatGPTAsanaRetrieval + actionsCreate9 Sept 2026
ChatGPTAtlassian (Jira and Confluence)Retrieval + actionsCreate, Update9 Sept 2026
ChatGPTBoxRetrieval onlyNone documented (retrieval: Search, Read)9 Sept 2026
ClaudeAsanaRetrieval + actionsCreate, Update9 Sept 2026
ClaudeAtlassian (Jira and Confluence)Retrieval + actionsCreate, Update9 Sept 2026
ClaudeGitHubRetrieval onlyNone documented (retrieval: Search, Read, Sync)4 Sept 2026
GeminiAsanaRetrieval + actionsCreate, Update, Delete9 Sept 2026
GeminiAtlassian (Jira and Confluence)Retrieval + actionsCreate, Update9 Sept 2026
GeminiBoxRetrieval onlyNone documented (retrieval: Search, Read)9 Sept 2026

What changes when write access is enabled

Six things become your responsibility the moment an action is possible. Each one has a test you can actually run rather than a policy you can only assert.

External side effects

The output is no longer confined to the conversation. A record, a message or a state change now exists where colleagues, customers and other automations can see it and react to it.

Test Name every system and audience that can observe the result of one successful action.

Reversibility

Reversibility varies by effect shape and by source system, not by a general rule. A sent message may be irreversible once it has been delivered; a delete depends on the source system's trash and retention behavior; an update depends on version history; and a created item may be removable but can still be seen and acted on before anyone removes it.

Test For each enabled action, write down the exact recovery step and who can perform it.

Identity and attribution

Somebody's name ends up on the change. Decide whether actions run as the individual user or a service account, and make sure the source system's audit trail shows that an assistant performed it rather than a person typing.

Test Open the source system's history for a test action. Can you tell who and what caused it?

Approval path

Automatic, needs approval, always ask, manual confirmation and blocked are all real settings, and the default differs by platform, surface and individual action. Approval reduces how much can happen unattended; confirmation does not independently validate that the proposed action is correct, and a person can still approve a mistaken or manipulated request.

Test State the current approval setting for each enabled action, and who sees the prompt.

Automation exposure

Research, agent and scheduled surfaces can invoke tools without you watching each step, and their rules differ from ordinary chat. Anthropic recommends disabling write-action tools when using Research, because Research can invoke connector tools automatically. OpenAI documents that deep research can use custom apps only for read and fetch, not write, and that write actions in Workspace Agents default to always ask.

Test List every surface that can call this connector, not just the chat window you tested in.

Audit and recovery

You need to be able to answer, after the fact, what ran and how to undo it: an invocation log on the AI side, an audit trail on the source side, a named owner, and a tested path to revoke the connection.

Test Revoke the connection in a test account and confirm the actions actually stop.

Server trust for MCP-based tools is covered in the MCP server security checklist, and the authorizing account and scope review in how to evaluate connector permissions.

How ChatGPT, Claude and Gemini handle write actions

The three hosts are not interchangeable on this dimension, and no single sentence covers any of them. Behavior differs by surface — ordinary chat, research, agents, Spark, enterprise deployments — and by whether the integration is first-party or a custom MCP app. Confirm the current behavior for your own plan and surface before designing a rollout, because eligibility and defaults change often.

Write-action behavior by platform, from current first-party documentation.
DimensionChatGPTClaudeGemini
Default and read behaviorApps connect ChatGPT to external tools, information and actions. Some apps are search and reference only. Under the default Important actions behavior, reads happen automatically.Source: OpenAI (opens in a new tab)Connector tools can be categorized by read-only versus write and delete, and each can be set to Always allow, Needs approval or Blocked. Defaults are per connector rather than platform-wide: the Microsoft 365 connector, as one documented example, is read-only until write tools are enabled.Source: Anthropic (opens in a new tab), Anthropic (opens in a new tab)Connected Apps vary by service and surface. The Google Workspace Connected App can retrieve Gmail and Drive data and can also create and manage Calendar events, Tasks and Keep items, so capability differs per service rather than per platform.Source: Google (opens in a new tab)
Where write capability comes fromOpenAI-built apps are search-only today and do not support write actions. Custom MCP apps are the route to write and modify capability; full MCP including modify is currently in beta for Business, Enterprise and Edu on the web, while Pro can connect read and fetch MCP servers.Source: OpenAI (opens in a new tab)First-party connectors expose their own read and write tools, and remote MCP servers can read, create, modify, delete or take other actions depending on the server the user adds.Source: Anthropic (opens in a new tab)First-party Connected Apps are mixed by service. Gemini Spark documents broader Workspace actions — Calendar RSVP, schedule, update and cancel; Gmail drafts, replies, forwards and labels; Docs, Sheets and Slides creation and editing; file rename and delete; Keep notes; and Tasks add, update and delete.Source: Google (opens in a new tab)
Admin and action controlsWorkspace admins can configure app action control and, where available, approval behavior, and can filter for apps with write actions to disable them as a group.Source: OpenAI (opens in a new tab)Team and Enterprise owners can restrict actions organization-wide: allow email search and summarization while blocking send, allow Drive reads while blocking create and edit, or allow Linear reads while blocking issue creation and status changes.Source: Anthropic (opens in a new tab)Availability and controls depend on the surface and on whether the account is personal or managed by an organization, so check the documentation for the specific Gemini surface in use.Source: Google (opens in a new tab)
Invocation approval behaviorImportant actions asks before actions that may have meaningful external effects, expose sensitive information or be hard to undo. ChatGPT may also ask for confirmation before write or modify MCP actions based on permissions, context and impact, and some high-risk actions can be blocked outright.Source: OpenAI (opens in a new tab), OpenAI (opens in a new tab)Users review approval requests per tool, and Anthropic advises using Allow always only for tools and servers trusted to run unsupervised. Irrelevant tools can be disabled entirely.Source: Anthropic (opens in a new tab)For custom third-party MCP apps, Gemini currently requires manual confirmation for write actions. Within Spark, semantics vary by action: edits to shared documents require review and confirmation, while Google notes bulk actions on private Tasks may occur without confirmation, so requests should be read carefully.Source: Google (opens in a new tab), Google (opens in a new tab)
Research and automation caveatDeep research can use custom apps for read and fetch only, not write. In Workspace Agents, write actions default to Always ask during a run, and OpenAI explicitly warns to apply write-action safety to risky workflows and data-exfiltration scenarios.Source: OpenAI (opens in a new tab), OpenAI (opens in a new tab)Research can invoke connector tools automatically, so Anthropic recommends disabling write-action tools when using Research.Source: Anthropic (opens in a new tab)Action support differs between the ordinary Gemini app, Spark and enterprise deployments, so treat each surface as a separate question rather than assuming one behavior across Gemini.Source: Google (opens in a new tab)
Change controlUpdates to a published MCP server are not auto-enabled: admins can refresh and diff the changed actions, and new actions are disabled by default.Source: OpenAI (opens in a new tab)Tool lists come from the server, so a server update can change what is on offer. Reviewing approval requests rather than granting blanket Allow always is the documented control.Source: Anthropic (opens in a new tab)For custom MCP apps, Google says it does not control, monitor or secure third-party MCP servers and advises connecting only providers you trust. Write actions currently require manual confirmation, and Google advises monitoring custom apps and removing ones that are no longer needed.Source: Google (opens in a new tab)

Action constraints are not data controls

One admin detail is easy to misread: in ChatGPT Workspace Agents, Connector Action Constraints restrict what an app or connector can do — they do not restrict the data the connector returns. Narrowing actions is not a data-exposure control, and the two decisions have to be made separately. Source: OpenAI (opens in a new tab)

Platform-level coverage and surfaces are compared in more depth in ChatGPT vs Claude vs Gemini connectors, and the current per-platform documentation is linked from ChatGPT, Claude and Gemini.

A progressive enablement sequence

Stage 1

Read only

Search, read and summarize. The assistant produces answers; nothing outside the conversation changes.

Control Scope the authorizing account narrowly and confirm what gets indexed.

Stage 2

Draft in chat

The model proposes the message, ticket or update, and a person copies it into the system themselves.

Control No write tools enabled. The human is the transport layer.

Stage 3

Additive writes

Create a draft, task, note or comment — ideally in a sandbox project, test mailbox or otherwise scoped area first.

Control Approval on, low-impact target, and a named owner watching the output.

Stage 4

Updates

Modify existing records: fields, statuses, document bodies. Now version history and audit trails matter.

Control Keep approval on, verify the source system records what changed and who caused it.

Stage 5

External communication and destructive actions

Sending, publishing, deleting and status changes that other people or systems act on immediately.

Control Strongest controls: narrow tool set, tested recovery path, explicit confirmation, and a reason this cannot stay at stage 4.

A rollout sequence, not a risk ranking

This sequence is Connector Scout guidance for rolling out authority in an organization, not a universal ranking of risk. Sensitivity and context can make a read action far riskier than a write action: retrieving an unredacted HR file is more serious than creating a task in a sandbox project.

Worked examples at each level, with the approval point marked, are in the AI connector workflow library.

When read-only should stay read-only

  • The value of the workflow is synthesis and answers rather than action.
  • The source contains highly sensitive data and no downstream action is actually needed.
  • The plausible action is hard to reverse, or immediately visible outside your organization.
  • Identity and attribution are unclear, so nobody could say afterwards who acted.
  • There is no useful audit trail on either the AI side or the source side.
  • An automated or research surface could invoke the tools more broadly than you intend.
  • Your organization has not yet tested revocation and recovery on this connection.

When write access is worth enabling

Expect most or all of these to be true before an action is enabled outside a test account.

  • A clear business outcome genuinely requires the action, not just convenience in a demo.
  • The enabled tool set is narrow — the specific verbs the workflow needs and nothing else.
  • Source-system permissions for the authorizing account are limited to the resources in scope.
  • The expected action is easy for a human to inspect and approve at a glance.
  • Invocations are logged and the connection has a named owner.
  • A recovery or undo path exists where the effect shape allows one.
  • It has been tested first with low-impact data or a disposable account.
  • A change to the connector's tools triggers a re-review rather than silently taking effect.

Four action ladders

These are conceptual ladders, not capability claims. No platform supports every step for every app, and support changes. Check the compatibility matrix or the individual connection record for what is documented today.

Email

  1. 1. Read and summarize a thread no side effect
  2. 2. Draft the reply in chat for a person to send no side effect
  3. 3. Create a draft in the mailbox external side effect
  4. 4. Send the reply external side effect

CRM

  1. 1. Read the account and recent activity no side effect
  2. 2. Draft the call note in chat no side effect
  3. 3. Create a note or follow-up task external side effect
  4. 4. Update a field, owner or pipeline stage external side effect

Project management

  1. 1. Read the issue, comments and history no side effect
  2. 2. Propose the ticket text in chat no side effect
  3. 3. Create an issue or comment external side effect
  4. 4. Update status, assignee or due date external side effect

Files and documents

  1. 1. Search and read documents no side effect
  2. 2. Draft the document content in chat no side effect
  3. 3. Create a new document external side effect
  4. 4. Edit or rename an existing document external side effect
  5. 5. Delete a file external side effect

Which steps are actually available for your app and platform today is recorded in the compatibility matrix and on each record in the connector directory.

MCP tool annotations are hints, not guarantees

MCP ToolAnnotations fields and their conservative defaults when absent.
FieldWhat the server is claimingDefault when absent
readOnlyHintThe server states the tool does not modify its environment.Absent, it is treated as false — assume the tool may modify something.
destructiveHintThe server states the tool may perform destructive updates.Absent, it is treated as true — assume destructive until proven otherwise.
idempotentHintThe server states repeat calls with the same arguments have no additional effect.Absent, it is treated as false — assume a repeat call acts again.
openWorldHintThe server states the tool interacts with an open external domain.Absent, it is treated as true — assume external interaction.

Do not treat an annotation as a control

These annotations are supplied by the server describing itself. The specification is explicit that they are hints rather than guarantees, and that clients must not make trust or security decisions based on annotations received from an untrusted server. Treat “read-only” as a behavior classification you verify, not a badge you accept. Sources: Model Context Protocol (opens in a new tab), Model Context Protocol (opens in a new tab)

How to establish whether a server deserves that trust in the first place is covered in the MCP server security checklist.

Frequently asked questions

Research basis

Each claim above links to its source where the claim is made. The full list is repeated here for auditing: first-party OpenAI, Anthropic and Google documentation for platform behavior, and the Model Context Protocol specification and annotation reference for protocol-level wording. Capability counts and examples come from Connector Scout’s own verified records, described in our verification methodology.