Redact secrets and provider errors from MCP logs

Do not claim provider-error redaction yet

The current first-party evidence does not support an absolute claim that provider errors are redacted before they reach every MCP-visible or application logging path. OfflineCreator's public privacy policy says API-key secrets are not written to application logs and describes sampled API request logs as route, status code, key identifier, and a truncated one-way hash of the network address. That is a narrow statement about key secrets and sampled audit records, not proof that prompts, signed URLs, provider response bodies, exception messages, or telemetry attributes are absent from every sink.

The pinned public MCP source exposes a separate boundary that needs remediation or a documented safety proof. Its API client reads a non-success Studio response, retains the parsed response body on `StudioApiError`, and derives the error message from a body `error` string when present. The server then serializes that message, HTTP status, and `details: error.body` into an error tool result. A tool result is not itself an application log, but an MCP client may display or persist it. Therefore the current evidence cannot support “provider errors are redacted” across the end-to-end MCP path.

Treat redaction as an output policy applied before data reaches either logs or tool results. OWASP says access tokens, passwords, connection strings, encryption keys, and other primary secrets should usually not be recorded directly. The MCP logging specification separately forbids credentials, secrets, personal identifying information, and attack-helpful internal details in log messages. These constraints support an allowlist and negative tests; they do not establish that OfflineCreator currently passes those tests.

Keep

Operation code, coarse status, correlation ID, and bounded timingChoose fields from a reviewed allowlist and document the troubleshooting purpose of each one.

Transform

Stable identifiers only when correlation is necessaryPrefer deletion; use keyed or otherwise reviewed pseudonymization only when the residual linkability is accepted.

Exclude

Credentials, payloads, signed URLs, and raw provider errorsDo not let an exception object's default serialization decide what leaves the process.

Map the application paths the source actually exposes

Three source-backed paths are visible. First, the privacy policy describes sampled API audit records and expressly says API-key secrets are not written to application logs. Second, the public MCP client converts a non-success Studio response into a `StudioApiError` containing the parsed body, and the MCP server includes that body in its error result. Third, the stdio entry point writes the configured API base to `stderr` when it connects and writes an uncaught `Error.message` to `stderr` when startup fails. The last path has no documented sanitizer in the cited entry-point source.

The MCP protocol surface is also changing. In the 2026-07-28 specification, protocol logging is deprecated for new implementations; the stated migration is `stderr` for stdio or OpenTelemetry for structured observability. Existing request-scoped notifications remain specified during the lifecycle window. A review must therefore cover the published package's tool-error result and stderr paths as well as remote request audit records, application provider adapters, exception handlers, traces, collector exports, proxy logs, crash reports, and the final backend.

Only the first three paths have current reachable first-party URLs in this research. Server-side generation logging, deployed logger configuration, exporter configuration, final-sink views, and retention queries still require externally reviewable evidence. Keep those stages as blocking gaps instead of extending the privacy-policy statement beyond its text.

MCP process

Logger calls, stderr, notifications, and crash outputExercise every transport and verbosity mode that production permits.

Application boundary

Middleware, provider adapter, exception handler, and response mapperCheck both success metadata and each failure branch before serialization.

Telemetry boundary

SDK attributes, collector processors, exporters, and backend viewsVerify the final exported record rather than assuming an earlier filter ran.

Define field rules before choosing a masking pattern

Use an allowlist for structured keys and a deny pattern only as a second layer for unexpected values. A key named `error`, `message`, `url`, `headers`, or `details` is too broad to approve without a schema. Normalize provider failures into application-owned fields such as `provider_status_class`, `operation_code`, `retryable`, and `correlation_id`; keep the raw provider body out of ordinary logs. Return a separate stable client message and an opaque support identifier. OWASP's error-handling guidance recommends a generic response for unexpected errors while keeping diagnostic detail server-side, and RFC 9457 requires careful scrutiny of generated problem details.

Do not assume hashing makes data anonymous. OpenTelemetry's current sensitive-data guidance warns that hashes of small, predictable input spaces can be reversed in practice. If correlation is required, document the threat model, input domain, key management, rotation, and retention; otherwise delete the value. Truncation can be appropriate for coarse network or time information when the remaining precision is sufficient. Never truncate a bearer token or API key and keep the prefix as a display convenience: even a fragment can reveal credential type or become sensitive when combined with other records.

