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.
Why MCP Tool Configurations Should Stay Versioned While Secrets Stay Out of Git
The version-control boundary is simple: keep the tool definition, endpoint metadata, and runtime options in source control, but treat credentials as runtime-only inputs. That separation preserves reviewability and rollback without turning the repository into a secret store. For teams building MCP integrations, the operational goal is reproducibility with MCP authorization handled outside the committed config.
Versioned config gives you change history, peer review, and safer promotion across environments. Secret custody belongs to a managed secret store or equivalent control plane, because the moment a token, API key, or private credential is committed, it becomes durable, replicated, and much harder to contain. The right pattern is “static settings in Git, dynamic credentials at launch.”
That pattern also avoids the common anti-pattern of embedding one environment’s secret material in a file that was meant to describe behaviour, not prove access. A clean MCP setup usually separates the server definition from the authentication material, so the same committed configuration can run in dev, staging, and production while each environment injects its own credentials. Guidance in the OWASP Non-Human Identity Top 10 and the Secrets Management Guide both reinforce that credential handling should be separable from code and deployment artifacts.
Where the Boundary Breaks Down in Practice
The failure mode is usually convenience: teams store secrets in config files “just for now,” or they template them into committed manifests so the tool works everywhere. That turns a versioned artifact into an exposure point, especially when MCP tools are distributed across developer laptops, CI jobs, and agent runtimes. Once the secret is in the repo, every clone, backup, log export, and build cache becomes part of the custody problem.
Another breakdown happens when the config itself is correct but the runtime exchange is sloppy, for example long-lived tokens, copied credentials, or token passthrough between components. In MCP-like tool chains, the safer assumption is that credentials may be intercepted, replayed, or overused unless they are short-lived and scoped. The Secret Sprawl Challenge and the OAuth 2.0 Demonstrating Proof of Possession specification are useful references for reducing replay and limiting blast radius when secrets leave the ideal path.
For teams operating agents or tool-connected assistants, the risk is not only leakage, but also overbroad authority. If the same credential unlocks too many tools or survives too long, a compromised process can do far more than the original config intended. That is why version control should describe the tool, while authorization should be issued per run, per environment, or per task scope.
What Good Looks Like for Review, Rotation, and Launch-Time Secret Injection
A sound operating model keeps the repository auditable and the secret source authoritative. The config should declare what the MCP tool does, where it connects, and which secret reference it expects. The launcher, sidecar, or deployment platform should resolve that reference at startup and inject only the minimum material needed for the session. This is the same separation echoed in practical secrets management guidance and in broader identity material such as the AI Agent Identity Security deployment guide, where short-lived and task-scoped credentials are preferred.
Review should focus on whether the config is deterministic, whether the secret reference is abstracted, and whether rotation can happen without editing code or JSON by hand. If the answer requires touching Git to rotate credentials, the custody model is already too coupled. If the answer can be changed by updating the secret backend and restarting the process, the separation is usually working as intended.
A practical indicator of maturity is that developers can rotate a credential, revoke it, or replace the backing secret store without changing the MCP tool definition itself. That gives you change control for the behaviour and incident response for the credential, without mixing the two.
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 addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | MCP tool configs can expose credentials if secrets are committed or templated into files. |
| NHI-07 — Long-Lived Secrets | The question is about making credentials ephemeral instead of durable in source-controlled config. | |
| NHI-10 — Human Use of NHI | Teams must avoid manually handling tool credentials in ways that bypass controlled runtime custody. | |
| Recommendation — Keep live secrets out of versioned MCP configs and load them from a managed secret source at runtime. Replace persistent credentials with short-lived secrets and rotate them outside Git. Route secret injection through automated launch-time controls rather than manual copying or sharing. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credentials for MCP tools need lifecycle control, rotation, and protected storage. |
| CM-2 — Baseline Configuration | Versioning the MCP tool definition supports a controlled, reviewable configuration baseline. | |
| IA-9 — Service Identification and Authentication | MCP tools authenticate non-human processes and should use managed machine credentials. | |
| Recommendation — Manage token and secret lifecycle centrally and rotate authenticators without changing committed config. Keep the tool definition in a controlled baseline and separate it from secret material. Authenticate MCP services with managed machine credentials instead of embedded static secrets. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Secret custody and token handling depend on protecting sensitive authentication material in transit and storage. |
| Recommendation — Protect secret material with appropriate cryptographic handling and controlled secret storage. | ||
Practitioner Guidance
What to verify: Check that committed MCP files contain no live tokens, passwords, API keys, or private certificates, and confirm that every runtime credential resolves from an external secret source at process start.
What to measure: Track how many MCP tools still depend on embedded or manually pasted secrets, and treat any non-zero count as an exception backlog rather than a steady state.
Decision rule: If the material would let a process authenticate or call a production service, keep it out of version control; if it only describes tool behaviour, it belongs in version control.
Practitioner takeaway: Version the description of the tool, not the authority to use it. The cleanest MCP designs make configuration repeatable, while making credentials disposable.
Related resources from NHI Mgmt Group
- How should security teams govern AI tools that query endpoint risk data through MCP?
- How do teams know whether an MCP control plane is actually governing secrets?
- Why do agentic workflows and MCP tools create new access control risks for identity teams?
- How do security teams balance convenience and control in AI-assisted branding and configuration tools?