The gateway stops being a policy layer and becomes an unmanaged secrets store. That breaks the single source of truth for ownership, rotation, and revocation, and it increases blast radius if the platform is compromised.
Why raw credentials turn an MCP gateway into the wrong control plane
An MCP gateway is supposed to mediate access, apply policy, and keep credential handling subordinate to governance. When it stores raw credentials, it stops acting like a control point and starts acting like a secrets repository. That changes the trust model: the gateway now owns sensitive material directly, rather than brokering access through references and an external vault.
The practical consequence is that the gateway becomes the place where ownership, expiry, and revocation can drift out of sync. A reference can point to a centrally managed secret with clear lifecycle controls; a copied credential inside the gateway creates a second lifecycle that is easier to forget, harder to audit, and more likely to survive beyond its intended use.
This is why raw storage is not just an implementation shortcut. It collapses separation between policy and secret custody, and it makes the gateway itself a high-value credential store. The more downstream systems rely on that gateway, the more a single compromise or config error can expose multiple access paths at once.
What breaks in rotation, ownership, and revocation
Vault references preserve a single source of truth. They let the vault own rotation timing, revocation state, and access policy, while the gateway only resolves or brokers the secret when needed. Raw credentials break that model because the gateway must now be updated, synced, and validated independently of the vault, which invites drift.
Rotation is the first control to suffer. If the vault rotates a secret but the gateway keeps an embedded copy, the system can fail open in confusing ways, with one path authenticating and another already expired. Revocation is even more dangerous, because removing access in the vault does not guarantee the gateway has dropped the copied value. That leaves an orphaned credential active long after the owner believes it is gone.
Ownership also becomes ambiguous. A vault reference makes it easier to answer who owns the secret, where it lives, and what process renews it. A raw credential inside a gateway blurs those answers, especially when multiple teams treat the gateway as an infrastructure component rather than as a credential custodian. In practice, that is how stale secrets linger in config, support scripts, and deployment artifacts.
Why blast radius grows when the gateway is compromised
Once the gateway holds raw credentials, compromise of the gateway can become credential compromise, not just policy bypass. That is a different class of failure because an attacker does not need to break the upstream application or the vault itself if the gateway already contains usable secret material.
It also expands lateral movement options. A gateway often sits at a trust boundary and may mediate multiple integrations, tenants, or tool paths. If the attacker extracts credentials from that layer, they may gain direct access to backends that were never supposed to share the same custody domain. This is the classic blast-radius problem: one exposed control point now contains many secrets with many downstream uses.
Raw storage also weakens detection. A policy gateway should show access decisions, not expose the credentials themselves. When it stores secrets directly, logging, caching, backup, crash recovery, and debug output all become potential leakage paths. That creates more places to miss, more artifacts to sanitize, and more ways for a security incident to become a secrets incident.
Risk and Threat Considerations
Raw credential storage in an MCP gateway creates a dual exposure: the gateway can fail as a policy boundary and as a secret store. That increases the chance of unauthorized reuse, stale access, and secret extraction during compromise or operational mishandling.
Failure mechanism: The gateway copies identity-bearing material into a layer that should only broker access, so rotation, revocation, and inspection must now be enforced in two places. Any drift, backup, cache, or compromise in the gateway can leave credentials usable after the vault state has changed.
Impact: Attackers or misconfigurations can turn a single gateway failure into direct access to multiple upstream services, with wider blast radius, weaker auditability, and slower revocation than a reference-based design.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Raw credentials in a gateway create secret leakage risk. |
| NHI-05 — Overprivileged NHI | A gateway that holds reusable secrets can expose excessive access. | |
| NHI-07 — Long-Lived Secrets | Embedded credentials bypass lifecycle control and outlive intended use. | |
| Recommendation — Store only vault references or short-lived tokens in the gateway. Reduce gateway privilege and remove reusable credentials from it. Replace embedded secrets with externally managed, short-lived credentials. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential storage, rotation, and revocation are central to this failure mode. |
| AC-6 — Least Privilege | A gateway holding raw secrets can exceed its intended access scope. | |
| Recommendation — Manage credentials centrally and revoke or rotate them at the source of truth. Limit the gateway to the minimum access needed to broker requests. | ||
| ISO/IEC 27001:2022 | A.5.17 — Authentication information | Raw credentials in the gateway directly concern authentication information handling. |
| Recommendation — Keep authentication information protected, inventoried, and centrally controlled. | ||
Practitioner Guidance
What to verify: Confirm that the gateway stores only references or short-lived tokens derived from an external source of truth, not reusable raw credentials. If a secret appears in gateway config, runtime state, or deployment manifests, treat that as custody drift, not a minor implementation detail.
What good looks like: Rotation happens in the vault, revocation invalidates access without manual gateway edits, and the gateway logs access decisions rather than secret values. That separation is the clearest indicator that the gateway is still a policy layer instead of an unmanaged secrets repository.
Practitioner takeaway: The key test is whether the gateway can be compromised without also compromising secret custody, if not, it is already holding too much trust.
Related resources from NHI Mgmt Group
- What breaks when agencies store identity credentials in vendor-controlled databases instead of user-held wallets?
- What breaks in practice when teams remove an MCP server and rely on raw HTTP calls instead?
- How can organizations manage the risk of credential leaks in MCP frameworks?
- How do organisations reduce the dwell time of exposed credentials at scale?