How to Prove to Examiners Which Client Files an Agent Read Through a Model Context Protocol Server

Start with the examiner's question

When an AI agent reads client files through a Model Context Protocol (MCP) server, an examiner will want to know which files were accessed, under what policy, and with what outcome. Those three questions break down into narrower ones: which resources were requested, which were returned, which were redacted or blocked, and who or what authorized the request.

Treat those questions as the design requirement and work backward to the record. NIST SP 800-171 offers a useful reference for what an audit record can contain. Revision 3 lists time stamps, source and destination addresses, user or process identifiers, event descriptions, file names, and the access control rules invoked. Revision 2 adds success or fail indications and says records should let an event be linked to the actions of an individual to the extent feasible. These are reference points for evidence design, not examiner mandates for every regulated enterprise, so confirm what your own regulators expect.

The practical consequence is that file names alone are not enough. A defensible record also shows the rule that applied and the outcome, so that it answers what the agent was permitted to do as well as what it did.

The gap between logging and evidence

Logs record that something happened. Evidence has to show what was allowed, what was denied, and why, in a form that holds up when someone challenges it. A server log that lists a file read does not say whether a policy permitted it, whether part of the content was redacted before it reached the agent, or whether the request was blocked and retried through another tool.

This is the case for enforcing policy in the execution path. When a policy decision is made at the point the call passes through, the record is created from the decision itself. It captures the access control rule invoked, the subject, the object and the context, which matches how NIST SP 800-162 describes attribute-based access decisions: the object protected, the requesting subject, the governing policies and contextual information. The record shows what was authorized and why, not an inference from later activity.

Trussed enforces policy in the execution path across agents, tools and MCP servers, with decisions to allow, redact, block, rate limit or escalate for human approval. Enforcement is at runtime, not reviewed after the fact, and the audit-ready evidence is generated by that enforcement. The scope is individual interactions and tool calls. It does not trace an entire agentic workflow end to end.

Define the per-tool-call evidence record

Define event types and record content up front, as NIST SP 800-171 Rev. 3 does with organization-defined events and content. For file access through MCP, each tool call and each resource read should produce its own record with the fields below.

Bind records to a distinct agent identity rather than a shared service account. NIST's design tenets for agent identity management list distinct agent identification first, and describe immutable evidence of the agent's identity, delegated intent and resulting actions. Record the delegated intent and the resulting action together, so the authorization and the access are never separated.

• Agent identity: A distinct identity for the agent, plus the delegating user or process where applicable.
• Requested resource: The file name or resource identifier asked for, as requested.
• Policy applied: The rule or policy version invoked for the decision.
• Enforcement decision: Allow, redact, block or escalate, with the human approval outcome if escalated.
• Returned content reference: A reference to what was returned, redacted or withheld, captured at the time of the call.
• Timestamp and outcome: Time of the decision and a success or fail indicator.

Integrity, retention and logging failure

A record an examiner cannot trust is not evidence. NIST's immutable evidence tenet describes an unbroken, tamper-evident chain of custody and an append-only body of evidence. In practice, write records to append-only storage, verify integrity on a schedule, and restrict who can alter retention settings.

Retention is organization-defined in NIST SP 800-171 Rev. 3. Derive the period from your records retention policy and the regulatory obligations that apply to the client data involved, and document how you arrived at it. Configurable retention and data residency matter here, as does the option to run in your own cloud so that evidence stays where your policies require. Trussed supports self-managed deployment in the customer cloud with configurable retention and data residency.

Decide in advance what happens if evidence generation fails. NIST names several responses, including overwriting the oldest records, shutting down the system, or stopping record generation. Each has a different evidence consequence. For tool calls that read client files, failing closed means no unrecorded access, at the cost of availability. Make that tradeoff explicitly and record the decision.

Finally, know what remains uncovered. An agent that combines data from several resources may produce a response more sensitive than any single file, a concern raised in the NCCoE concept paper on agent identity and authorization. Per-file records show each read but do not by themselves answer whether the user was authorized to receive the aggregated result. Review that risk separately, and apply least privilege and human approval to high-risk tool calls.