MCP Audit Logging for Enterprise: What to Record and Review

An MCP audit log should record, for every tool call: when it happened, which identity made it, which tool, with which arguments, what came back in summary, which policy governed it and whether any approval was required and granted. Keep enough to reconstruct what an agent did, without hoarding secrets or personal data.

Why agents make logging non-negotiable

When a script misbehaves you read the code. When an agent misbehaves, the “code” was a model’s decision made from text it read, and you cannot replay that decision from source. The log is the only reliable record of what actually happened. It also deters misuse, supports incident response and is often the first thing an auditor asks for.

BusinessMCP’s security guide makes the point as a rule: log every tool call before granting any write capability. Its access control documentation adds that every call is logged with the policy that governed it, and that sensitive actions appear as approvals in the owner’s dashboard. The Enterprise page lists a workspace audit log of privileged actions, exportable as CSV, as an Enterprise-tier capability not included in Business.

What to capture

Field	Why it matters	Caution
Timestamp	Ordering and incident timelines	Use a single time standard
Caller identity (key or user)	Accountability	Never log the key value itself
Tool name	What was attempted	Include version if available
Arguments	What it was asked to do	Redact secrets and personal data
Result summary or status	Success, failure, size	Prefer summaries to raw payloads
Policy applied	Explains why it was allowed	Keep policy version
Approval record	Who confirmed an action	Record decision and time
Error details	Debugging and abuse detection	Avoid leaking internals to the model

Key takeaway: a log that cannot answer “who, what, when, under which rule, approved by whom” will fail the first real investigation.

Two kinds of logs

Distinguish tool-call logs from administrative logs. Tool-call logs record what agents did. Administrative logs record who changed keys, policies and settings. You need both: a flawless call log is useless if anyone can quietly widen a policy. The Enterprise page’s mention of an audit log of privileged actions points at the second kind. Protect the administrators with strong authentication, as covered in access control.

Retention and privacy

Logs can themselves become sensitive. Arguments and results may contain customer data, so apply the same data protection thinking you apply elsewhere. Decide retention with legal and security, delete on schedule and restrict who can read them. The privacy article discusses minimisation. BusinessMCP notes that session-recording retention on Enterprise is customer-defined, which illustrates a general point: retention should be a setting you control, not a fixed vendor default.

Review routines that actually happen

1. Daily or continuous alerts for failed authentication, spikes in call volume and calls to rarely used tools.
2. Weekly look at the top tools and keys by volume.
3. Monthly review of approvals: what was requested, what was rejected and why.
4. Quarterly access review comparing keys, policies and recent use; revoke what is idle.

Name an owner for each. Unowned reviews are skipped.

Testing that your logs are complete

• Make a call with a restricted key and find it in the log within a minute.
• Make a call that policy blocks and confirm the denial is recorded.
• Trigger an approval and confirm both the request and the decision appear.
• Change a policy and confirm the change is logged with the actor.
• Export the log and open it in your analysis tool.

If any test fails, treat the platform as uninstrumented for that path.

Getting logs into your own tools

Ask whether logs can be exported or streamed to your SIEM or data warehouse. An export-only log in a vendor dashboard is better than nothing but poor for correlation. If export is manual, schedule it. Checking the vendor’s stated capability on the Enterprise page against your own requirement is a quick first screen for this.

Common mistakes

Logging everything, including secrets; logging nothing about denied calls; storing logs where agents or ordinary users can read them; and keeping them indefinitely by default. Fold these lessons into the broader checklist and the readiness test.

Logs as a source of product insight

Beyond security, logs show how agents actually behave, which is rarely how you expected. Tools that are never called may have confusing descriptions. Tools that fail repeatedly may need better error messages. Sequences that repeat may deserve a purpose-built tool. Review these patterns monthly and feed them back to the owners of each server. The same data supports cost control, since run counts per key reveal which agents drive spend. Used this way the log earns its storage cost twice: once as evidence and once as feedback. For a sense of how one vendor frames per-key logging and scoped keys, see its MCP hosting overview.

Handling denied and suspicious calls

Successful calls are only half the story. A denied call tells you an agent tried something outside its scope, which is either a misconfigured policy or a sign of manipulation. Record denials with the same detail as successes and alert on patterns: repeated attempts at the same forbidden tool, calls at unusual hours, a sudden jump in volume from one key or a new tool appearing in a key’s history. When you investigate, work backwards from the call to the conversation that produced it, if your client keeps one. Where an injection is suspected, preserve the evidence before revoking anything, then revoke the key, review what it touched and tighten the policy that allowed the reach.

Sampling and cost of logging at scale

Agents can make thousands of calls a day, and full logging has a price. Keep complete records for write and approval events, and consider summaries or sampling for high-volume read calls, provided denials are always kept in full. Compress and tier older data, and set deletion by schedule. Make sure that sampling decisions are documented and agreed with security, so that an investigation never discovers a gap that nobody knew existed.