Connectors and MCP safety

Connectors and MCP servers are how Studio reaches the rest of your toolchain — the ticketing system, the monitoring platform, the carrier portal, the chat tool. They are also the most common path by which third-party data enters or leaves the workspace. This page describes the safety controls around them. There is a hard truth here that we will not soft-pedal: a connector or MCP server is, by design, a way for Copilot to call out into a system you chose to add. Some of the safety story is what Studio enforces. Some of it is what the operator and the org admin are responsible for. The page is honest about both.

Definitions, credentials, and policy

Studio separates three things that are easy to conflate:

The connector or MCP definition—URL, endpoints, transport, schemas, and tool descriptions.
The credential used at execution.
The effective tool policy that decides whether a member, channel, or worker may call it.

An organization definition can use per-member credentials, where every member connects a private Key Chain entry, or an explicitly provisioned shared organization/service credential. Admins can see readiness without reading a member’s private secret. Current connectors support none, basic, bearer, API key, digest, AWS SigV4, custom headers, and several OAuth 2 flows. MCP supports none, API key, bearer, client credentials, authorization code, and MCP-standard automatic OAuth. New secret values should be referenced through Key Chain rather than persisted inline in a definition; legacy inline fields are migrated or retained only for compatibility. The model context should receive a credential reference, not the plaintext token. Custom templates, prompts, tool descriptions, context fields, and approval detail must not echo the resolved value.

Per-call approval

Connector and MCP calls use the same runtime policy and approval framework as other tools. In a supervised posture, the review surface can show:

The connector or MCP server name.
The endpoint or tool being called.
The arguments and request detail Studio makes available for review.
The credential reference that will be used.
The risk class — Read-only, Moderate, Dangerous, or Unknown.

Availability is layered. Organization policy can disable an integration or individual MCP tool; member and channel policy can narrow it; a worker stage can narrow it again. The runtime checks the effective policy at dispatch, so an old conversation cannot call a tool that was later disabled. A connector endpoint that mutates external state—creates a ticket, posts a message, sends an SMS, or changes a remote record—should never be described as read-only. Destructive or high-impact operations need the strictest classification supported by the tool definition and organization policy.

Autopilot or an equivalent autonomous trust posture can bypass per-call review for tools that remain available under policy. Do not enable it while validating a new connector or MCP server.

OAuth2 flows

Studio supports the OAuth2 flows real systems use:

Flow	Use case
Client credentials	Server-to-server APIs (most ticketing, monitoring, billing connectors).
Authorization code (with PKCE)	User-context APIs (Gmail, Outlook, Calendar — where the operator is acting as themselves).
Auto-discovery (RFC 9728 / RFC 8414 / RFC 7591)	MCP servers that publish OpenID Connect or OAuth metadata.

Token refresh is handled by the connector or MCP runtime. For per-member authorization-code flows, refreshed tokens are written back to that member’s private entry. A failed refresh becomes a visible needs auth or re-authorization state instead of silently widening credential scope.

What an MCP server can and cannot do

An MCP server is a process you connected. By definition, it is an extension point — Studio cannot enforce arbitrary safety properties on a third-party server’s behavior. Here is what it can do and what limits it:

It can	Limited by
Expose tools that Copilot may choose to call.	Organization, member, channel, worker-stage, and runtime policy plus the active trust posture.
Read tool arguments Copilot fills in.	Whatever the tool call sends. In supervised use, inspect the review detail before approving.
Return responses that become part of the model context on the next turn.	Pre-send redaction on tool output (same patterns as the prompt path).
Use and refresh an OAuth token.	The token is decrypted at the point of use and sent over TLS to the relevant authorization or resource server. It should not enter model context.
Disconnect itself.	Studio detects disconnection and pauses tool calls until the server returns.

It cannot	Why
Read another member’s personal credential.	Per-member entries remain private; administration sees readiness, not the token.
Receive Studio’s AWS credentials automatically.	Adding an MCP server does not grant it the desktop session’s AWS credentials. A server can still have its own cloud identity or any credential you explicitly configure.
Read another organization merely because you switched Studio context.	Studio scopes definitions, policy, and credentials to the active organization, but the external service must enforce its own tenant boundary too.
Write Studio’s history directly.	Studio persists the call and returned result through its own conversation path. The returned content can still influence later model turns and must be treated as untrusted input.

Threat scenarios for an unfriendly MCP

Three concrete scenarios are worth being explicit about: Exfiltration via tool argument. A hostile MCP exposes a tool whose description encourages Copilot to “send the host inventory for diagnostic purposes.” Mitigation: Copilot’s tool selection is governed by the system prompt, the user’s intent, and the approval gate. The operator sees the tool call before it goes out. Defense: do not approve tool calls whose arguments include data you don’t want to send. Data injection via tool response. A hostile MCP returns a tool response containing a prompt-injection payload aimed at convincing the model to leak data on the next turn. Mitigation: tool responses are pre-send redacted on the way back into the model context for the next turn (same patterns as outgoing prompts catch most secret leaks). Operators should treat MCP responses with the same skepticism as untrusted text from any external source. Long-lived credential abuse. A compromised external server or authorization path can misuse a token for as long as the issuer accepts it. Mitigation: keep refresh material in the configured Key Chain flow, request narrow OAuth scopes, revoke the token at the issuer, and remove the Studio credential reference and definition. Rotating Studio encryption keys does not revoke a token already issued by the external provider. These are honest descriptions of an inherent class of risk in any extensibility model. The defenses are real but they are defenses, not impossibilities.

What admins should do

The operator picks tool calls; the admin picks what tools are even available. The admin’s role is to:

Curate the connector and MCP catalog. Treat adding a connector or MCP server as adding a piece of software to the workspace. Vet the source. Read the tool catalog. Classify endpoints.
Review the OAuth scopes. Connectors authenticate with whatever scope you grant. The principle of least privilege applies — if the connector only needs to read tickets, do not give it write.
Set organization and per-tool availability. Keep write endpoints and broad MCP tools disabled until their side effects and approval detail are reviewable.
Choose credential mode deliberately. Prefer per-member identity for accountability; give shared service credentials an owner and rotation plan.
Rotate credentials. Connector credentials should rotate on the same cadence as the underlying API’s recommendation.
Remove unused connectors. A connector that no one calls is just an attack-surface item. Audit periodically and remove what’s not in use.

What operators should do

Read approval cards. They tell you the destination, the payload, and the credential reference. Approving without reading is the riskiest motion in Studio.
Use Manual or Supervised for unfamiliar tools. A tool from a newly-added MCP server you haven’t seen before is exactly the situation Manual exists for.
Treat tool output as untrusted. A response from an MCP server is not a fact. If the next turn proposes a destructive action based on it, re-read the response carefully before approving.
Report odd behavior. If an MCP tool’s description encourages something that doesn’t match its purpose, that’s an admin problem worth raising.

Built-in tools use the same framework

Studio’s built-in tools, connectors, and MCP tools all pass through effective tool policy and the conversation’s trust posture. Classification and approval detail can differ by tool. Autopilot can suppress per-call prompts, but it does not re-enable a tool disabled by organization or channel policy.