Whatever message this page gives is out now! Go check it out!
Protecting secrets
Last update:
May 18, 2026
Protect secrets such as API keys, OAuth tokens, and passwords by storing them securely, limiting their exposure, and planning for safe rotation.
Overview
Secrets include API keys, OAuth tokens, passwords, and other credentials used by your MCP client or MCP servers. These credentials must be handled carefully to prevent unauthorized access, data breaches, or misuse of downstream services.
Store secrets securely
- Do not hard-code secrets in
.cfmor.cfcfiles, Git repositories, or MCP tool definitions. - Store secrets in environment variables, secure credential stores, or application server-level configuration.
- When defining transports or tools, reference an injected variable or configuration value instead of a literal token.
Avoid exposing secrets to the model
- Do not send API keys, bearer tokens, or other credentials as arguments that an LLM can see or manipulate.
- Inject authentication on the server side or at the MCP transport layer whenever possible.
- Ensure the model receives instructions such as “call this tool” rather than direct access to credentials.
Log responsibly
- Do not include authorization headers, raw tokens, or full request bodies containing credentials in debug logs.
- Redact or truncate sensitive fields before writing request and response data to logs.
- Review logging configurations regularly to ensure secrets are not inadvertently captured.
Plan for secret rotation
- Use short-lived and scoped credentials whenever possible.
- Establish and document a clear rotation process for all secrets.
- Ensure that rotating a secret can restore security without disrupting unrelated parts of the system.
We're glad. Tell us how this page helped.
We're sorry. Can you tell us what didn't work for you?
Share additional feedback to help us improve.
0/255
|
