MCP credential exposure is a structural governance problem

At a glance

What this is: This is an analysis of how default MCP setups expose secrets through config files and session transcripts, with the key finding that the architecture itself can create plaintext credential risk.

Why it matters: It matters because IAM, PAM, and NHI teams need controls that separate tool invocation from secret access, or they will inherit broad, hard-to-audit exposure across agents, servers, and published artifacts.

👉 Read Obot's analysis of MCP credential exposure and gateway controls

Context

MCP security becomes an identity and governance issue the moment the agent is allowed to read the same files that hold its credentials. In this case, the default setup places API keys, OAuth tokens, database passwords, and session transcripts in local directories that the model can inspect, which collapses the normal separation between tool use and secret custody.

The practical failure is not a one-off misconfiguration. It is a design pattern that assumes local convenience is acceptable even when sensitive credentials, logs, and published project artifacts can all travel together. That is exactly the sort of pattern NHI and IAM teams need to treat as a control boundary, not a developer preference.

For teams extending Claude Code or MCP servers into shared environments, the question is whether access is being governed at the gateway, in the vault, or in scattered local files. The article shows that many deployments still rely on the least defensible option: plaintext context on the endpoint.

Key questions

Q: How should security teams prevent MCP agents from reading secrets directly?

A: Put secret retrieval behind a vault and a gateway so the agent never sees raw credentials in local files. The runtime should receive only the minimum data needed for each tool call, and the gateway should log and enforce every request. That preserves separation between tool execution and credential custody.

Q: Why do local MCP servers create secret exposure risk?

A: Local MCP servers often receive API keys or tokens through environment variables, which makes secrets visible to the process and potentially to logs, memory, and inspection tools. If the server is compromised, those credentials can be reused outside the intended boundary. Runtime injection reduces that exposure by keeping secrets out of user space.

Q: What do teams get wrong about transcript logs in agent workflows?

A: They treat transcript logs as harmless history instead of a durable record of sensitive inputs and outputs. In practice, those logs can contain environment files, keys, database strings, and tool-call context. If they are not governed like secrets, they become a searchable shadow repository for credentials.

Q: Who is accountable when MCP secrets escape into published code or shared packages?

A: Accountability sits with the team that defined the publishing and access controls, not with the agent that exposed the file. Organisations need clear ownership for secret handling, pre-publish scanning, and gateway policy changes. The governance failure is usually lifecycle and oversight, not a single malicious action.

Technical breakdown

Why local MCP configs expose secrets by default

Local MCP servers often store credentials in plaintext config files because the agent needs those values to reach external tools and data sources. That convenience model is the opposite of traditional vault-and-injection architecture, where the application never directly reads the secret it uses. Once credentials live beside the runtime, any process with local access, including the agent session itself, can read them. The result is not merely exposure to compromise, but a broader trust problem: the same identity that is being governed also sees the keys that govern its access.

Practical implication: move secret retrieval out of local config files and into a governed control point that the agent cannot browse.

Why Claude transcripts become a hidden secret store

Claude Code writes session transcripts to ~/.claude/projects/ as plaintext JSONL, which means pasted environment values, API keys, and database strings can persist long after the interaction ends. Unlike a vault, this store is cumulative, session-scoped, and usually invisible to the developer until someone looks for it. That makes transcript history a secondary credential repository, not just an audit trail. In governance terms, it creates an unmanaged NHI secret surface that expands every time a developer uses the tool with real environment data.

Practical implication: treat transcript storage as a regulated secret surface and exclude it from publishing, backup, and shared workstation workflows.

Why MCP authentication needs a policy layer, not just tokens

MCP servers act as intermediaries between AI agents and external systems, but bearer tokens alone do not solve authorisation if every server configuration contains broad access by default. The missing control is progressive, request-level scoping enforced through a gateway that can distinguish user identity, agent identity, and request context. Without that layer, the system can prove that a token exists, but not that the right actor used the right tool for the right purpose at the right time. That is where auditability and least privilege break down together.

Practical implication: enforce per-tool policy checks and centralised audit logging at the MCP gateway rather than trusting individual server configs.

Threat narrative

Attacker objective: The attacker objective is to convert local developer convenience into broad access to external systems, published code, and downstream credentials.

1. Entry occurs when developers run Claude Code or local MCP servers with real credentials in config files and session context, making the endpoint itself the first exposure point.
2. Escalation follows when transcript history and bundled config files accumulate multiple API keys, OAuth tokens, and database passwords that any local compromise can harvest together.
3. Impact occurs when those secrets travel into published packages or are reused against connected SaaS, database, and API systems, expanding blast radius beyond the original workstation.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

The real MCP risk is credential custody collapse, not just secret leakage. The problem is that the agent needs access to the very files security teams historically protect from applications. That breaks the vault-and-injection model that separates runtime behaviour from secret storage. For practitioners, the control question is no longer whether the secret is encrypted somewhere, but whether the agent can read it at all.

