Runtime secret injection for MCP configs reduces agentic token leaks

At a glance

What this is: This is an analysis of how MCP-based agentic development environments leak secrets when tokens are stored in plaintext, and how runtime injection changes the exposure model.

Why it matters: It matters because IAM teams now have to govern AI developer tooling as a secret distribution problem, not just a code hygiene problem, across NHI, agentic AI, and lifecycle controls.

By the numbers:

• 17 minutes.
• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.

👉 Read 1Password's guidance on securing MCP configs with runtime secret injection

Context

MCP configs are control files for agentic tools, but when they hold raw API tokens they become a secret exposure surface. The security problem is not the configuration format itself, it is the habit of embedding non-human identity credentials where source control, sync tools, and collaboration make them easy to leak.

For IAM and NHI programmes, this is a governance issue as much as a developer convenience issue. Runtime secret injection changes the trust boundary from the repository to the execution session, which is exactly where secrets should be introduced and removed for ephemeral tooling.

Key questions

Q: How should security teams handle secrets in MCP-based AI development tools?

A: Security teams should keep secrets out of MCP config files and inject them only at runtime from a managed vault. That reduces accidental disclosure through source control, shared folders, and sync tools. The credential should exist only for the process that needs it, with clear ownership, scope, and revocation.

Q: Why do plaintext tokens in agentic developer configs create outsized risk?

A: Plaintext tokens turn a local configuration file into a durable credential store. Once a repo, backup, or shared workspace contains that file, the token can be copied and reused outside its intended session. The risk is not theoretical, because API access follows the credential, not the editor.

Q: What do teams get wrong about secret rotation for AI developer tooling?

A: Teams often rotate the token but leave the storage pattern unchanged. If the secret still lives in config files, chat exports, or synced directories, the exposure path remains open. Rotation helps only when the credential lifecycle and the storage lifecycle are both controlled.

Q: Who should own MCP credential governance in an IAM programme?

A: Ownership should sit with the identity or security team that governs other non-human credentials, not with tooling admins alone. These tokens authorize API access and should be treated as part of the organisation’s NHI inventory, scope management, and offboarding process.

Technical breakdown

MCP config files and plaintext secret exposure

Model Context Protocol setups typically use a local manifest such as mcp.json to define what tools an agentic environment can call and how it authenticates. The risk appears when teams place API keys or bearer tokens directly into that file, because the file becomes portable, syncable, and easy to commit accidentally. In practice, the credential is no longer a runtime secret. It is a recoverable artefact in source control, chat shares, backups, and build systems. That creates a larger attack surface than the intended tool session.

Practical implication: treat MCP config files as non-sensitive control files and keep all credentials out of them.

Runtime secret injection with op run

Runtime injection changes credential handling by resolving secret references only when a process starts. The secret lives in a vault, is referenced by pointer, and is decrypted in memory for the duration of the process instead of being stored on disk in clear text. This pattern preserves the developer workflow while reducing the persistence of the secret itself. It also creates a cleaner separation between identity governance and tool orchestration, because the tool receives an ephemeral credential at execution time rather than a reusable static value.

Practical implication: use process-scoped secret retrieval for AI tools that need tokens, especially where repositories and shared configs are unavoidable.

Why MCP authentication should be governed like NHI access

An MCP token is not just a convenience setting. It is a non-human identity credential that authorises software to reach external APIs, and it should be governed with the same lifecycle thinking used for service accounts and workload secrets. The important distinction is that the tool may be agentic, but the credential remains an NHI control point. That means inventory, rotation, access restriction, and revocation all belong in the governance model, even when the development experience feels local and temporary.

Practical implication: place MCP-auth tokens under the same inventory and rotation controls as other NHI credentials.

Threat narrative

Attacker objective: The attacker wants to turn a leaked AI tool credential into persistent API access through the same trust path the developer intended.

1. Entry occurs when an attacker or unintended collaborator gains access to a repository, synced workspace, or copied config that contains a plaintext MCP token.
2. Escalation follows when that token is reused to call the connected API or tool endpoint with the original privileges of the developer or service account.
3. Impact occurs when the exposed credential is used to read data, modify tool-connected systems, or extend access into adjacent AI development workflows.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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

NHI Mgmt Group analysis

