Blocking PHI in Copilot Studio Connector Actions for HIPAA

Where PHI enters and leaves through connector actions

A Copilot Studio agent that calls connector actions reads from and writes to systems such as email, SharePoint, Dataverse and third-party APIs. Each call is a point where ePHI can cross a boundary, and there are three places to look.

The first is action input. The agent assembles parameters from the user's message, earlier turns or retrieved content. A patient name, phone number or record number can end up in an email body, a file write or an API request. The second is action output. A read from a list, table or document can return fields the task never needed, and those fields then sit in the agent's working context. The third is agent context itself. PHI returned by one action can be passed to a different action later in the same conversation, including one that sends data to an external party.

This is why a permitted connector is not the same as a safe call. The same approved connector can carry a harmless scheduling note in one invocation and a full patient summary in the next. Controls that evaluate only the connector never see that difference.

Connector-level governance and content-level enforcement

Data policies that group connectors work at the connector and environment level. They answer whether an agent may use a connector at all. They are a necessary layer and should stay in place. They do not inspect the content of an individual action's inputs and outputs, which is the gap runtime enforcement addresses.

• Unit of control: Connector-level governance: connector or environment. Content-level enforcement: one tool call, with its inputs and outputs.
• Question answered: Connector-level governance: is this connector permitted? Content-level enforcement: does this payload contain PHI, and what should happen to it?
• When it acts: Connector-level governance: at configuration time. Content-level enforcement: at runtime, on each invocation.
• Possible outcomes: Connector-level governance: allow or restrict the connector. Content-level enforcement: allow, redact or block the specific call.
• Evidence produced: Connector-level governance: the configuration state. Content-level enforcement: a per-call decision record.

Designing PHI detection and understanding its limits

Start the detection ruleset from the 18 identifier types in the HIPAA Safe Harbor method. These include names, telephone numbers, email addresses and other unique identifying numbers, characteristics or codes. Build one rule or classifier per category and tag each with the connector actions where it is likely to appear.

Structured payloads and free text need different handling. Structured fields, such as a named column or a typed API parameter, can be matched by field name and by format. Free text in email bodies, document content or chat turns relies on pattern matching and classification, which trade precision against recall. A strict rule produces false positives that interrupt legitimate work. A loose rule produces false negatives that let PHI pass. Decide in advance which error is more tolerable for each action, and set the policy accordingly. A write to an external recipient justifies stricter handling than a read from an internal store.

Be precise about what detection proves. Safe Harbor has two parts: removing the 18 identifiers and having no actual knowledge that the remaining data could identify an individual. Detection can address the first part. It cannot establish the second. Treat the ruleset as an enforcement control for tool calls, not as a de-identification determination.

Implementing allow, redact and block decisions

Place the enforcement point in the execution path so that every in-scope tool call passes through it before data moves. Trussed enforces policy at this level, on individual interactions and tool calls from agents, tools and MCP servers. It supports allow, redact, block, rate limit and escalation for human approval. The same design applies whatever mechanism you use.

Assign a default decision to each action and direction, then refine it. Redaction suits low-risk cases where the task can finish without the identifier. Blocking suits cases where the destination is not entitled to receive PHI at all. Escalation suits ambiguous cases that need a person to decide.

• Inventory every connector action the agent can call, and mark the direction of data flow (input, output, or both).
• Classify each action by sensitivity and by destination: internal store, internal recipient or external party.
• Map each PHI identifier category to a decision per action: allow, redact, block or escalate.
• Deploy in a monitoring posture first, review the decisions that would have applied, then tune and switch to enforcement.
• Version every policy change, with a named reviewer, and re-test whenever the agent's connectors or actions change.

Evidence that supports audit controls under 164.312(b)

Section 164.312(b) is the audit controls provision of the Security Rule technical safeguards. The Security Rule places obligations on covered entities and business associates, so enforcement tooling supports compliance but does not substitute for the organization's own policies and procedures. HHS also expects security policies and procedures to be reviewed and modified regularly where necessary, which applies to enforcement policies as agents change.

Each enforcement decision should produce a record that a reviewer can use without reconstructing events. Useful fields include the timestamp, the agent and the action invoked, the connector, whether the decision applied to input or output, the identifier categories detected, the decision taken, the policy version in force and the reason. Record the categories and not the PHI values, so the evidence store does not become a second PHI repository.

NIST SP 800-66r2 asks what mechanisms, such as metrics, will assess the effectiveness of the audit process. Track block and redact rates by action, escalation outcomes and test results over time. Trussed generates audit-ready evidence from enforcement, mapped to HIPAA, and supports self-managed deployment in the customer cloud with configurable retention and data residency, so evidence can stay inside the organization's own boundary.

If your organization is an actor under the information blocking rules, review blocking and redaction controls against them. Those rules are separate from HIPAA and are assessed case by case, and the right of access under 164.524 still applies. This is relevant as of November 2026 and should be confirmed with counsel.