Transcript stores have become an overlooked NHI secret repository. Session logs that capture pasted .env content, API keys, and database strings behave like a shadow secret store with no lifecycle governance. This is a classic access review failure for machine-adjacent workflows, because the sensitive material survives the interaction and outlives the decision that exposed it. The practitioner implication is to govern transcript retention with the same seriousness as credentials themselves.

Credential aggregation is the blast-radius multiplier in MCP environments. When config files gather multiple OAuth tokens and keys in one place, one compromised process can unlock a complete tool estate. That is a stronger failure mode than isolated secret exposure because it merges identity, authorisation, and data access into a single local trust boundary. The implication is that blast-radius control must move from workstation hardening to centrally enforced tool policy.

Purpose-built MCP gateways are emerging because local controls do not scale into governance. Independent builders have converged on the same pattern, encrypted vault mediation, scoped tool permissions, and audit logging, because the architecture demands a control plane rather than scattered endpoint hygiene. That convergence is a strong signal that the market is moving toward governed intermediary layers. Practitioners should re-evaluate whether their current MCP rollout has a real policy boundary or just a better-configured laptop.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, which explains why local agent workflows keep turning convenience into persistent exposure.
• Read the Guide to the Secret Sprawl Challenge for the operational patterns behind secret sprawl, rotation failure, and credential discovery.

What this signals

Secret custody has become the control point that will decide whether MCP deployments scale safely. Teams can no longer rely on endpoint discipline or developer memory when the default runtime invites plaintext credentials into local state. The next maturity step is to move from individual hardening to a governed control plane that can enforce policy consistently across agents, tools, and environments.

Transcript retention is now a lifecycle problem, not a logging detail. If session records can contain secrets, then retention, deletion, and access review need to be built into the programme from the start. The practical signal is simple: if your organisation cannot prove where Claude session history lives, it probably cannot prove where its agent-era secrets live either.

Credential aggregation is the new blast-radius metric for MCP adoption. Once multiple tokens live together in config files, a single compromise can expose far more than one workflow. Security teams should expect architecture reviews to shift from “can the agent call the tool” to “how many credentials become reachable when one local boundary fails.”

For practitioners

• Remove secrets from local MCP config files Relocate API keys, OAuth tokens, and database passwords into a vault-backed retrieval path that the agent cannot directly browse, and verify that local config files contain only non-sensitive references. The control objective is to eliminate plaintext credential custody on the workstation.
• Treat transcript directories as sensitive data stores Classify ~/.claude/projects/ and similar session history locations as governed secret surfaces, then define retention, deletion, and backup rules for them. Exclude those directories from publishing workflows and shared-image baselines.
• Enforce per-tool policy at a central MCP gateway Apply request-level allow, confirm, deny, and rate-limit logic at a single control point so access decisions are consistent across all connected servers. Use the gateway to log which agent invoked which tool and when.
• Audit published packages for bundled agent artefacts Scan release pipelines for .claude directories, transcript exports, and embedded configuration before code reaches a registry or artefact store. Add a pre-publish check that blocks any package containing secret-bearing agent artefacts.
• Separate identity for tool use from identity for secret retrieval Require that the identity used to invoke MCP tools is not the same path used to fetch credentials, and document the approval chain for each server. This keeps tool access and secret custody from collapsing into one local trust boundary.

Key takeaways

• MCP default architectures can collapse secret custody into the same local context the agent uses to operate.
• Transcript files and bundled config directories create persistent credential exposure that conventional vault patterns were designed to avoid.
• Centralised policy enforcement, vault mediation, and pre-publish scanning are the controls that change this from a local habit into governed identity practice.

Key terms

• MCP Gateway: The control layer that relays assistant intent to tools and data sources through the Model Context Protocol. In practice, it becomes a policy boundary, not just a transport layer. If it trusts model output too early, it can turn unverified reasoning into real-world execution or disclosure.
• Transcript Store: The persistent session history written by an agent runtime, often including prompts, tool calls, and copied environment values. When this store captures secrets, it becomes a credential surface that needs lifecycle controls, retention rules, and access restrictions.
• Key Custody: Key custody is the ownership and control of cryptographic keys across their lifecycle, including storage, rotation, emergency use, and retirement. Poor custody turns encryption into a weak barrier because any identity with key access can recover data that should have remained protected.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials — API keys, tokens, passwords, certificates — across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.

What's in the full article

Obot's full analysis covers the operational detail this post intentionally leaves for the source:

• Step-by-step explanation of how the Obot MCP Gateway centralises OAuth and credential handling across connected servers
• Per-tool access policy patterns that separate allow, confirm, deny, and rate-limited actions in live agent workflows
• Practical guidance on integrating gateway controls with existing identity providers and audit requirements
• Implementation detail on how the gateway keeps secrets outside the model's context window

👉 Obot's full post covers the transcript risk, local config exposure, and the gateway pattern in operational detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or NHI programme, it is worth exploring.