Preventing Copilot Studio Agents from Sending Customer NPI Through Connectors Under Regulation S-P

What Regulation S-P asks of connector traffic

As of November 2026, Regulation S-P (17 CFR Part 248 Subpart A), as amended at 89 FR 47786 on June 3, 2024, requires covered institutions' safeguards policies and procedures to include an incident response program. The program must be reasonably designed to detect, respond to, and recover from unauthorized access to or use of customer information. Any instance of unauthorized access or use triggers it, and it must include procedures to notify affected individuals when sensitive customer information was, or is reasonably likely to have been, accessed or used without authorization.

Our inference is that an agent sending NPI through a connector to an unauthorized destination could fall within unauthorized use. Whether it does is a legal determination for your counsel.

The program must also include written policies and procedures requiring oversight of service providers, including due diligence and monitoring. The rule text includes a term requiring a service provider to notify the institution as soon as possible, and no later than 72 hours after becoming aware, of a breach in security resulting in unauthorized access to a customer information system it maintains. Third-party SaaS recipients of agent traffic belong in that oversight scope.

The regulation does not mandate tool-call inspection or any specific technology. Payload-level control is an implementation choice for meeting the reasonably designed standard. Also confirm which rule governs your institution. The FTC Safeguards Rule (16 CFR Part 314) is separate from Regulation S-P.

Map the paths by which an agent can expose NPI

Start with the actions, not the connectors. An agent that can send email, write to a SharePoint location, call an HTTP endpoint, or invoke a third-party SaaS action has four different exposure surfaces, each with a different recipient and audience.

Then trace where the data in each action's inputs comes from. Typical origins are text the user typed into the conversation, content retrieved from a knowledge source, output from an earlier tool call, and parameter values the model fills in at runtime when it decides which action to invoke. A customer account number can enter through any of these and end up in an email body or request payload that nobody authored explicitly.

This matters for control placement. Controls that act on the prompt or on the knowledge source see only one origin. Every path converges at the tool call, where the final payload is assembled and the destination is known. That makes the call boundary the one place where content, destination, and calling agent can be evaluated together.

For each agent, record the connectors, the actions, the input fields, the destination, and whether customer information can reach those fields. Treat any destination outside your boundary as a candidate service provider.

Connector scoping, data policies, and identity

Connector inventory and scoping come first. Remove connectors and actions an agent has no business case for. A smaller action surface reduces the number of payloads you need to reason about, and it is the cheapest preventive control.

Platform data policies and environment strategy operate at tenant and environment level. They limit which connectors can be used and let you separate agents that touch customer information from those that do not. They govern availability. They do not inspect the data an agent sends through a connector they permit, so a permitted email connector can carry NPI to an unintended recipient and the policy will not see it.

Identity and permissions bound what a connection can reach. Use least-privilege identities, separate them by agent purpose, and avoid broad shared accounts, so that a mistaken call cannot read or write more than intended. Permissions answer whether a call may be made. They do not answer whether this particular payload contains NPI and whether this destination should receive it.

These three layers are preventive and necessary. The gap they leave is content at the moment of the call.

What each layer covers and what it leaves open

Use this summary to decide where tool-call enforcement is needed in your design.

• Connector inventory and scoping: Covers: which actions and recipients exist per agent. Leaves open: content of any call.
• Platform data policies: Covers: which connectors can be used in a tenant or environment. Leaves open: what is sent through a permitted connector.
• Environment strategy: Covers: separation of agents by data sensitivity. Leaves open: payload content within an environment.
• Identity and permissions: Covers: what a connection can access. Leaves open: whether a specific payload contains NPI.
• Payload-level enforcement: Covers: allow, redact, block, or escalate per call. Requires: data classes and destination policy defined in advance.

Payload-level enforcement in the execution path

Enforcement at the tool call requires three definitions. First, data classes: which patterns count as NPI for your institution, such as account numbers or Social Security numbers, and where your data inventory says customer information resides. Second, destinations: which recipients are approved for each connector action. Third, a decision per combination of agent, action, destination, and data class.

A workable decision set is simple. Allow when the destination is approved for the data class detected. Redact when the action can complete without the sensitive field. Block when the destination is not approved. Escalate to a human approver for defined exceptions.

The tradeoffs are real. Detection produces false positives and misses, so tune against representative traffic. Redaction can change the meaning of a message, so apply it only where the action tolerates it. Inline evaluation adds latency to each call. You must also decide whether a failure of the enforcement point blocks the call or lets it proceed, and for NPI the safer default is to block.

Trussed enforces policy in the execution path at the tool call, so decisions are enforced at runtime, not reviewed after the fact. It supports allow, redact, block, rate limit, and escalation for human approval across agents, tools, and MCP servers, with scope at the level of individual interactions and tool calls. It can be self-managed in the customer cloud, with configurable retention and data residency, which matters when the payloads being inspected contain NPI. It does not provide workflow-level tracing or transaction-level governance.