MCP connector security

Inspect connects agents to external services through remote Model Context Protocol (MCP) servers. This page explains who operates each part of that connection, what customers control, and the security limitations to consider before approving a connector.

At a glanceCopy Anchor Link

• A connector must be explicitly authorized before Inspect can use it.
• Inspect keeps connector credentials outside the model context and adds them to outbound requests at the gateway.
• Ramp operates the Inspect connector gateway. The external service controls its MCP server, tools, results, and underlying APIs.
• Inspect's built-in definitions use reviewed HTTPS endpoints on service-branded domains. Customers should confirm endpoint ownership and the provider's security posture during vendor review.
• Shared organization credentials should be limited to data appropriate for everyone who can use the connector in an eligible Inspect session.

Connecting an MCP server gives that external service a role in agent workflows. Inspect's controls do not replace review of the external provider's security, privacy, retention, and incident-response practices.

Who operates whatCopy Anchor Link

Ramp operates:

• the connector configuration and connection experience;
• authorization flows and encrypted connector records;
• the gateway that adds credentials to outbound requests;
• checks for connector status, credential ownership, and session visibility; and
• the MCP client used to discover and call tools.

The external service operates:

• the MCP server and its software supply chain;
• tool names, descriptions, input schemas, and behavior;
• the data returned by its tools; and
• authorization and audit controls in the external service.

Ramp does not install provider-supplied connector code in the Inspect application runtime. A remote MCP server remains an external trust dependency.

The AWS connector illustrates this split: Ramp built the connection flow, per-organization OIDC issuer, IAM role federation, access checks, and SigV4 request signer. Tool calls go to the configured AWS MCP endpoint, where AWS supplies the MCP tools. When a process inside a sandbox or repository image build must authenticate directly instead, use sandbox workload identity.

What customers controlCopy Anchor Link

Customers decide:

• which connectors to authorize;
• who can manage shared connector definitions and organization credentials;
• which external account, service account, API key, or cloud role Inspect may use;
• which permissions and OAuth scopes that identity receives; and
• whether a custom MCP server has passed the customer's own security review.

Inspect administrators and organization connector managers control shared connector configuration. Those management roles are not per-tool or per-user authorization after a shared connector is connected.

Personal connectors use a separate external authorization for each person, so tool calls use that person's provider identity and permissions. Organization connectors use one shared credential. Personal credential scope does not by itself make a session private: session visibility is controlled separately by the connector's access level. Using a connector marked private makes a solo session private, while a public connector can be used in workspace-visible sessions. Give a shared credential access only to data suitable for the members who can use those sessions.

Built-in connectorsCopy Anchor Link

Inspect's generally available built-in catalog contains 18 connector definitions. Availability varies by deployment and customer configuration; the Connectors page in the customer's Inspect deployment is authoritative.

Important limitationsCopy Anchor Link

• Provider changes: Inspect retrieves the live tool catalog from the connected server. Inspect does not cryptographically attest the provider's implementation or pin its tool schemas. A provider can change tool descriptions, schemas, behavior, and results independently of Inspect.
• Prompt injection: Tool descriptions and results are external content. Natural-language prompt injection cannot be completely prevented, so customers should use least-privilege credentials and review consequential actions.
• Shared access: Management roles govern connector configuration, not individual tool calls. A shared organization connector may be used by members in eligible sessions.
• Revocation: Disabling or disconnecting a connector blocks new credential resolution. A prompt already running may retain its authenticated connection until that run ends. Revoke the credential at the provider when immediate cutoff is required.
• Custom servers: Custom connectors receive Inspect's gateway, credential, status, and session checks, but Ramp does not attest the selected server's identity, implementation, or software supply chain.

Technical controlsCopy Anchor Link

Connector authorization records and custom MCP secrets are encrypted at the application layer. Inspect resolves credentials at the gateway and keeps them outside model context.

Configured MCP and discovered OAuth endpoints must use HTTPS, include a hostname, omit embedded credentials, and omit path-traversal segments. Custom named secrets can be sent only to their configured server origin.

OAuth authorization-code connections use random state, PKCE S256, a ten-minute pending authorization lifetime, and validated HTTPS authorization endpoints. The external account, grant, API key, or cloud role remains the final permission boundary.

Successful connector lifecycle changes are written to the Inspect administrator audit log. Entries identify the initiating actor and connector, credential scope, and authentication type without recording credentials, secrets, or tokens. Failed authorization attempts remain in operational logs because no lifecycle change succeeded.

For AWS, Inspect uses a five-minute OIDC token to obtain 15-minute credentials through AWS STS AssumeRoleWithWebIdentity, then signs the complete request with SigV4. Temporary credentials can sign requests only to the selected AWS MCP endpoint, and signed requests do not follow redirects. See the AWS documentation for web-identity federation and IAM OIDC providers.