MCP Credentials and Logs: Four Boundaries Before Redaction
A credential injected through the environment can spread through processes, child processes, API requests, and logs. Redaction is a final safeguard; scope, inheritance, storage, and log access remain separate controls.
Read in JapaneseRemoving a credential from an MCP configuration file does not protect it once the value is injected through the environment. The MCP process can read it, and so may child processes, outbound API code, exception handlers, stdout, stderr, and log collectors. Each is a new trust boundary. Redaction can reduce accidental display, but it does not replace access control to the credential or revocation after exposure.
Four boundaries a credential crosses
| Boundary | Required restriction | Impact when it fails |
|---|---|---|
| Secret store → MCP launcher | Inject only the credentials required by that server | Unrelated servers receive the same secret |
| Launcher → process and child processes | Allowlist inherited environment names | Packages, hooks, or child commands inherit unnecessary credentials |
| MCP server → external API | Bind to the intended resource and minimum scope | Credential reaches another API or excessive operations |
| Process → stdout, stderr, and logs | Avoid emitting values; restrict readers and retention | Logs become a reusable credential store |
Consider a SEARCH_API_TOKEN needed by one search MCP. Placing it in the client's entire login environment may expose it to every server launched by that client. Injecting it only into the intended server is narrower, but an environment dump, an error containing HTTP headers, or complete environment inheritance by a child process broadens the boundary again.
Passing a secret on a command line can create another copy in process listings or audit records. Environment injection avoids that particular copy; it does not stop code already running in the process from reading or transmitting the value. The relevant question is which code executes inside the credential-bearing process and which destinations that process can reach.
Token theft in the current specification
The MCP 2026-07-28 Authorization Security Considerations state that an attacker who obtains tokens stored by a client or cached or logged by a server can access protected resources with requests that appear legitimate. Clients and servers must use secure token storage. Short-lived access tokens and refresh-token rotation for public clients reduce the useful lifetime of an exposed credential.
Those requirements directly govern OAuth tokens. MCP Guard recommends applying the same operational boundary to API keys, database credentials, and cloud credentials. Their formats differ, but logging any reusable value expands the readers, systems, and retention periods that can expose it.
Redaction limits and acceptance evidence
GitHub's Actions security documentation explains that automatic redaction is not guaranteed for transformed or structured secrets. Its compromised-runner guidance is more direct: log redaction is not a security boundary. Exact-value masking can miss split values, encodings, derived tokens, or a differently formatted Authorization value. Code able to read a secret may also send it over the network without using logs at all.
Before connection, verify the actual launch path and every log destination. The following evidence is an MCP Guard operational recommendation, not a logging format required by MCP:
- a server-specific credential with minimum scope, intended resource, owner, and revocation method;
- an allowlist of environment names inherited by child processes, with unrelated variables absent;
- no credential or Authorization header in success, authentication-failure, timeout, and upstream-error output;
- readers and retention for stdout, stderr, application logs, collectors, and error tracking; and
- an incident path for log deletion, credential revocation and rotation, and exposure-window review.
Use a dedicated canary rather than a production credential when testing redaction. A successful mask is not sufficient acceptance evidence: confirm that the source value is not emitted and that log access is independently restricted. Require remediation and credential rotation before connection when a server inherits a broad login environment, dumps all environment values, or leaves long-lived tokens in logs.
Scope and sources
This design analysis uses the MCP 2026-07-28 Authorization Security Considerations, official Security Best Practices, and GitHub Actions secure-use and compromised-runner documentation reviewed on September 22, 2026. It does not report a secret leak, inspect an individual server's logs, or claim a product CVE. The table and non-OAuth credential acceptance evidence are MCP Guard recommendations derived from the public requirements.