Audit logs are a security feature, not a debug tool
Most teams treat MCP audit logs as a debug stream. They're a security and compliance artifact. The first time you have an incident — a leaked tool, a runaway agent, an unhappy enterprise buyer — you'll wish you'd designed them like one.
Minimum field set
timestamp·request_id·user_id·workspace_idtool·input_hash·output_hash·statusmodel·latency_ms·tokens_in·tokens_out- Optional:
raw_input/raw_outputbehind an explicit opt-in.
Storage and retention
- Append-only table; no updates, no deletes.
- 90 days hot for support; 13 months cold for audits.
- Periodic hash chain for tamper evidence.
- Export to the customer's SIEM via webhook or scheduled S3 dump.
Surface in-product
- Admin-only timeline view with filters by user, tool, status.
- One-click "explain this call" that resolves hashes to redacted summaries.
- Streaming export for SIEM ingestion.
Compliance shortcut
Logs designed to SOC 2 from day one make enterprise procurement weeks shorter. Logs retrofitted under deadline make it months longer.
FAQ
- What's the minimum fields an MCP audit log needs?
- Timestamp, user_id, workspace_id, tool name, input hash, output hash, latency, status, model, and request_id. Anything less and you can't answer 'who did what when' in an incident.
- Why hash inputs and outputs instead of storing them?
- Tool inputs often contain PII or secrets. Hashing lets you prove non-repudiation (the call happened, with this exact payload) without retaining the payload itself. Store raw payloads only when the user explicitly opts in.
- How long should logs be retained?
- 90 days hot for debugging and customer support, 13 months cold for compliance audits. Longer if your buyers have regulatory mandates (HIPAA, SOX).
- Should audit logs be tamper-evident?
- For SOC 2 / ISO 27001, yes. Append-only storage with periodic hash chaining is the standard pattern; full Merkle trees are overkill for most teams.