AuditMCP

Local MCP audit logging without becoming a gateway

When an MCP client can call tools, the useful post-session question is often not “did it work?” but “what did it actually ask the tools to do?” AuditMCP is a local MCP audit logging proxy: it sits between a compatible client and server, records matching tool-call activity, and gives the local user a queryable audit trail rather than a transient terminal history.

It is deliberately a recorder, not a policy engine. AuditMCP forwards MCP traffic and preserves a local record of tool calls; it does not decide whether a request is authorized, scan a server for vulnerabilities, or try to become an enterprise gateway. That narrow role makes it useful when accountability matters but an extra decision point in the tool path would be the wrong tradeoff.

Why fail open?

An audit recorder and an authorization gateway have different failure modes. After AuditMCP has started successfully, a logging failure does not stop the tool call: the proxy is fail-open so that a local audit component does not become an availability dependency for the agent it is observing. A policy gateway may reasonably fail closed because blocking is its job. AuditMCP intentionally belongs to the first category, and records gaps or warnings rather than silently treating a broken log as a clean session.

Proxy first, evidence second

MCP client → AuditMCP proxy → MCP server
                 │
                 └→ local SQLite audit log → query / verify / export

AuditMCP forwards a request and response while a dedicated local write path records the matching tool call. Likely secrets are redacted before persistence, which improves log hygiene without requiring a cloud logging service. The current integrity design chains entries, uses keyed verification material, and adds heartbeats and a separate local anchor outside the database so later verification has more to compare than an isolated row.

Those mechanisms make changes harder to hide; they do not make a SQLite file invulnerable. “Tamper-evident” means verification can reveal many kinds of alteration, reordering, or missing history. It does not mean every attacker, deletion scenario, or full-machine compromise is detectable. Redaction has the same honest boundary: it reduces the chance that likely secrets are retained, but pattern and heuristic detection cannot guarantee every credential format is caught.

Where it fits

The usual setup is to wrap an MCP server command in a client configuration, then inspect the local history after a session. For a stdio server, the shape is small enough to try without a config file:

auditmcp run -- npx -y @some/mcp-server
auditmcp query
auditmcp verify

Release archives are available for supported desktop platforms, or the Rust source can be built locally. HTTP proxying is loopback-only and maps each local listener to one upstream, which is appropriate for a local audit tool rather than a remotely exposed service.

Trust boundaries and limits

AuditMCP is local-first: its normal scope has no account, telemetry service, cloud dependency, or network calls of its own. That keeps an MCP audit trail close to the person who needs to inspect it, but the database remains sensitive local evidence and should be handled accordingly.

Interactive OAuth is a real proxy boundary. A transparent local proxy changes the identity and URL a client sees, while OAuth discovery depends on those identities agreeing. AuditMCP does not rewrite that security check to make transparent proxying appear to work. Static authorization headers can pass through without being stored; interactive OAuth flows do not fit this model.

The project cannot audit a malicious client that bypasses it, and it does not enforce an allow/deny policy. For an adjacent experiment in keeping credentials off the agent host entirely, see Conveyance's separate-device approval model; that is a different trust boundary from local audit logging.

Sources and further reading

AuditMCP README (commit d10efd7) · OAuth and transparent proxies (commit d10efd7)