Audit Logging in MCP: Optional, Inconsistent, and Leaky

Your MCP server returns a database credential in a tool response. The LLM reads it, uses it, and the conversation continues. Where did that secret go? Into your logs—unredacted, timestamped, ready for the next breach.

MCP treats audit logging as a utility feature: optional, implementation-specific, and entirely disconnected from security requirements. Tools return sensitive data. Servers may or may not log it. There's no standard for what gets captured, how long it persists, or who can access it. For organizations subject to SOC 2, HIPAA, or PCI-DSS, this isn't just inconvenient—it's a compliance gap that makes MCP unsuitable for regulated workloads.

Logging as an Afterthought

The MCP specification doesn't require audit logs. Servers may implement logging, but there's no guidance on what to capture, how to structure it, or how to protect it. The protocol defines rich tool schemas, resource patterns, and prompt templates—but audit events? Left to the implementer.

This creates three problems:

1. Inconsistent coverage: One server logs every tool call. Another logs errors only. A third logs nothing. There's no baseline for observability.
2. Secret leakage: Tool responses often contain credentials, API keys, tokens, or PII. Without structured redaction, these land directly in logs.
3. Tamper risk: Logs stored in flat files or application databases can be modified or deleted without trace, destroying forensic value when you need it most.

For debugging or development, this loose approach might suffice. For production systems—especially those handling regulated data—it fails every requirement.

What Audit Logs Actually Require

Security and compliance frameworks agree on core logging principles. SOC 2 requires tracking who accessed what data and when. HIPAA (45 CFR § 164.312(b)) demands audit trails for all electronic protected health information (ePHI) access. PCI-DSS 4.0 Requirement 10 mandates detailed logging of cardholder data environments with tamper-evident storage.

These frameworks converge on several non-negotiable requirements:

Mandatory capture: Systems must log authentication, authorization decisions, data access, configuration changes, and privileged operations. "Optional" logging is not compliant.

Tamper resistance: Logs must be immutable or append-only. Centralized, write-once storage with cryptographic verification ensures logs can't be altered post-incident.

Secret redaction: Sensitive fields—credentials, tokens, PII, cardholder data—must be masked or excluded before log persistence. Raw secret values never reach storage.

Retention and lifecycle: Logs must persist for regulatory periods (often 1-7 years) with automated archival and deletion schedules.

Access control: Audit logs are sensitive. Only authorized roles (security teams, auditors) should read them; nobody should modify them.

Queryability: Logs must support investigation. Structured formats, indexing, and search capabilities are essential for incident response and compliance audits.

MCP provides none of this. The protocol doesn't define audit events, retention policies, redaction mechanisms, or tamper-proof storage. Each server implementation starts from zero, and most stop there.

Secret Leakage Through Tool Responses

The most immediate risk: tools return secrets, and those secrets flow through the protocol into whatever logging layer exists—if any.

Consider a database query tool. The LLM asks for connection details. The tool returns:

{
  "content": [{
    "type": "text",
    "text": "Connection string: postgresql://admin:xK9$mP2zQ@prod-db.internal:5432/users"
  }]
}

That credential is now in three places:

1. Tool response: Visible to the LLM and logged by the server (if logging is enabled).
2. LLM context: The model sees it and may echo it in subsequent messages.
3. Application logs: If the client logs full message payloads, the credential persists there too.

MCP has no mechanism to flag sensitive returns or trigger redaction. The protocol doesn't distinguish between "query succeeded" and "here's a root password." Tools can add hints—structured fields, content type markers—but there's no standard, no enforcement, and no guarantee the server will respect them.

The same issue applies to API keys in requests.get() responses, tokens in OAuth flows, PII in customer records, or any other sensitive data a tool might retrieve. Without protocol-level redaction hooks, every tool becomes a potential leak vector.

No Standardized Audit Trail

Even when servers log events, there's no common schema. One server logs JSON-RPC method names. Another logs tool invocations with arguments. A third logs nothing but errors.

This fragmentation breaks observability. If you run multiple MCP servers—say, one for database access, one for cloud APIs, one for file operations—there's no unified audit trail. Each server logs differently (or not at all), and correlating events across them requires custom parsing, timestamp alignment, and fragile integration code.

For incident response, this is a disaster. When an attacker uses MCP tools to exfiltrate data, you need a complete timeline: which tools were called, with what arguments, by whom, and what they returned. Fragmented logs make this investigation slow, error-prone, and often incomplete.

Compliance auditors expect structured, queryable audit logs with standard fields: timestamp, principal (user/agent), action, resource, outcome. MCP doesn't provide this. Each deployment reinvents it—or skips it.

Compliance Gaps in Practice

Let's map MCP's current logging posture to common compliance requirements:

SOC 2 Type II:

• Requirement: Log all access to customer data with user attribution and timestamps.
• MCP gap: No requirement to log access. No standard user/agent identity in logs.

HIPAA (45 CFR § 164.312(b)):

• Requirement: Implement audit controls to record and examine ePHI access.
• MCP gap: Logging is optional. No guidance on what constitutes "access" in tool calls.

