Topic starter
11/06/2026 11:04 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by 1Password: “Securing MCP servers with 1Password: Stop credential exposure in your agent configurations”.
Key questions
Q: What should teams do when MCP configs contain API tokens?
A: Treat the config as sensitive until the token is removed.
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.
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.
Practitioner guidance
- 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.
Bottom line: MCP configs become a governance problem when they store reusable tokens directly in the file.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
12/06/2026 7:33 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Runtime secret injection for MCP configs reduces agentic token leaks
This post was modified 1 day ago by NHI Mgmt Group