Notifications
Clear all
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.
NHIMG editorial — based on content published by 1Password: securing MCP configs with runtime secret injection for AI tools
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 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.
Questions worth separating out
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.
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 do teams get wrong about secret rotation for AI developer tooling?
A: Teams often rotate the token but leave the storage pattern unchanged.
Practitioner guidance
- 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.
What's in the full article
1Password's full post covers the operational detail this post intentionally leaves for the source:
- The exact op run command pattern for resolving secret references at process startup.
- The .env structure used to keep AI tool credentials out of mcp.json.
- The runtime verification step that proves the token does not persist outside the shell session.
- The developer workflow example showing how to keep a GitHub-connected MCP setup versionable without exposing secrets.
👉 Read 1Password's guidance on securing MCP configs with runtime secret injection →
MCP config secrets: what changes for IAM and AI developers?
Explore further
12/06/2026 7:33 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Runtime secret injection for MCP configs reduces agentic token leaks
