Skip to main content
Version: Latest (1.9.x dev)

What the MCP audit record keeps, and what it never keeps

Every MCP call that goes through the DVARA MCP Gateway is written to an audit trail. Each entry is signed and linked to the one before it, so an entry that is changed or removed shows. The same record goes to your SIEM and your webhooks.

An audit trail is also a copy of what happened. If it held what agents sent to tools and what tools sent back, it would hold customer records, file contents and secrets, kept for years in a store that cannot be edited. OWASP lists this under MCP08, Lack of Audit and Telemetry: redact before you log, so the log is not itself a leak.

DVARA goes further than redacting. The MCP audit record never holds a tool's arguments or its results. This is a stated rule, and a test fails the build if a change breaks it.

What each call records​

  • Who called: the workspace, the user or key, and the client.
  • What was called: the server, the tool or resource, and the operation.
  • What the Gateway decided: allowed or refused, and the rule that refused it.
  • What the scans found: whether personal data was in the arguments or the result, which kinds, and which injection rules matched. Never the matched text.
  • How it went: the status, the error code, the time taken and the size of the result.
  • A fingerprint of the arguments: a one-way hash. It shows whether two calls sent the same arguments, or whether a copy someone kept is the one that was sent. The arguments cannot be recovered from it.

The same applies to everything else the MCP Gateway handles: resources, prompts, tasks, approval requests, and the questions a server asks the user.

Error messages​

When a server refuses a call, its message often repeats what it was given: "no customer with email …". The caller gets the full message, because they need it to fix the call. The record keeps the error code and notes that a message was held back. The same goes for a failed call whose message quotes the address it was sent to, and for a result refused because it did not match its schema. Messages the Gateway writes itself, such as a policy refusal, are recorded.

Enterprise only

Not included in DVARA Open Source.

What this means in an investigation​

The record answers who called which tool, when, what the Gateway decided and whether sensitive data was involved. It cannot answer what exactly was sent to the tool, or what came back.

  • For the content of a call, use the client's or the server's own logs.
  • A data-subject request finds no tool arguments or results in DVARA to return or erase.
  • To check whether a given set of arguments is the one that was sent, compare fingerprints.

Storing payloads​

DVARA does not offer to store tool arguments or results. If it does later, it will be off unless you turn it on for a workspace, kept for a period you set and then deleted, and passed through the personal-data and secret scans before anything is written. It will not be written into the signed trail, because nothing there can be deleted.

Limits​

  • Field names can carry data. When you trim tool results to the fields a tool needs, the record names the fields it saw. A result that uses data as field names, such as a list keyed by email address, puts that data in the name. This is being fixed.
  • Signed checkpoints with your own keys are not there yet. The trail is signed and chained per gateway.