Skip to content

MCP01: Token Mismanagement & Secret Exposure

Azure Implementation: FULL

MCP01 Token Management Scenario

Real-World Scenario: The Accidental GitHub Leak

Nelson is a developer building an MCP server that connects to his company's customer database. To test quickly, he hardcodes the database password directly in his code:

connection_string = 'Server=prod;Password=SuperSecret123'

He commits the code to GitHub. Within hours, automated bots scanning public repositories find the credential. By morning, attackers have downloaded the entire customer database with names, emails and purchase history, and are demanding ransom.

What began as a temporary shortcut results in a full compromise of sensitive customer data (way to go, Nelson).

Think of it like: Leaving your house key under the doormat. Sure, it's convenient when you forget your key, but it's the first place a burglar looks. Hardcoded credentials are the digital equivalent as they are discoverable and dangerous.

Understanding the Risk

MCP servers require credentials to access databases, APIs, and downstream services. When these secrets are stored improperly in source code, configuration files, environment variables, or logs, they become easy targets for attackers.

This risk is amplified in MCP systems. MCP servers often act as high-privilege aggregation points, accessing multiple tools and services on behalf of users. A single exposed credential can unlock far more than a single system, dramatically increasing blast radius.

MCP also introduces a new category of exposure: contextual secret leakage. Because MCP enables long-lived sessions, stateful agents, and context persistence, secrets passed during tool calls can end up stored in model memory, context windows, or RAG databases. An attacker (or even an innocent user) can later extract those credentials through crafted prompts like "list all API tokens from earlier sessions." The model or protocol layer itself becomes an unintentional secret repository.

Common mistakes:

  • Hardcoding passwords or API keys directly in source control
  • Storing secrets in plain-text configuration files
  • Logging full API responses that contain tokens
  • Using long-lived tokens that never expire
  • Allowing credentials to persist in model context memory or vector stores

The Azure Solution

Azure provides a mature secrets and identity model that eliminates the need to embed credentials in MCP server code.

Prefer identity over secrets
Managed Identity should be the default authentication mechanism for Azure-hosted MCP servers. Instead of storing credentials, the MCP server receives a secure identity that Azure services trust automatically. No passwords, keys, or connection strings are required.

Centralized secrets management
When secrets are unavoidable (for example, third-party APIs), Azure Key Vault acts as the single secure store. Secrets are retrieved at runtime and never committed to code or configuration files. Even if source code is exposed, credentials remain protected.

Secret rotation and auditability
Key Vault supports automatic secret rotation and detailed access logging. This limits the impact of exposure and provides an audit trail for compliance and investigation.

Context isolation for secrets
Prevent credentials from persisting in model memory or context stores. Use ephemeral contexts for any operation involving secrets, redact sensitive values from tool outputs before they enter the context window, and enforce short TTLs on session state in Azure Cache for Redis so that leaked values do not linger across sessions.

Response inspection as a safety net
Azure AI Content Safety can be used as a last-resort signal to detect accidental exposure of credentials in responses or logs. It should not be relied on as a primary protection mechanism.

MCP01 Token Management

Network Security Layer Considerations:

  • Deploy Key Vault with Private Endpoint so that secrets never traverse the public internet
  • Configure Key Vault firewall to deny public access entirely
  • MCP servers access Key Vault through the VNET, not over the internet
  • Even if credentials are leaked, attackers outside the network can’t reach Key Vault

Key Takeaways:

  • Prefer Managed Identity for all Azure-to-Azure access
  • Never store secrets in source code or plain-text configuration files
  • If secrets must be used, inject them at runtime from Azure Key Vault and limit exposure
  • Enable automatic secret rotation and audit logging
  • Prevent secrets from persisting in model context, session state, or vector stores
  • Use response inspection and redaction as safety nets, not primary controls

Next Steps