How to Detect and Redact PHI in Documents Returned by the Google Drive MCP Server

Where PHI enters model context

When an assistant connects to Google Drive through an MCP server, the model does not browse files. It calls tools that list, search, and read them, and the server returns the results as tool output. That output is placed into the model's context and can be passed on to downstream tools. Anything in the returned text is now in the prompt path: clinical notes, claims files, referral letters, spreadsheets, and text extracted from scanned PDFs.

Drive sharing permissions decide which files an identity can open. They do not inspect what a file contains, and they do not limit which parts of a file reach a prompt. A service account or user that is correctly authorized to read a referral letter will return the full letter, including every identifier in it. Neither the MCP server nor the model typically applies a content check at this point.

This is why the tool response is the useful enforcement point. It is the last place where content is still a discrete, inspectable payload before it becomes model context. It also maps directly to the minimum necessary standard, which HHS guidance ties to 45 CFR 164.502(b) and 164.514(d): authorization to a file is a different question from how much of that file a given task needs.

Detection approaches and tradeoffs

No single detector covers the identifiers that appear across Drive content. NIST guidance on data protection in cloud-native applications describes combining regex and machine learning models to detect patterns and classify data in real time, then redacting, masking, or blocking according to configured policy. Dictionary methods are a common third layer. Treat all output as probabilistic, tune it on your own documents, and do not assume a detector that works on one format generalizes to another. Published analysis of automated de-identification notes that rule-based and machine learning methods often struggle to generalize across diverse data types.

• Pattern-based (regex): Strong for identifiers with fixed formats, such as phone numbers, email addresses, and structured record numbers. Weak on names, addresses, and free text. Keyword-proximity rules depend on correct proximity and can produce false positives and noise if not managed.
• Dictionary-based: Useful for known values, such as facility names, clinician rosters, or internal patient lists. Misses anything not in the list and can flag ambiguous terms that are also ordinary words. Lists need ongoing maintenance.
• Model-based entity recognition: Uses context to find names, locations, and other identifiers that have no fixed pattern. NIST describes ML-based categorization as potentially the most effective automatic method, but it requires significant setup and management, and its errors are harder to predict.

Format limits, false negatives, and what redaction does not prove

Format matters as much as method. A Google Doc or a native PDF yields text directly. A spreadsheet holds values whose meaning often depends on a column header, so a bare number or short string may only be identifying in context. A scanned image requires OCR before any detector can run, and OCR errors become false negatives: a misread name or number passes through unflagged. Define in advance what happens when extraction fails or confidence is low. For a PHI-bearing workflow, blocking the response is usually safer than forwarding unread content.

Context-dependent identifiers are the hardest category. A detector can find a name token and still miss a combination of details that points to one person. NIST IR 8053 defines de-identification as removing the association between identifying data and the data subject, and it documents cases where reports were re-identified by correlating them with outside sources such as news reports and death registers. The implication for this design is direct: removing detected identifiers is a risk-reduction control. It should not be described internally as de-identification unless the output has been evaluated against a defined standard.

Measure before you rely on it. Build a representative sample of your own Docs, Sheets, PDFs, and scans, label the identifiers, and track false negatives and false positives per format and per detector.

Designing the allow, redact, block decision

Keep the decision logic simple enough to explain to an auditor. Allow when no findings exist and the file is within the task's scope. Redact when findings are limited to identifiers the task does not need, replacing each with a typed placeholder so the model keeps the document's structure without the value. Block when the response contains categories the task should never receive, when extraction or OCR confidence is too low to trust, or when the document cannot be inspected at all. Where a human decision is warranted, escalation for approval is a fourth option, though it adds latency.

The policy should be keyed to the task and identity, not just to the content. A claims-review agent and a scheduling assistant have different minimum necessary needs, even when both read from the same folder. Version the policy so each decision can be traced to the rules in force at the time.

Trussed is one example of this pattern. It enforces policy in the execution path across models, agents, tools, and MCP servers, applying allow, redact, or block decisions to individual interactions and tool calls, and it generates audit-ready evidence mapped to HIPAA. Trussed runs in production with healthcare and pharma organizations. It can be self-managed in the customer's cloud, with configurable retention and data residency. The design above does not depend on any one product, but it does require that enforcement happen at runtime, not be reviewed after the fact.