TABLE OF CONTENTS
Overview
Stack Internal supports Model Context Protocol (MCP) client access through a standards-based sign-in flow. MCP clients use OAuth 2.1, a standard authorization method, with client registration and a protected sign-in process. After sign-in, Stack Internal exchanges the external credential for its own signed access credential. That credential carries the organization, user, and permission information that Stack Internal needs to control access. The separate MCP server repository is a reusable starting point for teams building deployable services, not the component that provides MCP client sign-in.
MCP client sign-in
MCP clients sign in through Stack Internal's identity provider. The process uses OAuth 2.1 and the authorization code flow with Proof Key for Code Exchange (PKCE). PKCE adds protection to the sign-in code that a client receives. After successful sign-in, Stack Internal exchanges the external credential for a signed access credential used inside the product.
Client registration and access
MCP clients use Dynamic Client Registration, which allows a client to register as part of the OAuth 2.1 sign-in process. The signed access credential that Stack Internal issues contains the organization, user, and permission information needed for access decisions. This ties MCP client activity to the appropriate organization and authenticated user.
Service template role
The MCP server repository is a reusable template for teams creating deployable services. It includes deployment references for the Azure cloud platform. The template is separate from the identity process that supports MCP client sign-in. A service created from the template defines its own customer-facing behavior and data handling.
FAQ
Data access, privacy, and storage
Does the provider have visibility into data processed by MCP server?
The identity provider participates in the MCP client sign-in process and handles the identity information needed to authenticate the user. After sign-in, Stack Internal exchanges the external credential for its own signed access credential. MCP services receive the Stack Internal credential rather than the external sign-in credential.
How is the scope of data access determined for users, administrators, or agents?
MCP client access is tied to the authenticated user's organization and permissions. Stack Internal includes that information in the signed access credential issued after sign-in. Services use the credential to make access decisions for the appropriate user and organization.
Access and permissions
What permissions does MCP server need to access internal or external systems?
MCP client access uses a signed access credential that includes the organization, user, and permission information needed by Stack Internal. The external sign-in credential remains at the product edge, while internal services use the Stack Internal credential for access decisions.
How does MCP server authenticate users, services, or client applications?
MCP clients use OAuth 2.1 with Dynamic Client Registration and the authorization code flow with Proof Key for Code Exchange (PKCE). The identity provider handles sign-in, then Stack Internal exchanges the resulting credential for its own signed access credential.
Does MCP server support enterprise single sign-on (SSO)?
MCP clients use Stack Internal's identity provider for enterprise single sign-on (SSO). After the user signs in, Stack Internal exchanges the external credential for a signed access credential that internal services can use for access decisions.
How are new clients, integrations, or tools registered and approved?
MCP clients use Dynamic Client Registration as part of the OAuth 2.1 sign-in process. The registration process works with the authorization code flow and PKCE, which protects the sign-in code used by the client.
Security and audit controls
What monitoring and audit logging capabilities are available for MCP server?
Stack Internal records metrics and logs for authentication and signed access credential issuance. These records cover activity such as credential issuance and client registration. They provide operational visibility into the identity process that supports MCP client access.
How does MCP server prevent unauthorized access, data exfiltration, or unauthorized write actions?
MCP clients must complete the identity provider sign-in flow before Stack Internal issues a signed access credential. That credential carries the organization, user, and permission information used for access decisions. The external sign-in credential stays at the product edge rather than being passed to internal services.
How are cross-site request forgery (CSRF), replay, or authorization-code interception attacks mitigated?
MCP client sign-in uses the authorization code flow with Proof Key for Code Exchange (PKCE). PKCE protects the sign-in code used during authorization. The process also exchanges the external credential for a Stack Internal signed access credential after sign-in.
Additional security controls
How are tokens, credentials, or secrets stored, rotated, and revoked?
MCP client sign-in uses short-lived signed access credentials issued after the user completes the approved identity-provider flow. Stack Internal validates the credential before granting product access. The identity function keeps the signing material and related service secrets in protected deployment secret storage rather than placing them in application code.
Integration and API usage
How is the connection established between MCP server and internal or external systems?
MCP clients establish access through the identity provider and OAuth 2.1. After sign-in, Stack Internal exchanges the external credential for a signed access credential used by internal services. A service created from the MCP server template defines its own connections to other systems.
Infrastructure and deployment
Can MCP server be self-hosted, privately hosted, or deployed in a customer-controlled environment?
The MCP server template is a starting point for services deployed in the Azure cloud platform. The hosting model for a service created from the template is decided as part of that service's design and deployment plan.