MCP gateways create a new secrets sprawl problem for AI agents

At a glance

What this is: This is an analysis of how MCP gateways for AI agents can become a new locus of secrets sprawl, with runtime secret resolution and auditability emerging as the key governance pattern.

Why it matters: It matters because IAM teams now have to govern machine credentials at the control-plane layer across NHI, autonomous, and human-built agent workflows, not just in the vault.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read 1Password's analysis of MCP gateway credential governance for AI agents

Context

MCP gateways are becoming the control point where AI agents reach tools, services, and data, which means they also inherit the identity problem of who or what is actually holding the credential. The primary issue is not just access routing, but whether the platform has become a second secrets store outside the vault.

In practice, many teams solve local secret exposure by centralising credentials inside the MCP platform, then discover they have replaced one sprawl pattern with another. That shifts the IAM question from developer hygiene to NHI governance, runtime resolution, and auditable control of machine credentials.

For autonomous or agentic workflows, the governance gap is sharper because the action path is decided at runtime. For NHI programmes, the lesson is simpler: if the gateway can store, resolve, and inject secrets, it must be treated as part of the identity perimeter, not just an integration layer.

Key questions

Q: How should security teams handle secrets in MCP gateways for AI agents?

A: Security teams should keep the raw secret in the vault and let the MCP gateway resolve only a reference at runtime. That reduces persistence, limits blast radius, and preserves the vault as the source of truth. The gateway should log fetch and rotation events, but never store or expose the credential value itself.

Q: Why do MCP platforms create new identity risk for AI agents?

A: MCP platforms can become a second secrets store if they centralise upstream credentials outside the vault. That changes the risk from local developer exposure to platform-wide credential concentration. If the platform is compromised, every connected server token may be at risk, which turns orchestration into an identity control problem.

Q: How do you know if runtime secret resolution is actually working?

A: You should see reference-only storage, successful live resolution at connection time, and rotation propagation without manual reconfiguration. If the platform retains raw values in its database, caches secrets on disk, or requires redeployments after rotation, the model is not truly runtime-based.

Q: Who should own governance when an MCP gateway issues credentials to AI agents?

A: Ownership should sit with the identity and platform security teams together, because the gateway is part of the credential lifecycle. The secret broker, vault, and audit trail need one governance model. If ownership is split, policy gaps emerge where no team can prove who changed access, when it changed, or where the secret lived.

Technical breakdown

Why MCP gateways become a secrets control point

An MCP gateway sits between an AI agent and the upstream systems it needs to call, so it often becomes the place where credentials are presented, proxied, and logged. That architectural convenience creates a governance trade-off. If the gateway stores raw secrets, it concentrates risk and weakens the vault as the source of truth. If it only stores references and resolves values at connection time, the secret can stay ephemeral. The real technical issue is whether the control plane handles the credential as data, or merely as a temporary runtime dependency.

Practical implication: treat the MCP gateway as part of the credential lifecycle and require vault-backed runtime resolution, not stored static keys.

Runtime secret resolution versus stored platform credentials

Runtime resolution means the platform keeps a reference such as an op:// pointer and fetches the live secret only when a request is executed. That differs from embedding the raw value in configuration or a database. The security benefit is reduced persistence, smaller blast radius, and clearer separation between orchestration and secret custody. The operational challenge is consistency, because every connector, header, and upstream integration must support the same reference pattern if the model is to work across hundreds or thousands of servers.

Practical implication: standardise one reference-based secret pattern across all MCP connectors so teams do not fall back to ad hoc credential storage.

Auditability, rotation, and hash-based traceability

Good secret handling is not just about where the value lives. It is also about whether the platform can prove when a credential changed, who requested it, and whether the new value propagated without exposing the secret itself. Hash-based traceability gives auditors evidence of fetch and rotation events while preserving confidentiality. In NHI programmes, that matters because lifecycle control is only credible when rotation and access are observable without the platform becoming a secret repository.

Practical implication: require fetch and rotation logging that proves secret movement without recording the secret value itself.

Threat narrative

Attacker objective: The attacker aims to harvest the upstream credentials that let them pivot from the MCP gateway into multiple connected services and internal systems.

1. Entry begins when credentials are shifted from the vault into the MCP platform and the platform database becomes a new exposure surface for every connected server token.
2. Credential access occurs when a compromise of the gateway or its storage layer reveals the upstream tokens needed to reach GitHub, Slack, Notion, Linear, or internal APIs.
3. Impact follows when a single platform compromise exposes every MCP server credential at once, turning a control-plane failure into broad tool and data access.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Secrets moved into the MCP platform create identity blast radius, not just convenience. The centralised gateway model solves developer friction, but it also turns the control plane into a high-value secrets repository if raw credentials are stored there. That is an NHI governance problem, because the platform becomes both broker and custodian of machine access. Practitioners should treat any design that stores credentials outside the vault as an expansion of blast radius, not an optimisation.

