How do errors leak credentials in MCP?

MCP servers frequently return verbose errors — raw stack traces, failed command output, upstream HTTP responses — directly to the agent. Those strings then load back into the model's context, logs, telemetry, and conversational memory. Any secret in the error now sits on every downstream surface.

What's the official classification?

OWASP MCP01:2025 "Token Mismanagement and Secret Exposure". In classic AppSec terms, it maps to CWE-209 "Information Exposure Through an Error Message". The LLM-era twist is that the model itself becomes an unintentional secret repository via long-lived context and persisted transcripts.

How do you prevent it?

Sanitise errors at the MCP server boundary. Better, enforce it at the transport layer — strip known secret patterns (Bearer tokens, API keys, connection strings) from all tool responses before they re-enter the agent's context. Monitor for secret patterns in stored transcripts and invalidate exposed credentials.

← Attack Database

Credential leak via error messages

Updated Sun Apr 19 2026 00:00:00 GMT+0000 (Coordinated Universal Time)

Credential & data partial

Credential leak via error messages

Summary

MCP servers frequently return verbose errors — raw stack traces, upstream HTTP responses, failed command output — directly to the agent. Because those error strings are loaded back into the model’s context window and then often echoed in model output, logs, telemetry, or conversational memory, any secret the error contains is now exposed on every downstream surface. Classified as OWASP MCP01:2025 “Token Mismanagement and Secret Exposure” and, in classic AppSec terms, CWE-209 “Information Exposure Through an Error Message”. The specific LLM-era twist is that the LLM itself becomes an unintentional secret repository via long-lived context and persisted transcripts.

How it works

