Secure MCP access with secret stores and identity pass-through
Once a Model Context Protocol (MCP) catalogue exists, the next governance problem is how the credentials behind that catalogue are held and how the gateway proves who is making each tool call. A server entry that carries a static bearer token in plain configuration is convenient and quietly dangerous: the token is readable by anyone with access to the configuration surface, it survives unchanged through every rotation cycle that nobody remembers to run, and when it leaks the blast radius is every request that server has ever served. Worse, when the downstream tool logs that activity, it attributes everything to a single shared identity rather than to the person who actually invoked it, which is exactly the attribution an auditor asks for and exactly what a shared token cannot provide.
This guide covers the two practices that close those gaps. The first is sourcing MCP server secrets from an approved secret store (HashiCorp Vault or a cloud key management service (KMS)) so that the gateway fetches a credential at the moment it is needed rather than reading it from a configuration field. The second is identity pass-through: configuring OAuth and API-key delegation so the downstream tool receives a credential scoped to the real end user, and propagating that end-user identity into the tool call so the downstream tool's own logs name the person who acted. Together they turn the MCP catalogue from a set of shared secrets into a set of governed, auditable, per-user delegations.
Persona: Platform operator working in the Admin Dashboard, in coordination with the security team that owns the secret store and the corporate identity provider.
Estimated time: 45--90 minutes for a first integration, depending on how quickly access to the secret store and the downstream tool's OAuth registration can be arranged.
When this guide applies
This guide is the right starting point in any of these situations:
| Situation | What it covers |
|---|---|
| Removing plaintext MCP server secrets from configuration | Pointing server entries at an approved secret store instead of an inline token |
| Integrating HashiCorp Vault or a cloud KMS with the platform | Establishing the trust relationship and reference syntax used to resolve secrets at use time |
| Delegating credentials to a downstream tool | Configuring OAuth or API-key pass-through so the tool receives a credential scoped to the caller |
| Making downstream tool logs name the real user | Propagating end-user identity into the tool call so attribution survives the hop through the gateway |
| Preparing for a security or compliance review of MCP access | Demonstrating that secrets resolve from the store and that user identity reaches downstream logs |
This guide extends Govern MCP server access, which establishes the MCP server catalogue and OAuth client configurations this guide secures. Read that guide first; the catalogue it builds is assumed throughout. The developer-side flow of assembling servers into a profile is covered in Aggregate MCP servers into a profile.
Outcomes
By the end of this guide:
- At least one MCP server resolves its credential from an approved secret store rather than from a value stored in configuration.
- At least one OAuth pass-through flow is configured and demonstrated, with the downstream tool receiving a credential scoped to the end user.
- End-user identity is propagated to the tool call and is visible in the downstream tool's own logs.
- The relationship between secret-store integration, identity pass-through, and the platform's single sign-on (SSO) and group mapping is clear.
Prerequisites
- Administrator access to the Admin Dashboard, typically the
super_adminormcp_adminrole. - A populated MCP catalogue from Govern MCP server access, including any OAuth client configurations the relevant servers require.
- An approved secret store the platform is permitted to read from (a HashiCorp Vault instance or a cloud KMS) and the credentials or workload identity the gateway uses to authenticate to it. The security team usually owns this provisioning.
- For OAuth pass-through: an application registered with the downstream tool's OAuth provider, plus the corresponding OAuth client configured in the platform as described in the governance guide.
- For identity propagation: SSO configured so that signed-in users carry a verified identity. See Configure single sign-on.
Step 1: decide which credentials belong in the secret store
Not every value needs the same treatment, and being explicit about which do avoids both over-engineering and gaps. The distinction that matters is whether a value is a standing secret that grants access on its own.
| Value | Treatment |
|---|---|
| Static bearer tokens for MCP servers | Move to the secret store; these grant access on their own and are the highest-value target |
| OAuth client secrets | Move to the secret store; a leaked client secret undermines every delegated flow that uses it |
| OAuth client IDs, authorization URLs, token URLs | May remain in configuration; these are identifiers, not secrets |
| Per-user OAuth access tokens | Not stored by the operator at all; these are obtained per user at call time and never live in configuration |
The guiding principle is that a credential should be fetched from the store at the moment it is used, not copied into a configuration field where it then has to be rotated separately and audited separately. Anything that grants access on its own belongs in the store.
Step 2: connect the platform to an approved secret store
Before a server entry can reference a stored secret, the platform has to be able to authenticate to the store and read the specific paths it is permitted to read. This is a one-time integration, performed with the security team.
- Confirm with the security team which secret store backs this deployment (HashiCorp Vault or a cloud KMS) and which paths or key names the gateway is permitted to read.
- Provision the identity the gateway uses to authenticate to the store. For Vault this is typically a role bound to the gateway's workload identity; for a cloud KMS it is typically the deployment's service account granted a decrypt or secret-access permission. The data plane runs in customer-managed infrastructure, so this binding is established on the customer side.
- In the Admin Dashboard, open the secret-store integration settings and register the store: its address, the authentication method the gateway uses, and the scope of paths it may resolve.
- Save the integration and confirm the platform reports a successful connection to the store.
Scope the gateway's access to the store as narrowly as the store allows. A read-only binding limited to the specific MCP secret paths means that a compromise of the gateway cannot be used to read unrelated secrets, which is the entire point of putting the secrets in the store in the first place.
Step 3: point an MCP server at a stored secret
With the integration in place, a server's credential can be expressed as a reference into the store rather than as a literal value.
-
Open MCP Servers in the Admin Dashboard and open the server whose secret is to be externalised.
-
Locate the field that currently holds the bearer token or other inline secret.
-
Replace the literal value with a reference into the configured secret store. The exact syntax depends on the store; a Vault reference resolves a path and key, while a cloud KMS reference resolves a named secret. A representative Vault-style reference:
vault:secret/data/mcp/github-issues#token -
Save the server entry.
At use time, the gateway resolves the reference against the store, retrieves the current value, and applies it to the upstream request. Because the value is fetched on each use rather than copied, a rotation performed in the store takes effect without any change to the platform configuration; the next tool call simply receives the new value.
Removing the literal secret from configuration is the change a security review measures. The configuration now records where the secret lives, not the secret itself.
Step 4: configure OAuth pass-through to the downstream tool
API-key pass-through and OAuth pass-through solve the same problem, delivering the right credential to the downstream tool, but they differ in whose credential is delivered. Pass-through is what lets a tool act with the correct identity rather than with a single shared account.
| Pass-through type | What reaches the downstream tool | When it applies |
|---|---|---|
| API-key pass-through | A key resolved from the secret store and attached to the upstream request | Tools that authenticate with a service or shared key held by the platform |
| OAuth pass-through | A per-user access token obtained through the OAuth flow and attached on that user's behalf | Tools that grant access on behalf of a specific authenticated user |
For API-key pass-through, the work is already done: a server configured with a bearer token resolved from the store (Step 3) attaches that key to every upstream request. The remaining steps below configure OAuth pass-through, where the credential delivered to the tool is scoped to the individual end user.
- Confirm the downstream tool's MCP server entry has its auth type set to OAuth and is mapped to the correct OAuth client, as established in Govern MCP server access. Confirm the client's secret resolves from the secret store rather than from an inline value.
- Confirm the OAuth client requests the scopes the tool requires for the actions end users will perform. A token issued without a needed scope produces a downstream authorization failure that is easy to mistake for a gateway error.
- Have a Console user reach the profile URL that includes this server. The OAuth flow runs: the user is redirected to the provider, authenticates, grants consent, and the platform exchanges the resulting code for a per-user access token.
- The gateway attaches that per-user token to the tool call. The downstream tool now sees a credential that belongs to the consenting user, not a shared one.
The result is delegation rather than impersonation. Each user's tool calls carry that user's own access token, so the downstream tool enforces that user's own permissions: a request a user is not entitled to make fails at the tool, not silently succeeds under a shared account's broader rights.
Step 5: propagate end-user identity into the tool call
OAuth pass-through gives the downstream tool a per-user token, which already carries identity in many cases. Where the tool keeps its own activity log keyed on a header or claim rather than solely on the token, the gateway can additionally propagate the verified end-user identity so that the tool's log names the real person.
- Confirm SSO is configured and enabled so that every signed-in user carries a verified identity. The identity propagated downstream is the one the identity provider asserted, not a value the user can set. See Configure single sign-on.
- In the server's configuration, enable identity propagation and select which attribute is forwarded, typically the user's email or a stable subject identifier. Avoid forwarding more than the downstream tool needs to attribute the action.
- Where the downstream tool reads identity from a specific request header, configure the gateway to place the chosen attribute in that header on the upstream tool call.
- Where group-based attribution matters (for example, distinguishing actions by business function in the downstream log) the same group mapping that drives platform roles can inform what is propagated. See Map Entra ID groups to business functions.
Identity propagation depends on SSO supplying a trustworthy identity in the first place. A locally created account with a self-asserted email propagates a self-asserted email; the value of the audit trail is only as strong as the identity provider behind it.
Step 6: verify secrets resolve and identity appears downstream
The two claims this guide makes, that secrets come from the store and that identity reaches the downstream log, are both verifiable, and both should be confirmed before the configuration is treated as done.
Verify the secret resolves from the store
- Confirm the server's secret field holds a store reference, not a literal value, by reopening the server entry in MCP Servers.
- Exercise the server through a profile and confirm the tool call succeeds, which establishes that the gateway resolved the reference to a working credential.
- Rotate the secret in the store and exercise the server again without changing any platform configuration. A successful call after rotation confirms the value is being fetched at use time rather than cached from configuration.
Verify end-user identity in downstream logs
- Have two distinct users each invoke a tool on the same server through their own profile sessions.
- With the security team, inspect the downstream tool's own activity log.
- Confirm each action is attributed to the correct individual user, with distinct identities for the two users, rather than to a single shared service account.
A failure on either check points to a specific cause: an unresolved secret reference indicates the store binding or the reference syntax is wrong, while a single shared identity in the downstream log indicates either OAuth pass-through is not active for that server or identity propagation is not configured. The platform's own audit log records the configuration changes made in this guide and complements the downstream tool's log on the access side.
What to do next
- Govern MCP server access: revisit the catalogue this guide secures to add, retire, or re-map servers and OAuth clients. See Govern MCP server access.
- Aggregate MCP servers into a profile: the developer-side flow that consumes the secured servers configured here. See Aggregate MCP servers into a profile.
- Configure single sign-on: the SSO configuration that supplies the verified identity propagated to downstream tools. See Configure single sign-on.
- Map Entra ID groups to business functions: drive group-based attribution from the corporate directory. See Map Entra ID groups to business functions.
- Audit platform activity: review the events generated by the configuration changes made here. See Audit platform activity.
Where to go next