Runtime resolution preserves the vault as the system of record, which is the correct governance boundary for machine credentials. If the gateway only stores references and injects the secret at connection time, it avoids persisting the raw value in a second database. This aligns with OWASP-NHI and ZT-NIST-207 thinking: secrets should be least exposed, short-lived, and auditable across the request path. The practitioner takeaway is to reject architectures that quietly reintroduce a parallel credential store.

Credential access policy for MCP must follow the control plane, not the agent label. Many teams talk about AI agents as the risk, but the actual governance surface is the credential broker that feeds them. That means policy, audit, and rotation need to be enforced where the secret is resolved and injected. The implication is straightforward: if the platform can hand out credentials, it is part of identity governance and should be reviewed as such.

Runtime credential persistence is the named failure mode this architecture exposes. The problem is not only that secrets may be stolen, but that they are no longer confined to the vault long enough for existing lifecycle controls to matter. Once the gateway stores them, even temporarily, the organisation has widened the time and place in which those credentials can be observed, copied, or misused. Practitioners should read this as a custody failure in the NHI chain, not a tooling detail.

AI agent identity governance and NHI governance are converging at the same control point. This topic shows why teams cannot separate agent security from machine credential control. The agent may decide what to call, but the credential boundary determines what it can reach. That means identity architecture for AI systems must be evaluated as a unified control plane, with the vault, gateway, and audit trail treated as one governance surface.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That governance gap becomes sharper when agent access is mediated by a gateway, which is why teams should also study 52 NHI Breaches Analysis for credential-lifecycle failure patterns.

What this signals

Secrets resolved at runtime should be treated as a governance control, not an integration convenience. If the MCP gateway becomes the place where credentials accumulate, the programme has already moved beyond secret storage into identity brokerage. Teams should expect more demand for vault-backed references, rotation evidence, and connector-level review as AI agent adoption scales. For a related control model, see Ultimate Guide to NHIs.

The next wave of AI agent governance will focus less on whether access exists and more on whether that access can be proven, rotated, and revoked without introducing a second secrets repository. That shift aligns with zero trust principles and with the practical realities of runtime credential custody in NHI programmes.

Identity blast radius: this is the point at which a single brokered secret can unlock multiple upstream services if custody is not tightly bounded. As more teams centralise agent connectivity, the security question becomes whether the control plane can prove least exposure at every fetch. For a control reference, review OWASP Top 10 for Agentic Applications 2026.

For practitioners

• Keep raw credentials in the vault Require the MCP platform to store only a reference, such as op://, and resolve the live value at request time. Prohibit raw keys from being written to the platform database or configuration store.
• Audit the control plane as part of NHI governance Review every MCP gateway as if it were a credential broker. Confirm who can fetch secrets, how fetches are logged, and whether rotation events are visible without exposing the secret value.
• Standardise runtime injection patterns Use one approved pattern for headers, token fields, and connector inputs so AI builders do not improvise with plaintext overrides or one-off secret handling.
• Tie rotation to upstream connector validation Test that credential rotation in the vault propagates cleanly to every connected server without manual redeployments or copy-paste updates.
• Map AI agent access to least-privilege upstream scopes Document the exact GitHub, Slack, Notion, Linear, and API permissions behind each server connection, then remove any credential that covers more systems than the agent actually needs.

Key takeaways

• MCP gateways are now part of the identity boundary because they can store, resolve, and inject machine credentials.
• Centralising AI agent access without vault-backed runtime resolution creates a new secrets sprawl problem and increases blast radius.
• Teams should govern the gateway like a credential broker, with reference-only storage, rotation evidence, and audit trails that never expose raw secrets.

Key terms

• MCP gateway: An MCP gateway is the intermediary that routes AI agent requests to tools, services, and data sources. In identity terms, it becomes a control point for authorisation, logging, and credential injection, so its design determines whether access stays ephemeral or becomes a second secrets repository.
• Runtime secret resolution: Runtime secret resolution means a platform stores a reference to a credential and fetches the live value only when a request is executed. This reduces persistence and can limit exposure, but only if the resolved secret is not cached, copied into logs, or written to disk.
• Secrets sprawl: Secrets sprawl is the uncontrolled spread of credentials across files, platforms, databases, and integration layers. In NHI governance, it weakens accountability because no single system can prove where the secret lives, who can fetch it, or whether the value has outlived its intended use.
• Identity blast radius: Identity blast radius is the amount of access and downstream reach exposed when one credential, token, or broker is compromised. For AI agent and NHI programmes, the term describes how much damage a single secret can unlock across connected tools, services, and automated workflows.

Deepen your knowledge

MCP gateway credential handling and runtime secret resolution are covered in the NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is moving AI agent access into a control plane, the course helps ground that design in identity governance.

This post draws on content published by 1Password: MCP gateway credential governance for AI agents. Read the original.