PCI-DSS 4.0 (Requirement 10):

• Requirement: Log all access to cardholder data with immutable storage and daily review.
• MCP gap: No immutability, no standard schema, no retention policy.

GDPR Article 30:

• Requirement: Maintain records of processing activities for personal data.
• MCP gap: No mechanism to identify or log personal data in tool interactions.

Organizations deploying MCP in regulated environments must build an entire audit logging layer around it. This is engineering-intensive, error-prone, and fundamentally reactive—patching a protocol that didn't prioritize compliance from the start.

Defense: Structured Audit-by-Default

Fixing this requires protocol-level support for mandatory, standardized audit logging with secret redaction.

1. Define audit event schema

The protocol should specify required audit fields for all tool calls:

• timestamp: ISO 8601 timestamp of the event
• principal: User or agent identity (session token, API key, or delegated credential)
• tool: Tool name invoked
• arguments: Tool arguments (with sensitive fields redacted)
• outcome: Success, failure, or error
• response_summary: High-level summary, not raw response
• sensitive_fields: List of redacted field names for forensic context

Servers must emit this schema for every tool invocation. Clients can extend it but cannot omit required fields.

2. Secret redaction hooks

Tools should declare sensitive fields in their schemas:

{
  "name": "database_query",
  "inputSchema": {
    "properties": {
      "connection_string": {
        "type": "string",
        "sensitive": true
      }
    }
  }
}

Servers redact these fields before logging. Instead of "connection_string": "postgresql://admin:xK9$mP2zQ@...", logs show "connection_string": "[REDACTED]". The tool still receives the real value; only the log is masked.

Response redaction is harder—tools return unstructured text—but servers can apply heuristics:

• Regex patterns for common secrets (API keys, tokens, connection strings)
• Truncation: log the first 100 characters of responses, not the full payload
• Opt-in verbosity: tools that need full response logging must explicitly declare it

3. Tamper-proof storage

Audit logs must be append-only and cryptographically verifiable. Servers should write to:

• Immutable storage: S3 Object Lock, GCS retention policies, or specialized audit stores like AWS CloudTrail or Azure Monitor Logs
• Cryptographic hashing: Each log entry includes a hash of the previous entry, creating a tamper-evident chain
• Separation of concerns: Log storage is decoupled from application storage. Attackers who compromise the MCP server cannot modify logs.

This isn't exotic. Many security-critical systems (Certificate Transparency, blockchain, Merkle trees) use append-only logs with cryptographic proofs. MCP should borrow these patterns.

4. Retention and lifecycle

The protocol should support configurable retention:

• Short-term (7-90 days): Hot storage for incident response and debugging
• Long-term (1-7 years): Cold storage for compliance and legal hold
• Automated deletion: After retention expires, logs are deleted according to policy

Servers expose retention configuration, and clients can query it to verify compliance alignment.

5. Access control and auditability

Audit logs are sensitive—they reveal system usage patterns and may contain residual PII. Access should be:

• Read-only for most users: Even admins cannot modify logs
• Restricted to security roles: Only security teams, auditors, and compliance officers can view audit logs
• Itself audited: Reading audit logs generates its own audit event (the "audit of audits")

This prevents insider threats and ensures log access is traceable.

Rafter: Audit-as-a-Service

At Rafter, we're building audit logging as a first-class MCP feature. Every tool call generates a structured audit event with automatic secret redaction. Logs are written to immutable storage with cryptographic chaining, making tampering detectable. Retention policies enforce compliance requirements, and access control ensures only authorized roles can query logs.

Our approach:

• Zero-config defaults: Audit logging is enabled by default with secure defaults. You opt out, not in.
• Secret detection: Pattern-based and schema-driven redaction catches credentials before they hit storage.
• Queryable audit store: SQL and full-text search over structured events. Answer "who accessed X" or "what did this tool return" in seconds.
• Compliance templates: Pre-configured policies for SOC 2, HIPAA, PCI-DSS. Map regulatory requirements to audit queries automatically.
• Tamper-proof chain: Each log entry hashes the previous one. Breaks in the chain trigger alerts.

Audit logging isn't a feature. It's a requirement. We're making it easy to get right.

Conclusion

MCP's logging story is a compliance liability. Optional, inconsistent, and leak-prone, it leaves organizations to retrofit audit trails onto a protocol that didn't anticipate them. Secrets flow through tool responses into logs. Event schemas vary across servers. Tamper resistance is absent.

For regulated workloads, this is a blocker. SOC 2, HIPAA, and PCI-DSS aren't optional, and neither are their logging requirements. MCP deployments in production need mandatory audit events, secret redaction, immutable storage, and queryable trails—all missing from the current specification.

The fix is achievable: standardized audit schemas, redaction hooks, tamper-proof storage, and retention policies. These aren't exotic features. They're table stakes for security-critical systems. MCP should adopt them before enterprises do it themselves, badly, in thousands of incompatible ways.

Until then, every MCP tool call is a potential audit gap—and a compliance risk waiting to materialize.