TL;DR

• Every MCP server call carries credentials. Without proper secret management, those credentials are stored in plaintext, visible to anyone with database access.
• At enterprise scale, the problem compounds: thousands of instances, dozens of integrations, and a rotation process that has to happen manually every time something changes.
• When a secret is compromised, most organizations cannot tell you within the hour who was affected and what they could access. That is a liability.
• MCPX, Lunar's MCP gateway, handles secret management at the protocol layer: encryption at rest, integration with your existing secret manager, admin-controlled access by group, and automatic propagation when values change.

Managing API keys and credentials has always been a problem. For enterprise teams deploying AI agents at scale, MCP makes it significantly larger.

Every outbound call from an MCP server carries secrets: API keys, database passwords, and OAuth tokens. The server sits between your AI agents and your production systems, which means it regularly holds the most privileged access in your stack.

According to Astrix Security's 2025 research, 88% of MCP servers require credentials to operate, and 53% rely on static API keys or personal access tokens, long-lived credentials that require manual rotation to stay secure. Token mismanagement and secret exposure rank #1 on the OWASP MCP Top 10. This is the current state of the ecosystem, not an emerging risk.

The industry knows the anti-patterns. Hard-coded credentials end up in Git history. Long-lived static tokens mean an attacker only needs to get lucky once. Broad access grants create a single point of failure for everything downstream. WorkOS published a useful breakdown of these patterns and the tooling options for addressing them at the individual server level.

What that guidance does not cover is the organizational problem: what happens when you are not managing one MCP server for one team, but dozens of servers across hundreds of users, with different access levels, connected to systems that carry sensitive data?

Deploying and managing those servers without burdening DevOps is a separate challenge, covered in Your MCP Server Is Ready. Your Organization Isn't.

That is the enterprise problem. And it's where most MCP without a proper secret management approach breaks down entirely

How MCP Handles API Keys and Secrets Today

When a user loads an MCP server, they provide configuration. Some of it is generic. Some of it is sensitive: API keys, tokens, and connection strings. That sensitive data has to live somewhere.

In most MCP implementations, it lives in a database, mapped to the server configuration. The architecture is straightforward. The problem is what that looks like in practice.

A DevOps engineer with database access can query that table and read the values in plaintext. If a user has high-privilege credentials mapped to a server, that engineer can act on their behalf, against their systems, without that user ever knowing.

Before Lunar's MCPX, a user's API key was stored as plaintext in the database or locally on the machine, mapped to their server configuration. Any engineer, AI agent, or any malicious actor with database access could read it and act on that user's behalf without their knowledge.

The rest of this post walks through the rules of enterprise MCP secret management, the use cases that demonstrate them, and how MCPX applies each one.

Rule #1: Secrets must be encrypted at rest

Plaintext credentials in a database are an exposure surface. Anyone with read access can pull every credential in the system. Encryption at rest means the stored value is unreadable without a key held separately from the database.

How MCPX applies this

The database stores only an encrypted value, unreadable without the encryption key that the DevOps team provisions at installation. At runtime, MCPX decrypts the value in memory for the authenticated user, injects it into the connection, and discards it immediately. The decrypted value is never logged, never written to disk, and never persists beyond the active session.

One important operational note:
‍ the encryption key is provisioned by the DevOps team at installation time. If that key is lost, every encrypted value in the database becomes irrecoverable, and the organization would need to reconfigure from scratch. Treat the provisioning key with the same rigor as any production secret.

Healthcare Enterprise Use Case: Credentials at Scale

One of our enterprise customers in healthcare is building AI agents that connect to patient data systems across multiple hospitals. Each hospital runs its own database with its own connection credentials. The agent needs to switch between them based on context: this request is for Hospital A, that one is for Hospital B.

Without governed credential management, the workflow looks like this. An engineer configures the agent manually for each hospital connection. When credentials change, they update each configuration manually. When a new hospital is added, they repeat the process. When a security incident occurs, and credentials need to be rotated, they hope they can find every place those credentials were used before the damage compounds.

At one hospital, this is manageable. Across a network of healthcare facilities, with agents running at scale, it's not. The manual process breaks down. Credentials drift. Rotation becomes a fire drill. And when something goes wrong, nobody can tell you with confidence who had access to what.

Imagine a corporate building where every door has both a magnetic access card and a keypad code.
If you had to memorize every code for every door you needed to enter, you would be carrying dozens of codes in your head. More importantly, when you leave the company, someone would have to track down every code you knew and change them all.

The magnetic card solves this. The card is programmed with what it opens. You never see the codes. When your access to a floor is revoked, the card configuration changes. You never knew the code, so there is nothing to forget, nothing to share, and nothing to rotate on your end.

Rule #2: Credentials must be scoped by identity, not just hidden

Hiding a credential in a UI is not the same as preventing access to it. If the value is still resolvable by the wrong user or agent, the boundary is cosmetic. Real isolation means the credential cannot be fetched outside its intended scope, even if someone knows it exists.

How MCPX applies this

