Logging every filesystem and browser MCP tool call as audit evidence

Why evidence is a design requirement

Agents use filesystem MCP servers to read, write and list files, and browser MCP servers to navigate pages, submit forms and extract content. Each call can touch sensitive data or trigger a consequential action. An auditor will ask what the agent was permitted to do and what it actually did. Those are two different questions, and a record has to answer both.

Server-side logs rarely answer them on their own. Formats differ between servers, files sit on separate hosts, and an administrator of the server can usually edit them. They often lack the calling identity, the policy decision, or the arguments and results. Rebuilding that picture after an incident from scattered sources produces evidence that is incomplete and hard to defend.

General log management guidance points the same way. Audit-related data is most useful when it records which accounts performed which actions, when baseline logging is set for all systems and a higher level for critical ones, and when logs are sent to central servers, which lowers the risk of loss or alteration. For MCP, define the evidence first, then choose where to capture it. Decide which calls are critical: writes, deletions, form submissions and access to sensitive paths or domains deserve the fullest record.

Define the minimum evidence schema

Use one schema for both filesystem and browser calls so records can be queried together. The fields below are a working minimum. The differences between the two tool families sit mainly in the target and arguments fields.

• Caller identity: The agent, the human or service principal it acts for, and the session. An agent name alone is not enough to attribute an action.
• Tool and server: Tool name, MCP server identifier and version, and the operation requested, such as read, write, move, navigate, click, submit or extract.
• Target and arguments: Normalised file path for filesystem calls. Full URL, action and form field names for browser calls. Argument values are handled under the redaction rules below.
• Policy decision: Allow, redact, block, rate limit or escalate, the policy and version that produced it, and the approver and outcome where a human was involved.
• Result metadata: Success or error status, error type, bytes or elements returned, and a content hash. Record denied and failed calls, not only successful ones.
• Time and integrity: Timestamp from a trusted clock, a sequence number or correlation ID for the call, and a hash linking the record to the previous one.

Choose the capture point

There are three places to capture a tool call. The comparison below is design reasoning, not a ranking of products. The deciding factors are coverage, bypass risk, tamper resistance and consistency.

• Inside the MCP server: Sees the true effect on files or pages and can log errors in detail. Coverage depends on each server's implementation, formats differ, the operator of the server can alter records, and it has no view of identity or policy decisions unless they are passed in.
• In client or agent code: Knows the caller and the intent. Every agent framework needs its own instrumentation, a modified or unmanaged client can skip it, and the agent being audited controls the records.
• In the execution path between client and server: Every request and response passes through one point, so records share a schema and cover all agents and servers routed through it. It can record the policy decision at the moment it is made. Its limit is that traffic must be forced through it, so network and credential controls should prevent direct connections.

Retain, redact or hash: handling sensitive content

Arguments and results can contain the data you are trying to protect. An evidence store full of file contents and page text becomes another leakage path, so audit log entries holding sensitive information need their own confidentiality controls.

A workable rule has three tiers. Retain in clear the fields needed to attribute and reconstruct the action: identity, tool, operation, path or URL, decision and status. Redact values that are sensitive but not needed, such as credentials, tokens and personal identifiers in form fields or query strings. Hash content that you may later need to prove unchanged or matching, such as the body of a file read or written, so you can show what was handled without storing it.

Keep the redaction rules versioned and record in each entry which fields were redacted or hashed. Restrict read access to the evidence store separately from write access.

For retention, set periods from the regulatory obligations that apply to your organization and confirm them with compliance counsel. Preserve originals, and configure residency so evidence stays in the regions you require. For tamper resistance, write records to a central, append-only store outside the control of the agent and the MCP server, chain record hashes, use redundant destinations to avoid a single point of failure, and alert on configuration changes to the logging pipeline.

Policy enforcement as the source of evidence

When policy is enforced in the execution path, the decision and the record come from the same event. Each allow, redact, block, rate limit or escalate outcome already carries the identity, the arguments and the rule applied, so evidence is a by-product of enforcement rather than something assembled afterward. This also closes the gap between what an agent was permitted to do and what it did, because both appear in one record.

Trussed is one example of this approach. It enforces policy in the execution path across models, agents, tools and MCP servers, at the level of individual interactions and tool calls, with decisions enforced at runtime, not reviewed after the fact. The audit-ready evidence that enforcement generates is mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. It can be self-managed in the customer's cloud, with configurable retention and data residency. It does not trace end-to-end agentic workflows or govern business transactions across tasks and agents.

Whichever tooling you use, test it against the schema and completeness checks above.