TL;DR: Hardcoded tokens in mcp.json files create a plaintext secret leak path for agentic development environments, and 1Password recommends storing credentials in a vault and injecting them at runtime with op run instead. The pattern removes secrets from Git history and keeps MCP configs versionable without exposing API keys.
At a glance
What this is: This is a 1Password explanation of how runtime secret injection for MCP configs removes plaintext tokens from project files and Git history.
Why it matters: It matters because IAM, NHI, and AI development teams need versionable configs without turning MCP authentication material into a long-lived exposure problem.
Context
MCP configuration files often hold API tokens and other credentials that agentic development tools need at runtime, which makes the config itself part of the secret surface. When those values are written directly into mcp.json or shared through a repo, the file stops being a harmless settings file and becomes an exposure point.
The identity governance problem is straightforward: these credentials are non-human identities in practice, even when they are used by developers and AI tools. The article argues for removing the secret from the file and resolving it only when the process starts, so the configuration can stay portable without becoming a durable credential container.
That pattern fits the broader NHI problem of separating policy from material credentials. The security objective is not to make the config more clever, but to stop treating version-controlled text as a safe place for reusable tokens.
Key questions
Q: What should teams do when MCP configs contain API tokens?
A: Treat the config as sensitive until the token is removed. Move the credential into a vault, replace the value with a reference, and make the process resolve it only at runtime so the file itself can be shared safely.
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 are the signs that secrets are being handled unsafely in AI-assisted development workflows?
A: Warning signs include repeated use of hardcoded credentials, secrets appearing in generated code, accidental commits to public repositories, and private repositories that can be made public with only a few clicks. Another signal is overconfidence in controls while leakage still occurs. If teams need frequent emergency reissuance, their current workflow is exposing secrets faster than they are being governed.
Q: How should teams balance version control with secret custody for MCP tools?
A: Keep the config versionable but make the credentials ephemeral. The clean pattern is to commit only the tool settings and resolve authentication material from a managed secret store when the process launches.
Technical breakdown
Why mcp.json becomes a secret leakage point
MCP configs describe which tools an agentic environment can call and how it should authenticate to them. If a token is embedded directly in that file, the secret inherits every risk of the file itself: source control commits, sync tools, backups, screenshots, and copied examples. That is not an MCP-specific flaw so much as a familiar secret handling failure that reappears in agentic workflows because the config is convenient and human-readable. The practical issue is that the auth material is no longer separated from the control plane that references it.
Practical implication: Keep credentials out of MCP config files so the configuration can be shared without expanding the secret blast radius.
How runtime injection changes the credential model
Runtime injection uses a secret reference in an environment file, then resolves it only when the process starts. The token never needs to exist as a plain value in the repository or in the static config, because the CLI decrypts it in memory and passes it as an environment variable to that one session. This is a different control model from storing a reusable secret alongside the tool configuration. The important change is temporal: the credential exists only for the running process, not as a persistent artefact in the project.
Practical implication: Use runtime resolution for credentials that an MCP server or AI coding tool only needs during execution.
Why this matters for agentic development environments
Agentic development tools tend to blend local developer workflows with machine-to-machine API access, which makes their configs especially prone to secret sprawl. The article’s approach is useful because it keeps the configuration versionable while pushing credential handling into a dedicated secret store. That narrows exposure without changing the developer workflow that depends on those tokens. In identity terms, the access mechanism becomes easier to govern because the secret is centrally managed while the config remains non-sensitive metadata.
Practical implication: Separate the tool configuration from the credential source so AI-assisted development does not turn into permanent token persistence.
Breaches seen in the wild
- PyPI admin GitHub token leak 2024: A PyPI admin's GitHub token with admin rights over Python and PyPI repos sat in public Docker images for 15 months before JFrog found it.
- Toyota T-Connect key exposure 2022: A subcontractor left a T-Connect server key on public GitHub from 2017 to 2022; 296,019 customers' emails were exposed, misuse unknown.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Runtime injection is the right control boundary for MCP credentials: when a config file holds the token itself, version control becomes part of the credential lifecycle. That collapses the distinction between settings and secrets, which is exactly what creates durable exposure. The practitioner lesson is that the file should describe access, not contain it.
MCP configs are turning into a new secret sprawl layer: agentic tooling is creating more places where tokens can be copied, synced, and forgotten. The article is a reminder that the problem is not only vault hygiene but also the misuse of plain-text configuration as a transport for credentials. NHI governance has to treat developer-facing agent configs as sensitive surfaces, not harmless scaffolding.
Ephemeral process-scoped access is the governance model that fits this use case: the secret should exist only long enough for the process to start, authenticate, and run. That reduces the persistence window that attackers and careless sharing depend on, while preserving the operational convenience developers want. For practitioners, the control objective is shorter credential lifetime at the point of use.
Versionable configuration and secret custody should be decoupled: a clean MCP config can be committed, reviewed, and shared without exposing the underlying token. That separation makes governance simpler because code review can focus on function while secret management stays in the vault layer. The practical conclusion is that agentic development needs a split between declarative config and executable authentication material.
Secret leakage in agentic tools is now a configuration design problem, not just a developer discipline problem: asking developers to remember not to paste tokens into mcp.json does not scale. The stronger control is to remove the opportunity for plaintext secrets in the first place. Teams should design their MCP and AI tool workflows so the credential never appears in the file that is easiest to share.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Runtime secret injection is now the safer default for agentic development configs: the file that tells an MCP server what to do should not also be the place where reusable credentials live. That separation reduces accidental disclosure, simplifies review, and makes the config itself safe to version and share.
Secret sprawl is moving into AI developer tooling: the same habit that once leaked API keys into scripts now shows up in mcp.json, .env files, and agent startup commands. Security teams should treat these artefacts as part of the NHI estate, because the credential lifecycle is being expressed through developer workflow rather than a classic secrets manager alone.
For practitioners
- Separate MCP config from credential storage Keep mcp.json free of raw tokens and reference secrets from a dedicated vault-backed source instead.
- Inject credentials only at process start Use runtime resolution so the secret exists only for the running session and never as a committed value.
- Review developer workflows for hidden secret paths Check repository templates, sync tools, and example configs for any place where API keys can be copied or persisted.
- Standardise secret references in .env files Use reference strings such as op:// paths in environment files so the file carries pointers, not credentials.
Key takeaways
- MCP configs become a governance problem when they store reusable tokens directly in the file.
- Runtime secret injection keeps the configuration shareable while shrinking the credential exposure window.
- The practical control is separating declarative tool settings from vault-backed authentication material.
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article is about removing plaintext tokens from MCP configs. |
| NHI-07 — Long-Lived Secrets | Static tokens in mcp.json become durable credentials that outlive the process. | |
| Recommendation — Keep NHI secrets out of config files and store them only in vault-backed references. Replace long-lived NHI secrets with runtime-resolved credentials that expire with the session. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | IA-5 governs lifecycle handling of authenticators used by services and tools. |
| Recommendation — Apply IA-5 to rotate and manage credentials used by MCP-connected tools. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The core threat is credential exposure through plain-text configuration. |
| Recommendation — Map plaintext MCP tokens to TA0006 and hunt for exposed secrets in repos and config files. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Runtime injection changes how access is granted to tools and processes. |
| Recommendation — Use PR.AA-05 to align tool access with managed, process-scoped authorisation. | ||
Key terms
- MCP Configuration: MCP Configuration is the set of settings that tells an AI agent how to connect to Model Context Protocol tools, data sources, and permissions. It defines endpoints, authentication, allowed actions, and context boundaries. In practice, it governs how an agent discovers and uses external capabilities without exposing unnecessary data or control.
- 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.
- Secret Reference: A secret reference is a pointer used in configuration or policy code to retrieve a sensitive value at runtime. It lets teams keep the secret out of the file itself while still making it available to the control that needs it. This pattern improves rotation and reduces accidental exposure.
- Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
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.
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org