# Security & Governance

2 min read

## Security Posture

| Credential isolation | Defense in depth | Standards-based OAuth |
| --- | --- | --- |
| MCP clients never receive origin credentials. The hub maps hub tokens to per-user downstream tokens and injects them server-side. | Origin allowlists, connector approval, selected-space restrictions, virtual server publication, and user access checks combine before a tool call is routed. | The hub supports MCP OAuth patterns including metadata discovery, PKCE, token exchange, refresh, and dynamic client registration. |

## Endpoint Authentication Summary

| Endpoint group | Authentication | Notes |
| --- | --- | --- |
| Well-known metadata | Public | Required for OAuth discovery; returns metadata only for published virtual servers. |
| Authorization and token flow | OAuth protocol controls | Protected by PKCE, state, redirect URI validation, and client handling. |
| MCP transport | Hub bearer token | Access tokens are verified before tool calls are accepted. |
| Auth-session API | Hub session JWT | Short-lived session tokens coordinate downstream authentication. |
| Downstream callback | State-bound flow | Completes per-user origin authentication without exposing tokens to clients. |

## Governance Controls

| Control | Detail |
| --- | --- |
| **Immediate access checks** | Permission decisions are evaluated against the latest state on every request, so revoking access takes effect right away. |
| **Connector access control** | Delegated connector administration and selected-space restrictions can be enabled per tenant for controlled rollout. |
| **Token lifecycle** | Hub-issued tokens are opaque, short-lived, and rotated on refresh. |
| **Tool-call audit trail** | Inbound requests and downstream tool calls are recorded with a shared correlation ID so administrators can trace activity end to end. |
| **Coordinated state changes** | Configuration changes such as disabling a tool or unpublishing a server propagate quickly across the hub. |

## Roadmap

| Theme | What is planned |
| --- | --- |
| Access-control hardening | Finalized role model, clearer scope isolation, and expanded separation of duties across hub sections. |
| Rate limiting | Per-route limits on authorization, token, and registration endpoints in addition to ingress-level protection. |
| Data loss prevention | A default Microsoft DLP baseline, the option to plug in the customer's own Microsoft DLP policy, and custom DLP modules. Requests and responses are evaluated. |
| Data anonymization | An optional outbound cleaning layer that can be configured globally, per virtual server, per origin server, or per tool. |

## Planned Request Pipeline

For sensitive tools the planned order is: elicitation where configured, outbound anonymization where activated, DLP evaluation, forward to the origin server if allowed, evaluate the response, and write the decision to the audit log.

**Security boundary.** MCP Hub governs tool exposure and credential flow. It does not remove the need for customer-side identity reviews, downstream permission hygiene, network controls, monitoring, and incident response processes.