MCP Audit Logging: What to Record and How to Use It

MCP audit logging means recording every tool call with the caller’s identity, the tool name, the arguments, the outcome and the time, plus any approval decision. Keep secrets out of the log, store it where callers cannot edit it, and test it by answering a real question from it. An unlogged agent is an unaccountable one.

Why edge logs are not enough

A conventional gateway log tells you that a client sent POST /mcp and received a 200. In an MCP system that single line hides everything that matters: one request can be a harmless read or a message to your customers, and the difference is in the JSON-RPC body.

BusinessMCP’s security guide puts the principle in one line, which it quotes as “An unlogged agent is an unaccountable one.” The reasoning is practical. When something goes wrong, you need to answer four questions quickly: who, which tool, with what input, with what result.

The fields to capture

Field	Why you need it
Timestamp (UTC)	Ordering and incident timelines
Caller identity (key ID, user, service)	Accountability; never log the key itself
Request ID	Correlate gateway, server and upstream logs
Tool name	The core of the record
Arguments (redacted)	What the model asked for
Result status and size	Success, failure, refusal, truncated
Policy decision	Allowed, denied by allowlist, held for approval
Approver and decision time	For gated actions
Upstream system touched	Helps scoping when a source is compromised
Cost or quota units	Spot loops and runaway agents

Refusals deserve full records. A denied call by a read-only key is one of the best early signals you will get.

What to keep out

An audit log can become a liability if it collects what it should not.

• Secrets. Bearer tokens, OAuth tokens and upstream API keys must never be written. Log a key ID or a hash prefix instead.
• Raw personal data. Redact or tokenise fields such as email addresses where you can, or limit who can read the log. If you operate under data protection rules, treat the log as in scope.
• Full large payloads. Log a summary and a size, and keep a pointer to the full record in a restricted store when you truly need it.

Key takeaway: log decisions and identifiers generously, content sparingly. The log should prove what happened without becoming a second copy of your sensitive data.

Where logs should live

Send them off the gateway host as soon as possible, to a store that the gateway’s operators cannot silently alter. Whether that is a SIEM, an append-only bucket or a managed logging service is your call, but the properties are the same: durable, access-controlled, time-ordered, searchable.

For a hosted product, ask what it records and what you can export. BusinessMCP’s documentation for exposing an MCP endpoint states that every call is recorded in an audit log and that usage is limited by per-run cost ceilings and plan quotas. Exportability and retention are not described in that page, so ask before you depend on them.

Turning the log into signals

A log nobody reads is a compliance artefact, not a control. A few simple alerts catch a lot:

1. A key attempts a tool outside its policy.
2. Call volume per key jumps well above its normal pattern.
3. A tool that is normally rare is called repeatedly.
4. An approval-gated tool is requested outside working hours, if that is unusual for you.
5. A key is used from a new network location, where you can see it.
6. A connected server’s tool list changes.

Start with two or three, tune them to your traffic and add more once you trust them.

The incident questions your log must answer

Rehearse these. If you cannot answer them from your log, fix the log.

Question	Fields used
Which key made this call?	Caller identity, request ID
What exactly did the agent ask for?	Tool, arguments
Was it permitted, and by which rule?	Policy decision
Who approved the action?	Approver, decision time
What else did that key do in the last day?	Caller identity, timestamp
Did data leave through any tool?	Tool, upstream system, result size

Logging and prompt injection

Injected instructions are hard to see in the moment but often leave a pattern in the log: a reporting agent suddenly calling a send tool, a long argument that looks like it was copied from a document, a call to a tool that has no connection to the conversation. BusinessMCP’s guide on MCP prompt injection describes exfiltration through tool results, where output re-enters the model’s context. Logging the tool, its arguments and a result summary is what lets you reconstruct that chain afterwards.

Designing for the people who will read it

Logs have readers: an engineer debugging at night, a security analyst hunting for a pattern, an auditor asking for evidence. Each wants something different, and a single raw stream serves none of them well.

The engineer wants a request ID that links the gateway line to the server line and the upstream call. The analyst wants consistent field names so a query written today still works next quarter. The auditor wants proof that the log is complete and unaltered, and an explanation of what is deliberately not recorded. Decide those things up front and write them in a short logging standard: field names, redaction rules, retention, who can read and who can administer.

Structured records beat free text. A JSON line with stable keys can be filtered, counted and alerted on. Free text has to be parsed, and parsers break. Keep one record per tool call, with a separate record for each policy decision if your gateway makes more than one, such as a refusal followed by an approval request.

Finally, consider the model’s side of the story. The log shows what was called, but the reasoning that led to the call lives in the conversation, which the gateway usually cannot see. If your client or platform can record a conversation identifier, store it with the tool call so an investigator can find the matching transcript where policy allows. That link is often what turns “this key sent a message” into “this document told the agent to send a message.”

Test your audit trail

Before you rely on it, run an exercise.

1. Create a test key with a narrow policy.
2. Make three allowed calls, two denied calls and one approval-gated call.
3. Find all six in the log without asking the engineer who made them.
4. Confirm no secret appears in any record.
5. Delete the test key and confirm its history is still readable.
6. Ask someone outside the team to answer “what did this key do?” from the log alone.

If step 3 or 6 is hard, the log lacks fields or searchability.

Practical retention advice

There is no universal period. Security investigations often benefit from months of history. Legal, contractual and sector rules may require more or less, and data protection rules may require you to delete personal data sooner. Write down the decision, who made it and when it will be reviewed.

Audit logging is one layer. Pair it with a deny-by-default tool allowlist and the baseline described in MCP gateway security. For what a hosted endpoint exposes in the first place, see the published list of MCP gateway tools and judge whether each tool belongs in your logs’ scope.