How to Filter PHI from a Slack MCP Server Before the Agent Reads It

Map the data flow before choosing controls

An agent connected to Slack through an MCP server calls tools that the server exposes. The server queries Slack and returns the results to the MCP client, which places them in the model's context. Depending on the tools enabled, those results can include channel message history, thread replies, search results, file references, and user and channel metadata.

In a healthcare organization, informal clinical and operations chat can contain patient names, MRNs, diagnoses, and appointment details. Once a tool call returns that text, the model can reproduce it in an output, pass it to a downstream tool, or leave it in prompts and logs that sit outside HIPAA-scoped systems.

This makes the tool response the practical control point. It is the last place where content can be inspected before it becomes model input. Prompt instructions that tell the agent to ignore PHI do not change what was already delivered. Where the filter sits relative to prompt and log stores also matters: if it runs after those stores are written, raw PHI has already been retained.

Scope retrieval first, then detect

Detection is the weaker control, so reduce what it has to examine. Under 45 CFR 164.502(b), as of November 2026, a covered entity or business associate must make reasonable efforts to limit PHI to the minimum necessary for the intended purpose of a use, disclosure, or request. Whether that applies to a given agent use depends on your covered entity or business associate status, which counsel should confirm.

NIST SP 800-122 likewise points to access control policies as a way to limit access to PII. For a Slack MCP server, that means starting from a default-deny channel allowlist rather than workspace-wide access. Exclude channels used for patient coordination, handoffs, and escalations unless a specific use case requires them. Cap retrieval by time window and thread depth, and disable tools such as broad search or file retrieval if the use case does not need them.

Each restriction removes content that detection would otherwise have to classify correctly. It also gives you a documented, reviewable rationale for what the agent was permitted to request.

Define the policy actions for each tool response

Write the policy per tool and per response type, not as one global rule. NIST SP 800-53 Rev. 5 lets organizations choose from block, strip, modify, or quarantine after a filter runs. Those map readily to the decisions below, with allow as the case where nothing is detected or the content is out of PHI scope.

• Allow: Return the response unchanged when the channel is in scope and no PHI is detected. Record the decision anyway.
• Redact: Replace detected identifiers such as names, MRNs, or dates with typed placeholders, so the agent keeps the sense of the message without the identifier.
• Block: Withhold the whole response when it contains dense or high-risk PHI, such as a clinical summary pasted into a thread.
• Escalate: Hold content for human approval when confidence is low or the content is ambiguous. Assign an owner and a response time.
• Fail closed: If the filter errors or times out, return nothing to the model instead of the unfiltered response.

Produce evidence for each filtering decision

Review after the fact tells you what was exposed. Evidence produced at enforcement time tells you what was prevented. NIST SP 800-53 Rev. 5 calls for recording content filtering actions and results for the information being filtered, and describes per-message records as a way to confirm the correct action was applied and to troubleshoot why content was modified or failed filtering.

A useful record contains the tool call identifier, timestamp, channel identifier, policy version, detected categories, action taken, and the result. It should not contain the raw PHI. NIST's audit record guidance raises privacy considerations, including limiting PII in audit records, so a filter log that copies the original message creates a second PHI store.

These records support the audit controls requirement at 45 CFR 164.312(b) by showing, per interaction, that filtering ran and what it decided. Confirm retention periods and the mapping to your audit control procedures with your compliance team. Pair the records with a documented risk assessment, since controls are meant to reduce risk to an acceptable level, not remove it.

Limits of detection and where runtime enforcement fits

Detection-based filtering produces false negatives. Pattern matching can catch structured values such as MRN formats but misses identifiers written in unusual ways. Model-based detection can use context but may struggle with short, informal fragments, abbreviations, and nicknames. Plan on misses: measure them against your own sample of Slack content, set thresholds from that testing, and treat a clean result as reduced risk rather than proof of absence.

That is why scoping and human escalation sit alongside detection. Assign owners to review blocked and escalated content, tune filters, and revisit the channel allowlist as usage changes.

Trussed enforces policy in the execution path of MCP tool calls, with actions to allow, redact, block, or escalate for human approval, and generates audit-ready evidence mapped to HIPAA. Its scope is individual interactions and tool calls, so it supports the response-level control described here and does not replace channel scoping or risk assessment. It runs in production with healthcare organizations and can be deployed self-managed in the customer cloud.