How to Prove to an Examiner Which Customer Rows an AI Agent Read Through an MCP Server

Treat the examiner's question as a testable requirement

An examiner's question is usually simple: which customer records did this agent read, when, under what authority, and what did it receive? The useful way to handle it is as a test. Given only your evidence store, can a reviewer list the record identifiers returned to a named agent over a defined period, without consulting engineers or rebuilding the answer from other systems?

The regulatory anchors are general rather than MCP-specific. As of November 2026, the HIPAA Security Rule in 45 CFR Part 164 includes an audit controls standard requiring mechanisms that record and examine activity in information systems that contain or use electronic protected health information. It also requires procedures to regularly review records of system activity, such as audit logs and access reports. The FTC Safeguards Rule, 16 CFR 314.4, calls for regular testing or monitoring of the effectiveness of key controls, systems and procedures. Whether either applies to you depends on your organization, so map each evidence field to a duty actually in scope.

The gap is that standard application and server logs typically record the tool call, not the rows returned. They may not tie each read to an agent identity or a policy decision. Reconstructing row-level access afterward from several partial sources produces answers that are hard to defend.

The fields a tamper-resistant evidence record should contain

Define one record per tool call, written when the response is released to the agent, not assembled later. The record should be readable on its own, without joins to other systems whose retention may differ.

Integrity matters as much as content. Options include append-only or write-once storage, hash chaining of successive records, and keeping the evidence store outside the administrative reach of the MCP server and the agent's operators. Choose retention periods against the obligations that apply to you, and make retention and data residency configurable so that the record stays available for as long as an examiner may ask.

• Agent identity: A stable identifier for the specific agent, and the user or service it acted for, not a shared service account.
• Tool invoked: The MCP server and tool name, with version where available.
• Query parameters: The arguments as received, so a reviewer can see what scope the agent requested.
• Record identifiers returned: The identifiers of the customer records in the response as released to the agent, not the identifiers the data source held.
• Policy decision: Allow, redact or block, with the policy or rule that produced it.
• Timestamp: A time for the request and the decision, from a consistent, trusted clock.

Record what the agent received, not only what it asked for

A record that stores the request and the unfiltered data source result can overstate or misstate what the agent saw. The record should reflect the response after any policy action.

For an allowed read, list every returned identifier. For a redacted read, record which identifiers were returned, which fields were removed, and the rule that removed them, so the reviewer can see that the agent received a reduced view. For a blocked read, record the request, the decision and the rule, with an empty returned set. A blocked attempt is also evidence: it shows the control operated.

Be careful about the evidence store itself. If it holds full customer content, it becomes a sensitive data store that needs equivalent protection. Storing identifiers and field-level actions rather than full payloads is usually enough to answer which rows were read, and it keeps the exposure smaller.

Why enforcement in the execution path produces better evidence

Evidence reconstructed after the fact depends on whatever each system happened to keep. Evidence produced at the enforcement point is a by-product of the decision itself: the same component that evaluates the request, applies the policy and releases the response writes the record. There is no separate collection step to fall out of sync, and no gap between what was decided and what was recorded.

Trussed enforces policy on MCP tool calls in the execution path, with allow, redact, block, rate limit and escalation for human approval. Policy is enforced at runtime, not reviewed after the fact, and the enforcement generates audit-ready evidence mapped to frameworks including HIPAA, NAIC, NYDFS, the EU AI Act and NIST. It deploys self-managed in the customer cloud, with configurable retention and data residency. Its scope is individual interactions and tool calls.

Whichever tooling you use, the test stays the same. An examiner asks which rows, and your record answers it directly.