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.

Where credentials live

Every connector and every MCP server has authentication material. None of it lives inline in the connector definition or in the chat context. All of it lives in the vault, encrypted at rest under the org DEK.

Auth type	What’s stored
None	No credential.
Basic	Username + password as an encrypted blob.
Bearer / API key	The token as an encrypted blob.
Custom header	A templated header value with the secret as the substituted variable.
OAuth2 client credentials	Client ID + secret + token endpoint, all in the encrypted auth blob.
OAuth2 authorization code	Refresh token in the encrypted auth blob; access token cached short-term.

The auth blob is a single encrypted JSON object on the connector or MCP record. The Go sidecar unwraps it at the moment a tool call needs to authenticate, builds the HTTP request, and discards the plaintext after the request goes out. The renderer never sees the plaintext token. The model context never sees the plaintext token. The approval gate shows the connector name and the credential reference (by name); it does not show the token.

Per-call approval

Connector calls and MCP tool calls go through the same approval gate as any other tool. The gate shows:

The connector or MCP server name.
The endpoint or tool being called.
The full argument set, including the request body if there is one.
The credential reference that will be used.
The risk class — Read-only, Moderate, Dangerous, or Unknown.

The classification of a connector endpoint or MCP tool comes from two sources. Studio defaults treat new endpoints as Unknown until classified. Org admin overrides can promote specific endpoints to Read-only when the admin has reviewed them and is confident. A connector endpoint that mutates external state — creates a ticket, posts a message, sends an SMS, charges a card — should be classified Moderate at minimum. Dangerous is the right classification for things that cannot be undone (sending email, transferring money, destroying records).

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 per spec. Refresh tokens stay encrypted at rest. Access tokens are cached in memory for their lifetime, then refreshed silently or, for authorization-code flows, the operator is re-prompted.

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.	The approval gate. Every call requires approval per the trust level and classification.
Read tool arguments Copilot fills in.	Whatever you let into Copilot’s context. The approval card lets you see and edit the arguments before they go out.
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).
Refresh a long-lived OAuth token.	The vault — refresh tokens never leave the encrypted store.
Disconnect itself.	Studio detects disconnection and pauses tool calls until the server returns.

It cannot	Why
Read or modify other connectors’ credentials.	Credentials are isolated per connector at the vault level.
Reach AWS resources for your organization on its own.	The MCP server has no AWS identity. AWS calls always originate from the renderer with your short-term credential.
See your other organizations’ data.	Cross-org isolation is cryptographic, as described in vault and keys.
Persist tool outputs into your audit history.	The audit history is written by Studio, not the MCP server. The server’s response becomes the next user message; it does not bypass the application audit.

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 hostile MCP holds a refresh token and uses it indefinitely. Mitigation: refresh tokens live in the vault under the org DEK. Removing the MCP server removes the vault entry. A DEK rotation does not invalidate cleartext tokens already issued, but it does invalidate the MCP’s ability to retrieve future tokens through Studio. 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 per-connector approval policy. Read-only endpoints can be auto-approved on Supervised; write endpoints should require approval at every level except a deliberate Autonomous-with-scope.
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 have the same gate

The same approval architecture covers Studio’s built-in tools (terminal, network discovery, packet capture, inventory, search) as it does connectors and MCP. Nothing is special-cased to skip the gate. If a built-in tool changes class — for example, a terminal command that the classifier promotes from Moderate to Dangerous based on the device class — the gate prompts at the new class. The model in your head should be “the gate is the gate, regardless of where the tool came from.”