Logging every Google Drive MCP server file access as HIPAA audit evidence

What counts as PHI-relevant file access

The audit controls standard, 45 CFR 164.312(b), requires hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information. A Drive folder that holds clinical notes, claims exports, or patient correspondence is such a system. An MCP server that reads from it becomes another route to that information.

NIST SP 800-66r2 lists the activities an entity should consider auditing: creating, accessing, modifying, transmitting, and deleting ePHI or the files and records that contain it. Mapped to a Drive MCP server, that means at least four operations: listing folder contents, searching, reading file content, and exporting or downloading. Listing and searching deserve attention because results can expose file names and snippets that themselves contain PHI, even when no file is opened.

The same guidance says audit scope should come from the regulated entity's risk assessment. Write down which MCP operations you treat as ePHI access and why. Exclusions should be explicit and justified, not an accident of what the server happens to log. This page is a technical walkthrough, not legal advice.

What each evidence source captures and misses

Three sources are usually available. They answer different questions, and the gaps matter when you must show an auditor what an AI was allowed to access and what it actually accessed.

• Source-system logs (Drive and Workspace): Strength: an independent record of activity as the source system saw it. Gap: it sees the credential the MCP server presented. If that is a shared service account or delegated OAuth identity, the record does not by itself name the end user, the AI client, or the tool call. It also holds no record of policy decisions.
• MCP server application logs: Strength: closer to the tool call, so they can carry tool name and arguments. Gap: content and format are whatever the implementation chose, coverage may vary by tool, and the system being audited controls them. They rarely record what policy applied or why a request was permitted.
• Enforcement in the execution path: Strength: sees user, client, tool call, decision, and outcome together, and can record denials that never reach the source system. Gap: it only covers traffic routed through it, so completeness depends on there being no path around it.

Where to capture the record

Capture at the point where the tool call is made and its result returned. That is the only place that can bind a human requester, an AI client, a specific call, and an outcome in one record. Reconstructing the same picture afterward by joining source-system logs to server logs by timestamp is fragile, especially when many users share one credential.

Three design rules follow. First, the capture point must cover every supported MCP transport and every tool, not a selected subset. NIST SP 800-53r5 frames completeness this way: event logging should include all protocols that are operational and supported by the system. Second, record both identities. NIST SP 800-204B separates a service's runtime identity from end-user authentication, and the NCCoE concept paper on AI agent identity points to linking agent actions to a non-human identity. Recording the service or agent identity alongside the human requester is an inference from that guidance, but it is the combination that makes the record attributable. Third, write records to a central store that the audited system cannot alter. NIST SP 800-209 recommends central collection, such as syslog servers or cloud logging services, which lowers the risk of logs being lost or changed.

Retention, completeness, and review

The text of 164.312(b) does not prescribe fields, tooling, or a retention period. You have to justify your design from the risk assessment. Set retention deliberately, record who decided it, and make sure the setting is enforced where the records are stored. If data residency matters for your environment, decide where the evidence store lives before deployment.

Test completeness rather than assuming it. NIST SP 800-66r2 asks whether an audit trail is established for all accesses to the information, and what mechanisms will assess the effectiveness of the audit process. A practical test is reconciliation: compare the access activity the source system reports for the MCP server's credential with your enforcement records. Any source-side event with no matching record points to a bypass path, an unmonitored tool, or a capture failure. Run it on a schedule and track the mismatch count as your effectiveness measure.

Collecting records is not the end of the job. HHS guidance says covered entities and business associates should review and secure audit trails and use proper tools to collect, monitor, and review them. Set review frequency from the risk assessment and produce exception reports, such as blocked requests, unusual export volume, or access outside expected users. Remember that the audit trail can itself expose PHI, so limit who can read it and avoid storing file content in it.

Policy decisions at the boundary, and where Trussed fits

An audit record shows what happened. A policy decision at the boundary determines what is allowed to happen. For Drive access, define decisions per operation and data type: allow a search scoped to a permitted folder, redact identifiers from a returned document, block an export of files tagged as containing PHI for a given user role. Recording the decision with each call lets you show both what the AI was permitted to do and what it did, including requests that were refused.

Trussed enforces policy in the execution path across models, agents, tools, and MCP servers, at the level of individual interactions and tool calls. Decisions are allow, redact, or block, and can also include rate limiting and escalation for human approval. Policy is enforced at runtime, not reviewed after the fact, and the enforcement itself generates audit-ready evidence mapped to HIPAA. It can be self-managed in your cloud, with configurable retention and data residency. Trussed runs in production with healthcare and pharma organizations.

The approach above does not depend on any one product. What matters is that the enforcement point sits in the path, covers every tool, and writes records to a store you control.