MCPX treats secrets the same way. The reference is what the user sees. The value is what the system resolves at runtime. Profile-scoped secret assignment means Hospital A's agent can only resolve references assigned to its profile. Hospital B's credentials are structurally inaccessible, not just hidden.

How MCPX Manages MCP Secrets and API Keys

Secret management in MCPX operates in four modes. The distinction matters.

Local value entry. A user provides a credential directly. MCPX encrypts it at rest and resolves it at runtime. The value is never stored in plaintext, never persisted beyond the active session. This addresses the immediate database exposure problem.

Environment-based injection. The DevOps layer controls this one, not the user. Environment variables set on the MCPX container at deploy time propagate down to the MCP servers that need them. The admin maps environment variables to server parameters once. The same MCPX configuration then resolves to the right value in each deployment context: dev, staging, production, per-region, or per-tenant. When a credential rotates in production, the change happens at the cluster level once. Every MCP server under that MCPX instance picks up the new value on its next start.

Load from Secrets. The fully governed enterprise mode. Rather than entering a value, the user picks from a dropdown of named references pre-configured by the admin. The references point to the organization's existing secret manager: HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, or Azure Key Vault. The user never sees the underlying value. Neither does the admin viewing the MCPX interface. The only thing visible is the reference name.

OAuth token management. For MCP servers that authenticate via OAuth, MCPX persists the token securely and refreshes it automatically. Users authenticate once and keep uninterrupted access without repeated login prompts.

For enterprises running an MCP gateway at scale, the distinction between these modes determines whether credential management is a manual operation or a property of the system itself.

Back to our healthcare customer, this means the admin configures Hospital A's database connection once, in the org's secret manager, and maps it to a named reference in MCPX. The agent selects that reference. When the agent runs, MCPX resolves the reference at runtime, injects the value, and the connection is established. The engineer never handled the credentials.

When Hospital A rotates their database password, the admin updates the value in the secret manager once. Every instance that references it connects with the correct credentials automatically on the next call, without any manual intervention required across the organization.

The same pattern applies when multiple teams share a credential. When an R&D group and an ops group both need access to the same production database, the admin assigns that secret to both profiles once. When the password rotates, both teams pick up the new value automatically, with no coordination required between them.

Different profiles can be mapped to different references for the same field. A Sales team connecting to a CRM server gets read-only credentials. An engineering team connecting to the same server gets write access with a higher-privilege key. The admin manages both references centrally. Each user selects the reference that applies to their context, and the right credentials are injected at runtime.

What This Solves at the Enterprise Layer

• Encryption at rest: Secrets are encrypted using a key provisioned by the DevOps team at installation. The database stores only the encrypted value. The decrypted value is never logged, written to disk, or persisted beyond the active session.
• Observability and incident response: Secrets are assigned to profiles and groups. When a secret is compromised, an admin identifies exactly which users were affected and can revoke access immediately. If a secret assigned to a profile is renamed or removed in the secret manager, the admin is notified in the dashboard before it causes failures in users' connections. Organizations running more than one secret manager can see at a glance which vault each secret is pulled from, making it straightforward to audit coverage across providers.
• Automatic credential refresh: When a value is updated in the connected secret manager, every MCPX instance picks up the new credentials on the next connection. No manual API key rotation required, and no stale credentials in production.
• Compliance: Group-level secret assignment creates a clear record of who has access to what. Every secret access event is logged, giving security teams a complete audit trail for compliance review. MCPX never stores or logs underlying values and integrates with secret managers that carry existing compliance certifications.
• Operational reliability at scale: Admins configure once at the profile level. Users select from named references. When pods fall and restart in cloud Kubernetes environments, MCPX re-pulls the correct Kubernetes secrets automatically based on group assignment. If a credential was updated while the pod was down, the restarted instance picks up the new value with no manual intervention. The security posture that previously required constant manual maintenance becomes a property of the system.

What this looks like in practice

The admin view in MCPX shows all secrets available in the cluster, pulled from the connected secret manager. The admin sees reference names, not values. They assign secrets to profiles or groups. Every user in that group can then reference those secrets when configuring their server connections, without seeing or handling the underlying credentials. Admins can also trigger a manual sync with the connected secret manager at any time to immediately pull in newly added or renamed secrets.

When an incident occurs, the admin navigates to the affected secret, sees which groups it's assigned to, and has the full picture of exposure immediately. Remediation is a matter of updating the value in the secret manager and removing or updating the group assignment in MCPX.

The process that previously required hunting through individual configurations, contacting individual users, and hoping nothing was missed now takes minutes and produces a complete record.

Ready to govern MCP credentials at scale?

Most organizations discover their credential exposure after an incident. By then, the question is not whether something went wrong, but how long it went undetected and how many systems were reachable during that window.

Secret management in MCPX, Lunar's MCP gateway, handles secret management at the protocol layer:

• Secrets are encrypted at rest
• Secret values live in the organization's vault, never in MCPX itself
• Credentials are scoped by identity, not just hidden
• Secret changes propagate automatically across every instance in the cluster
• Access is granted and revoked at the group level, not per user

If your organization is deploying an MCP gateway for sensitive systems and needs to demonstrate governed, auditable credential management, [book a demo] or [contact our team].

‍