Lakera scanned roughly 46,500 npm packages this spring and found credentials sitting in Claude’s config directory across 30 of them. The developers who published those packages did not intend to ship secrets. They ran Claude Code, built something worth sharing, and pushed it without realizing the .claude directory came along. The MCP security problem in its most concrete form is exposure that happens not through misconfiguration but through the default architecture working exactly as designed.
The credentials are in the config files because the agent needs them there. The transcripts accumulate in ~/.claude/projects/ because every session gets written to disk. Neither is an accident. Both create risks that traditional vault-and-injection patterns were built to prevent, and neither is addressed by anything in the standard MCP setup. Local MCP servers often run directly on a user’s local machine, which can increase security risks if misconfigured or compromised.
When you set up an MCP server, the credentials go somewhere. In the default architecture, that somewhere is a plaintext config file sitting in your local environment, readable by the same AI agent you just handed a set of powerful tools. API keys, OAuth tokens, database passwords: all of it, in the clear. MCP servers operate as intermediaries that connect hosts to various external systems, and MCP servers act as proxies between AI agents and those systems. When MCP servers run locally, they can inadvertently expose sensitive credentials, increasing the risk of unauthorized access.
MCP servers need credentials to authenticate with external services, and the path of least resistance is environment-based configuration. The AI model needs to invoke those tools, so it gets access to the context that defines them. The two requirements converge on a setup where the agent can read everything it needs to operate, including secrets that exist purely to authenticate outbound connections, which is one of the core MCP security risks and best‑practice gaps emerging as organizations connect agents to real systems.
Traditional API credential management keeps secrets in dedicated vaults, injects them at runtime through infrastructure tooling the application never directly reads, and enforces strict access controls on who and what can retrieve them. The developer writes code that calls a function; the function resolves a secret from a vault the code itself cannot browse. That separation is foundational to how security teams think about credential hygiene.
MCP configurations collapse that separation by design. As one developer noted in a discussion on r/ClaudeAI, “every MCP server I’ve set up puts credentials in config files that Claude can read. API keys, OAuth tokens, database passwords, all in plaintext in my environment.” That is not a misconfiguration. That is the default. Credential aggregation is a risk, because typical local MCP configurations keep multiple OAuth tokens and API keys together in plaintext config files. A compromise of the machine or any MCP server process that can read those files has an outsized blast radius.
The Malicious MCP Server Security Exposure Developers Are Discovering Late
The scope of the problem extends beyond raw config files. As developers on r/AI_Agents have started documenting, CLAUDE.md files can also carry sensitive information if developers have dropped API keys or database connection strings in as session context. Those files get read every session, automatically, without any deliberate access grant.
MCP authentication is not happening in the traditional sense. The agent is not being handed a token scoped to its specific actions. It is being handed a config environment that happens to contain every secret the system needs to function. From a least-privilege standpoint, that is a significant gap between where the ecosystem is today and where enterprise security standards require it to be. As a result, clients and users are often granted broad access to sensitive tools, increasing the risk of unauthorized actions and making it difficult to track user identity, user consent, and user actions for compliance and audit purposes.
Implementing a progressive, least-privilege scope model is essential for minimizing the impact of token compromise and improving audit clarity in MCP systems, and it requires proxying access and credentials through a governed MCP security layer rather than trusting each individual server configuration.
The Transcript Time Bomb: What Claude Has Already Stored on Your Machine
The config file problem is visible if you know to look for it. The transcript problem is not, and that asymmetry is what makes it more dangerous.
Every Claude Code session writes a full conversation record to ~/.claude/projects/ as a plaintext JSONL file. The directory accumulates indefinitely. As one developer noted in a discussion of terminal workflows, anything you have pasted into a session to help Claude understand your setup, including .env contents, API keys, and database connection strings, is sitting in that directory in full. These transcript files may also include details about data sources accessed and API calls made by the AI agent during the session. A quick ls -lh ~/.claude/projects/ tends to surface more than developers expect.
MCP allows AI agents to directly interact with internal databases, APIs, and SaaS platforms, which requires specialized security measures to protect sensitive data and a focus on managing MCP servers beyond just building them as deployments scale across teams and environments.
The MCP Security Risk That Travels With Your Code
The local exposure is one problem. The supply-chain exposure is a different one entirely.
The Lakera scan found credentials in Claude’s config directory across 30 separate packages because developers ran Claude Code on projects they later published, and the .claude directory came along for the ride. Secrets that were never meant to leave a laptop ended up in public package registries because the transcript store was not part of anyone’s pre-publish checklist. These credentials can provide unauthorized access to third-party APIs and external systems, increasing the risk and impact of such exposures, especially when they are paired with dangerous MCP OAuth shortcuts that undermine security guarantees.
A credential that lives only on your machine is a contained risk. A credential that ships inside a published npm package becomes accessible to anyone who installs it, forks it, or audits its contents post-publication. The blast radius is categorically different.
What is accumulating in ~/.claude/projects/ is a growing archive, session over session, project over project, with no automatic expiration. The cc-vibeguard scanner from Vibenalytics was built specifically to parse this transcript history and surface credential patterns across projects, because the exposure tends to present as a habit rather than a one-time event. In sample scans, the tool has flagged hundreds of KEY= and SECRET= values alongside dozens of Bearer tokens spread across multiple projects.
For teams working toward real MCP authentication governance, the transcript store belongs in the same conversation as the config files, with the same rigor applied to access controls, rotation policies, and what gets included in version control or published artifacts. MCP servers should also enforce scope checks on each request to ensure that only authorized actions are performed, limiting the potential damage from stolen tokens. Centralized enterprise access control for MCP servers is what makes those policies enforceable across many agents and tools.
The DIY Security Sprint: What Builders Are Cobbling Together
When a security gap is real, developers stop waiting for a fix and start shipping their own. In the span of a few weeks this spring, at least three independent builders published tools designed to solve the same underlying MCP security problem from different angles, without coordination, arriving at the same diagnosis. These DIY solutions often implement additional security controls and follow security best practices to mitigate risks associated with MCP servers, but they stop short of the kind of centralized MCP proxy layer for security, control, and observability that enterprises ultimately need.
Output sanitization is also an important security best practice, as it prevents data leaks and tool poisoning by cleansing data returned to the AI from malicious content.
The Workarounds Taking Shape
The most direct response came from the developer who posted in r/ClaudeAI in early May. Uncomfortable with credentials sitting in plaintext config files, they built Factorly, an open-source Go intermediary that sits between Claude Code and your MCP servers. Credentials live in an encrypted vault. Claude sees tool names and results. The secrets never cross the agent’s context window. Per-tool policies allow, confirm, deny, or rate-limit individual operations, including a workflow layer that holds for human approval before high-stakes actions like posting to Slack. The architecture is a direct reimplementation of the vault-and-injection pattern that security teams already rely on in mature infrastructure stacks. Secure tool invocation is critical in this setup to ensure that AI assistants cannot perform unauthorized actions, as each tool call must be authenticated, authorized, and logged to prevent misuse.
A few days later, a separate builder posted in r/AI_Agents with a narrower but equally telling solution: a Docker-based sandbox for Claude Code on Windows, filling a gap the official tooling leaves open on that platform. The approach uses a settings.json permissions object to explicitly scope what Claude can read, write, and execute, and a separate sandbox configuration to constrain file and domain access at the Bash tool level. The builder framed it plainly as “strict guardrails” for environments where the defaults are not sufficient. However, even with sandboxing, AI assistants can be targeted by tool poisoning attacks, where attackers manipulate tool definitions to deceive the AI into calling incorrect functions or bypassing security filters.
Meanwhile, cc-vibeguard from Vibenalytics had already shipped a local-first audit scanner that parses transcript history to surface credential exposure patterns across projects. Rather than preventing exposure at the point of configuration, it measures whether risky handling has become a habit and reports it in terms security teams can act on.
A Signal, Not a Prompt Injection Solution
These tools are genuine contributions. They also represent a tax that should not exist. When independent developers in separate communities, working from separate frustrations, all arrive at encrypted vault intermediaries, containerized permission scoping, and credential audit scanning as their answers, the platform has a structural gap and practitioners are filling it by hand. Monitoring MCP components—such as tracking interactions, configurations, and server activity—is essential for detecting threats and ensuring consistent mcp security, which is where a purpose-built MCP gateway that centralizes routing, security, and observability becomes the core control point.
The history of infrastructure security follows this pattern: a capability outpaces its governance model, a wave of DIY patches emerges, and then either the platform catches up or the patches become the permanent workaround layer that every new team has to rediscover. The presence of these tools is a clear signal about where MCP authentication stands on that curve. Real-Time Policy Enforcement is critical, as it evaluates every AI request before execution to prevent unauthorized actions.
Why DIY Doesn’t Scale: The Enterprise Access Token Problem
A Go-based vault intermediary running on one developer’s laptop enforces policy for that developer. A Docker sandbox with scoped permissions protects one environment. A transcript scanner surfaces credential patterns for whoever runs it. Each addresses a real exposure. None of them answer the questions a CISO needs answered: Which agents across our organization have access to which credentials right now? When did that change? Who approved it?
Those questions require a control plane, not a collection of local tools. The absence of that control plane is not a niche concern. Enterprise deployments require robust governance and seamless integration with existing identity providers (IdPs) to meet the complex security and interoperability requirements of enterprise environments, which is why integrating MCP servers with a central enterprise IdP is quickly becoming a baseline requirement. As developers on r/AI_Agents have documented, the default Claude Code setup grants access to environment files, build output directories, and infrastructure config files without any deliberate grant from the developer. In an enterprise context, “nobody set limits” is the audit finding, not the prelude to one.
While homegrown tooling may suffice for small teams, enterprise adoption is hindered by the current MCP Authorization specification, which relies on OAuth RFCs that are not widely implemented among established IdPs. Enterprises prefer to use their existing identity providers for authentication and authorization, aligning with established security practices and reducing friction for large-scale organizational implementations.
To enhance mcp security, enterprises should implement policy-driven access control that considers user identity, agent identity, and the context of each request, rather than relying solely on claims in bearer tokens.
The MCP Security Gap Is Structural
OAuth adoption across MCP server implementations remains low, and the CVE pipeline for agent tooling has begun filling in. These are not isolated incidents from careless developers. They reflect a structural gap between how credentials flow through agentic systems by default and what enterprise security frameworks require. Integration with identity providers is essential, and enterprises strongly prefer using established identity providers (IdPs) for secure authentication and authorization, as these trusted IdPs form the backbone of robust access management.
Homegrown tooling patches individual surfaces. It does not produce consistent policy enforcement across teams, integrate with existing identity providers, or generate the audit trail that compliance frameworks demand. Every team that builds its own solution builds it differently, which means security teams inherit a patchwork of controls with no shared visibility into the aggregate exposure. The MCP authorization specification should align with enterprise requirements and established identity management practices to ensure secure and scalable adoption.
Session hijacking can occur when unauthorized parties obtain a session ID, so MCP servers must use secure, non-deterministic session IDs and verify all inbound requests to prevent such attacks.
What Purpose-Built MCP Governance Looks Like
The pattern that addresses MCP security at an organizational level centers on a single chokepoint: a gateway that sits between your agents and every MCP server they connect to. All OAuth flows run through it. All credentials live in a vault the model cannot browse. Per-tool access policies enforce least privilege consistently, across teams, without relying on individual developers to configure their own sandboxes. Robust security controls, including strong authentication and authorization, are enforced at the gateway to mitigate vulnerabilities and ensure secure access, mirroring the Obot MCP architecture for secure, scalable hosting and gateway control.
That architecture also generates something the DIY approaches structurally cannot: a unified audit trail. When a security team asks which agent accessed which tool at which time, the answer exists and is queryable. When a policy changes, it changes once, at the gateway, and applies everywhere. MCP servers can integrate with external OAuth providers like Keycloak to handle authentication and token issuance, acting as an OAuth relying party that verifies tokens and enforces scope checks.
OAuth 2.1 is the recommended framework for secure access to MCP servers, and the OAuth 2.1 Authorization Code flow with PKCE should be used for secure token issuance and validation.
From Pattern to Platform
Obot MCP Gateway is the open-source realization of this architecture. It handles OAuth for all connected servers centrally, stores credentials outside the model’s context window, enforces per-tool access policies across agent sessions, and maintains the audit logs that compliance frameworks require. During the OAuth authorization process, a consent screen is presented to users, allowing them to explicitly approve the requested scopes before an access token is issued by the authorization server. Where Factorly runs on one developer’s laptop and a Docker sandbox scopes one environment, Obot MCP Gateway operates at the organizational layer, giving security teams the aggregate visibility that individual tools cannot compose into.
A developer building on Obot does not need to solve MCP authentication from scratch, manage credential injection manually, or hope that every teammate remembers to configure their local vault. The governance is built into the platform they are building on. Capability-level permission scoping, Identity and Access Management (IAM), and Zero Trust architecture are enforced to align user roles and AI agents with specific tool capabilities and to secure direct pathways for AI connections, the same criteria that differentiate the best MCP gateways for enterprise teams as this ecosystem matures.
Try It Before the Window Closes
Practitioners are already patching the gap by hand. Enterprises scaling MCP deployments will inherit those patches, or something worse, unless purpose-built infrastructure is in place first.
Obot’s MCP server catalog is the practical starting point. Browse the available integrations, connect your first server through the gateway, and see what credential governance looks like when it is designed in rather than bolted on. The gateway can also integrate with existing APIs, allowing organizations to centralize security management and ensure consistency across multiple MCP servers. See the following diagram for an illustration of how the integration process works.
MCP security can also streamline compliance with regulatory standards by providing immutable audit trails and anomaly detection, and broader learning resources on MCP gateways, authentication, and catalogs are emerging to help teams adopt these patterns correctly the first time.
The Window Is Closing on MCP Credential Risk
The independent builders who shipped encrypted vaults, sandbox tooling, and transcript scanners this spring were signaling that the default MCP architecture has a structural problem that individual discipline cannot reliably fix. The community has already diagnosed the exposure. Enterprise security teams are next to notice.
Getting purpose-built MCP security infrastructure in place before that audit conversation happens is measurably easier than retrofitting governance after a breach surfaces what the config files contained all along. The Model Context Protocol (MCP) and its security framework provide a universal governance and control plane that enables safe connections between AI agents and enterprise data, addressing risks, attack vectors, and best practices for secure MCP authorization flows and server operations. The Obot MCP Gateway is where to start: centralized OAuth, credential vaulting, per-tool access policies, and unified audit logs, the control plane that homegrown tooling cannot compose into, built for the teams who need it to work at scale.
