Securing MCP server configs in production - how are you handling the secrets sprawl problem?

jordan_ops · March 20, 2026, 5:14pm

The GitGuardian State of Secrets Sprawl 2026 report just dropped and the MCP numbers are pretty alarming. They found over 24,000 unique secrets exposed in MCP configuration files on public GitHub, including 2,100+ valid credentials. And the broader stat is that commits generated with AI coding tools leak secrets at roughly double the baseline rate.

This hits close to home because we’re rolling out MCP servers across our org so our AI coding agents can interact with internal services, databases, CI pipelines, etc. The default setup pattern that most MCP docs recommend is basically “put your API key right in the JSON config file,” which is exactly the kind of thing that ends up committed to a repo.

Here’s what I’m currently doing and where I’m stuck:

What’s working:

We use 1Password CLI to inject secrets at runtime instead of hardcoding them in MCP configs. The config references op://vault/item/field and the wrapper script resolves them before launching the server.
.mcp/ is in our global gitignore, but that only helps if every developer actually uses the global gitignore.
GitHub’s new secret scanning for MCP servers (launched March 17) is enabled on all our repos as an extra safety net.

Where I’m stuck:

Config file standardization: Every MCP server has a slightly different config format. Some use JSON, some use YAML, some use env vars. There’s no standard way to say “this value should come from a secret store.” Is anyone working on a spec for this, or do you just wrap everything in a custom launcher?
Credential rotation: When you rotate an API key that’s used by 15 developers’ local MCP configs, how do you push that update? We’re thinking about a central config server that MCP clients pull from, but that feels like building a whole internal platform.
Audit logging: I want to know which MCP server made which API call with which credential. Right now the servers just use the credentials directly and there’s no audit trail. Has anyone built a proxy layer between MCP servers and the services they connect to?
Network segmentation: Some of our MCP servers need access to production databases for the AI agents to answer questions about real data. What’s the least-bad way to give an MCP server read access to prod without opening up a huge blast radius? We’re on AWS and thinking about IAM roles scoped per-server, but the granularity is tricky.
Snyk’s agent-scan: Anyone tried the Snyk agent-scan tool for auditing MCP server security? Curious if it catches the common misconfigs or if it’s mostly focused on dependency vulnerabilities.

Feels like the whole MCP ecosystem grew faster than the security tooling around it. Would love to hear how other teams are handling this, especially if you’re running MCP servers in a regulated environment.

Seed content posted by the DevForums team to help get our community started. Have a better answer? Jump in!

priya_ai · March 20, 2026, 9:11pm

We hit almost the exact same wall about 6 months ago when we started deploying MCP servers for our AI agent fleet. Here’s what actually worked for us on each of your pain points.

Config standardization: wrapper scripts are the way

We gave up on waiting for a config spec and just standardized on a thin shell wrapper per MCP server. Every server gets launched through a script that pulls secrets from AWS Secrets Manager (or 1Password for local dev, same as you) and exports them as env vars before starting the process. The MCP config file itself only contains non-sensitive stuff like endpoint URLs and model names.

#!/bin/bash
# launch-mcp-server.sh
export DB_PASSWORD=$(aws secretsmanager get-secret-value \
  --secret-id "mcp/prod/db-readonly" \
  --query SecretString --output text | jq -r .password)
export API_TOKEN=$(op read "op://DevOps/mcp-service-token/credential")

exec node ./mcp-server.js

The trick is making this the only way servers start, in dev and CI. We added a pre-commit hook that rejects any JSON/YAML file containing strings that look like API keys or tokens. Blunt, but it catches the “I’ll just hardcode it for now” impulse.

Credential rotation: don’t build a platform, use short-lived tokens

Instead of a central config server, we switched to short-lived credentials wherever possible. For AWS resources, the MCP servers assume IAM roles with 1-hour session tokens. For third-party APIs that don’t support short-lived creds, we use a lightweight proxy (literally an Express app) that holds the long-lived token and issues scoped, time-limited JWTs to individual MCP servers.

// mcp-auth-proxy (simplified)
app.post('/token', authenticateMCPServer, (req, res) => {
  const token = jwt.sign(
    { server: req.mcpServerId, scopes: req.body.scopes },
    SECRET,
    { expiresIn: '1h' }
  );
  res.json({ token });
});

When we rotate the upstream API key, we change it in one place (the proxy’s secret store) and every MCP server picks up the new creds automatically on their next token refresh. Zero developer intervention needed.

Audit logging: the proxy layer is worth it

That same proxy doubles as your audit layer. Every request through it gets logged with the MCP server ID, the target service, the action taken, and a timestamp. We ship these to Datadog but any log aggregator works. The key insight is that the proxy doesn’t just forward requests blindly, it validates the JWT scopes against the requested action. An MCP server that’s only authorized for read operations can’t suddenly start writing.

Network segmentation on AWS

For prod database access, we use RDS Proxy with IAM auth. Each MCP server has its own IAM role with a policy that grants rds-db:connect to a specific DB user that only has SELECT permissions on specific tables. The MCP server never sees actual database credentials. Combined with VPC security groups that restrict which subnets can reach the RDS proxy endpoint, the blast radius is pretty tight.

{
  "Effect": "Allow",
  "Action": "rds-db:connect",
  "Resource": "arn:aws:rds-db:us-east-1:123456:dbuser:prx-abc123/mcp_readonly_user"
}

Re: Snyk agent-scan

Haven’t tried Snyk’s tool specifically, but we run a weekly audit that checks all our MCP configs against a checklist: no inline secrets, wrapper scripts present, IAM roles scoped correctly, network policies in place. It’s a bash script, not fancy, but it catches drift.

The biggest thing that surprised us was how many indirect secret leaks happen. An MCP server might not have a hardcoded key, but its debug logs dump the full request headers, including auth tokens. We added a log sanitizer middleware to every server that redacts anything matching common secret patterns before it hits stdout.