MCP tool wraps an upstream call. For example, a Stripe tool wraps POST /v1/charges using an API key; a database tool opens a connection using credentials from env vars; a GitHub tool forwards a PAT.
Upstream call fails. Authentication expired, rate limit hit, parse error, network error, or a malformed request.
Exception propagates unredacted. The MCP server, built like a normal Node/Python/Go service, catches the exception and returns {"error": str(e)} or the full stack trace. The response may contain:
- the bearer token in the Authorization header echoed by the upstream (“authorisation header was Bearer sk_live_...”)
- the full connection string in a DB driver exception (psycopg2.OperationalError: connection to postgres://app:p4ssw0rd@internal-db...)
- internal hostnames, IP addresses, cloud resource IDs
- pre-signed URLs containing signatures
- API key fragments in upstream error bodies
Error lands in model context. MCP protocol returns the error to the client, which includes it in the next model turn.
Leak surfaces multiply. The secret is now in: the agent’s conversation history, any transcript logging system, any prompt-caching layer, any observability tooling that captures LLM I/O, and any model reply that echoes the error to the user.

This is the “contextual secret leakage” vector OWASP MCP01 names explicitly: “MCP enables long-lived sessions, stateful agents, and context persistence, which means tokens can be inadvertently stored, indexed, or retrieved through user prompts, system recalls, or log inspection.”

Real-world evidence

OWASP MCP01:2025 — official advisory

OWASP’s MCP Top 10 lists verbose errors, unredacted logs, and context-persisted tokens as named exposure vectors. It is the most authoritative reference for this attack class as of April 2026. (OWASP MCP01:2025)

GitGuardian secrets scan of MCP ecosystem

GitGuardian reported 29 million leaked secrets in 2025, with a dedicated analysis of MCP-linked leaks. Cyata’s parallel analysis of 5,200+ open-source MCP server implementations found 24,008 unique secrets embedded in MCP configuration files, and that more than half of servers (53%) rely on long-lived static credentials. These are the tokens that appear in errors when rotation or scope-reduction hasn’t happened. (GitGuardian / Help Net Security, 14 Apr 2026; Cyata — “MCP’s Quiet Crisis”; GitGuardian blog)

Check Point — Claude Code project file RCE leaking API tokens (2025-2026)

Check Point Research disclosed CVE-2025-59536 and CVE-2026-21852: vulnerabilities in Claude Code that allow a malicious project configuration (including MCP server definitions and env vars) to achieve RCE and steal API tokens. While the primary vector is code execution, Check Point’s writeup describes the exfiltration of credentials via uncontrolled error and log paths as a contributing step. (Check Point Research)

MCP Inspector RCE (CVE-2025-49596, CVSS 9.4)

Oligo Security’s disclosure of CVE-2025-49596 against Anthropic’s MCP Inspector demonstrated that developer-facing MCP tooling itself leaks: an attacker could execute code on a developer’s machine and harvest any secret that had touched the Inspector’s logs. (Oligo Security)

Reversing Labs — ecosystem credential weakness

Reversing Labs’ MCP credential weakness analysis surveyed MCP servers in the wild and found bearer tokens and X-Api-Key values dominant, confirming that the credentials leaking in MCP errors are production-grade, long-lived, broadly-scoped. (Reversing Labs)

Note: as of April 2026 we have not found a named, reproduced incident of “MCP tool returned a stack trace containing a live API key to an agent, which then leaked it into a public transcript”. The attack class is well-documented as a risk (OWASP, GitGuardian, Cyata) but public post-mortems name the outcome (credentials in public repos, agent transcripts, log files) without naming the intermediate tool-error step.

Impact

Long-lived credential compromise. Because MCP credentials are typically static and long-lived (see OWASP MCP01), a single leak gives persistent access until the token is manually rotated.
Cross-session contamination. A secret leaked into one agent’s context window can propagate to every subsequent prompt in that conversation, including shared or templated conversations.
Transcript / telemetry blast radius. Most LLM observability tools (Langfuse, LangSmith, Helicone, Braintrust) capture full I/O by default. Errors containing secrets end up in those backends unless explicit redaction is configured.
Audit trail corruption. Errors in session history make the history itself a regulated secret store.

Detection

Regex sweep of LLM transcripts for secret patterns. Bearer [A-Za-z0-9._-]{20,}, sk_live_, AKIA[0-9A-Z]{16}, Slack xox[baprs]-, etc. Run against agent transcripts the same way you’d run it against source code.
MCP response-body size outliers. Error responses should be small and terse. A multi-kilobyte error body is almost always a stack trace.
Upstream HTTP 401 / 403 followed by large response to agent. Classic shape of “upstream auth failed, server dumped whole request back”.
Secret-scanner integration on MCP server logs. Treat MCP server stdout/stderr as you treat a CI build log.
Canary tokens in MCP server env vars. Plant a never-used credential; alert if it ever appears in an agent response.

Prevention

At the MCP server:

Never return raw exceptions. Wrap every tool handler with an error normaliser that returns {"error": "upstream_failure", "code": <opaque-id>} to the agent and writes the detail to a server-side log protected by secret scanning.
Redact Authorization, Cookie, X-Api-Key, Set-Cookie, connection-string, and PII patterns from both the response path and the log path before serialisation.
Keep credentials out of env vars that debuggers and crash dumps can reach — use a vault / keychain injector such as mcp-keyring-injector.
Use short-lived, audience-bound tokens (OAuth 2.1 + RFC 8707 as required by the MCP 2025-11-25 authorisation spec) so any leaked token expires quickly.

At the transport layer (Intercept):

Intercept can inspect tool results before they return to the agent and block or redact responses that contain credential patterns.

# Speculative example — response-side redaction rules.
# Intercept's result-inspection syntax is illustrative here.
version: "1"
description: "Strip secrets from MCP tool responses"
default: "allow"

tools:
  "*":
    rules:
      - name: "block responses containing bearer tokens"
        conditions:
          - path: "result.body"
            op: "matches"
            value: "Bearer\\s+[A-Za-z0-9._-]{20,}"
        on_deny: "Response contained a bearer token — blocked"

      - name: "block responses containing AWS keys"
        conditions:
          - path: "result.body"
            op: "matches"
            value: "AKIA[0-9A-Z]{16}"
        on_deny: "Response contained an AWS access key — blocked"

      - name: "block DB connection strings"
        conditions:
          - path: "result.body"
            op: "matches"
            value: "(postgres|mysql|mongodb)://[^\\s]+:[^\\s]+@"
        on_deny: "Response contained a DB connection string — blocked"

Non-policy controls:

Treat every MCP transcript as a regulated secret zone with the same DLP, retention, and access-control rules as CI logs.
Run secret scanners (GitGuardian, TruffleHog, trufflehog) against agent transcript stores.
Rotate MCP-bound credentials on a short cadence regardless of suspected leak.

Sources

Data exfiltration via tool chaining
Privilege escalation via admin-only tools
Session hijacking in HTTP MCP

Protect your agent in 30 seconds

Scans your MCP config and generates enforcement policies for every server.

npx -y @policylayer/intercept init

github.com/policylayer/intercept →