Plaintext MCP credentials are an NHI governance failure, not a tooling quirk. A token inside mcp.json turns a developer convenience file into an access-bearing identity artefact. That collapses the normal boundary between configuration and credential storage, which is why source control and sync tooling become part of the attack surface. The practitioner conclusion is simple: if a file can be shared, mirrored, or committed, it should not carry reusable secrets.

Runtime secret injection is the right pattern because it shortens credential residence, not because it is fashionable. The security gain comes from moving the secret to the moment of process start and keeping it out of durable storage. That aligns with NIST CSF access control and OWASP NHI expectations for secret handling, while preserving the developer workflow. The practitioner conclusion is to govern how secrets enter the session, not just where they are stored.

Agentic development tools expose a new secret sprawl zone between the IDE and the API layer. The issue is not only the number of tools, but the speed with which credentials are copied into local configs, shells, and shared environments. Ephemeral credential trust debt: every static token left in a development workflow creates future cleanup work, audit ambiguity, and revocation risk. The practitioner conclusion is to map that trust debt before it becomes habitual.

Least privilege must be applied to the API token, not assumed from the user interface. Many teams focus on the agentic editor while overlooking the fact that the embedded token often inherits broad upstream permissions. That means the actual privilege boundary sits in the backing service account or API scope, not in the MCP client. The practitioner conclusion is to review the identity behind each token and reduce its standing reach.

Developer AI environments should be treated as production-adjacent identity systems. Once MCP servers begin accessing cloud APIs, code repositories, or sensitive datasets, their credentials deserve lifecycle controls, auditability, and revocation discipline. This is where human IAM practice and NHI governance converge, because the developer is human but the delegated access is machine-held. The practitioner conclusion is to put these environments into the identity governance map rather than leaving them in tooling operations.

From our research:

• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate, 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 visibility gap makes it worth reviewing OWASP Agentic Applications Top 10 alongside your NHI secret-handling controls.

What this signals

Ephemeral secret delivery is becoming a baseline control for AI developer environments. The practical signal for IAM teams is that repository hygiene is no longer enough when AI tools can authenticate directly to APIs. Organisations that still embed tokens in config files are creating avoidable identity debt across both human workflows and machine access paths.

Runtime-controlled credentials should now be mapped into the same governance model as service accounts and workload identities. That means ownership, rotation, revocation, and audit evidence need to be visible even when the access is issued by a local development session. The identity programme that can already manage non-human access across cloud and DevOps tools is better positioned to absorb agentic tooling without widening exposure.

Secret sprawl in AI tooling is not just a hygiene problem, it is a control-plane problem. When the same credential is reused across editors, MCP servers, and local shells, the organisation loses clarity on where access begins and ends. Teams should use the Guide to the Secret Sprawl Challenge to pressure-test whether their current secret distribution model can survive agentic developer adoption.

For practitioners

• Keep secrets out of MCP config files Store tokens in a vault and reference them by pointer so mcp.json remains a non-sensitive control file that can be shared safely.
• Inject credentials only at process start Wrap AI tool startup in runtime secret resolution so the credential exists in memory only for the session that needs it.
• Inventory MCP-connected tokens as NHI credentials Track each API key, bearer token, and service credential used by agentic developer tools as a governed identity with an owner, scope, and revocation path.
• Reduce token scope before exposing tool access Limit each backing API token to the smallest tool function set possible, then validate that the connected MCP server cannot reuse broader privileges.
• Audit shared environments for residual secret copies Search repositories, synced folders, shells, and logs for leftover token values and remove any static copies that outlive the intended session.

Key takeaways

• MCP config files become a secret exposure problem when teams place API tokens in plaintext.
• Runtime secret injection reduces persistence and makes agentic developer access easier to govern.
• AI developer tooling should be managed as an NHI lifecycle issue, with ownership, scope, and revocation in place.

Key terms

• Mcp Config File: A configuration file used by an MCP-enabled tool to define which servers, APIs, and credentials it can use. In practice, it becomes risky when teams store reusable secrets inside it, because the file is easy to copy, sync, and commit across development environments.
• Runtime Secret Injection: A pattern that retrieves credentials only when a process starts, rather than storing them in files or source control. For AI developer tools, it reduces secret persistence, limits accidental disclosure, and keeps the credential tied to a specific execution session.
• Non-Human Identity Credential: A secret that authorises software rather than a person, such as an API token, service account key, or access token. These credentials need lifecycle governance because they can be reused programmatically and often outlive the task they were created for.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by 1Password: securing MCP configs with runtime secret injection for AI tools. Read the original.