Notifications
Clear all
Topic starter
18/08/2026 2:46 pm
TL;DR: Lakera scanned roughly 46,500 npm packages and found credentials in Claude’s config directory across 30 of them, showing that MCP defaults can expose API keys, OAuth tokens, and transcripts through ordinary developer workflows, according to Obot. The issue is not accidental leakage but a governance model that lets the agent read the secrets it needs to operate, which breaks traditional vault-and-injection assumptions.
NHIMG editorial — based on content published by Obot: MCP security risks, transcript exposure, and governed gateway controls
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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
👉 Read Obot's analysis of MCP credential exposure and gateway controls →
MCP config files and transcript logs: are your controls keeping up?
Explore further
18/08/2026 3:28 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP credential exposure is a structural governance problem
