DEV Community

Mads Hansen
Mads Hansen

Posted on

Audit logs become a liability when they copy every database result

An audit log can begin as a security control and end as a second database full of sensitive results.

Teams capture prompts, SQL, tool arguments, returned rows, model responses, traces, and screenshots because more evidence feels safer.

Months later, the audit system has broader access, weaker deletion rules, and no tested restoration path.

An MCP audit record should preserve what a reviewer needs to reconstruct the governed operation:

  • authenticated identity, tenant, role, and purpose
  • tool, policy, and contract versions
  • source, database role, view, and time boundary
  • row and byte counts
  • truncation, freshness, cache, and redaction status
  • operation and trace IDs

That usually does not require copying every returned value.

Classify evidence before assigning retention. Keep recent metadata searchable, move investigation evidence to a controlled warm tier, and archive only what a defined obligation requires.

Make raw payload capture exceptional, narrow, encrypted, approved, and short-lived.

Then test both directions: can you restore archived evidence, and can you prove expired evidence disappeared from indexes, caches, replicas, exports, and applicable backups?

An archive nobody can restore is not evidence. A deletion job that misses the search index is not deletion.

Full guide: MCP database audit log retention

Top comments (0)