If telemetry passes through an OpenTelemetry Collector, pin and test the actual component version. The v0.156.0 contrib redaction processor documents allowlisted attributes, blocked key and value patterns, masking or hashing, and audit summaries; it marks log support as alpha. Its allowlist removes unauthorized attributes before blocked-value checks, and ignored keys bypass redaction. Those semantics mean a permissive ignored-key rule or an incorrect allowlist can defeat the intended policy.

Delete

Raw secrets and payload fields with no troubleshooting purposeThe safest retained secret is no retained secret.

Normalize

Provider failures into owned status and operation codesKeep diagnostic meaning without copying an upstream body or exception string.

Pseudonymize

Only identifiers needed for an approved correlation useRecord the method, key controls, residual linkability, rotation, and retention.

Use the observed gaps to define reproducible cases

Start with a synthetic Studio error response because the public client and server sources make that case concrete. Configure a test fetcher to return a non-success status with distinct, nonfunctional canaries in the body `error` field, a nested `details` field, and a URL-like field. Invoke an MCP tool through the real handler. The current source predicts that the client will retain the parsed body and the server will place it in the tool error result. A passing redaction control must instead return only an application-owned code, coarse status, and opaque correlation identifier while the canaries remain absent from the tool result.

Run a separate stdio startup failure with a synthetic exception message. Inspect captured `stderr` and assert that the canary is absent, because the cited entry point currently passes an uncaught `Error.message` directly to `console.error`. Then trigger controlled provider 400, 401, 403, 429, timeout, malformed-response, and unexpected-500 branches. The complete test must inspect the MCP result, stderr, application logs, traces, collector output, crash reporting, proxy logs, and the final observability search. Passing an audit-payload unit test alone cannot establish the final-sink result.

Test structure as well as strings. Include a multiline value containing carriage return and line feed characters, an object nested several levels deep, an array, mixed-case header names, percent-encoded text, and a secret split across fields. OWASP's logging guidance calls for sanitizing event data to prevent log injection and testing logging failures, access controls, and unintended side effects. A regular expression that masks one token shape in a flat message is not evidence that nested objects, alternate encodings, exception causes, or framework-generated metadata are safe.

Preserve a non-secret test receipt: application version, policy version, transport, sink names, injected canary class, triggered branch, expected retained fields, observed result, and reviewer. Do not attach the raw secret-shaped payload to the ticket or snapshot. Run a negative control to confirm useful fields still arrive, then temporarily disable each sanitizer in a test environment to prove the test can detect leakage. This guards against a false pass caused by a sink that was never receiving records.

Provider error text deserves its own assertion. Treat the upstream status, headers, body, request identifier, SDK exception, and chained cause as separate inputs. Map only approved fields into the application event and client response. OWASP and RFC 9457 support separating generic client-facing errors from scrutinized internal diagnostics; neither source establishes that a particular provider's error body is safe to copy.

Case A

Synthetic bearer canary in an upstream 401Assert absence from the client result, exception chain, stderr, logs, traces, exports, and backend search.

Case B

Prompt and signed-URL canaries echoed by a provider 400Assert that only normalized status, operation code, retry state, and opaque correlation remain.

Case C

Nested multiline canary in an unexpected exceptionAssert recursive sanitization, injection resistance, bounded output, and a generic external error.

Continue from redaction to access and minimization

Redaction is one control in a larger logging boundary. Continue with the MCP security guide to review transport, authentication, and server trust; use the analytics minimization guide to decide which events should exist at all; and use output access control for generated media and signed links. The current MCP specification also requires controlling log access and monitoring for sensitive content, so protect retained records and their search interface instead of treating sanitized text as public.

Evidence boundary and remaining gaps

The evidence supports only a narrow application claim: OfflineCreator's policy says key secrets are not written to application logs and identifies fields in sampled API audit records. The pinned public MCP source simultaneously shows unsanitized Studio error bodies entering tool error results and uncaught startup messages entering stderr. Those findings do not prove that a secret has leaked in production, but they block an end-to-end provider-error-redaction claim until a fix or an effective upstream guarantee is documented and exercised.

The reachable first-party package test covers server metadata and tool annotations, not provider-error bodies, stderr redaction, or final sinks. Keep community anecdotes, prevalence statements, adoption claims, customer outcomes, and claims that a community was quiet out of this page. Before publication, require a safe synthetic-canary result across the actual deployed logger, MCP result, stderr, telemetry exporter, and final searchable sink; without it, this researched page must remain a degraded, unreviewed draft.