Copilot Studio DLP Policies vs Runtime Policy Enforcement: What FINRA Examiners Need to See

What Copilot Studio DLP policies control

Power Platform DLP connector policies classify connectors and restrict which of them can be used together. For a Copilot Studio agent, this limits the set of systems the agent can be wired to when a maker builds it. That is a legitimate and necessary control. It reduces the surface area an agent can reach and gives administrators a central place to set boundaries across an environment.

The important property is when the control applies. DLP policies are evaluated against configuration. They answer the question of whether a connector combination is allowed. They do not look at the content of a particular prompt, the arguments passed to a particular tool call, or the data returned in a particular response. An agent that is configured entirely within policy can still issue a call, in a specific conversation, that a compliance officer would not have approved if asked.

For that reason DLP is best described as a boundary on design, not a decision about behavior. Treating it as the whole control set creates a gap that surfaces when someone asks about a specific interaction.

Connector-level DLP compared with runtime enforcement

The two layers are complementary because they operate on different units of control. The table summarizes the difference as it matters to a supervisory reviewer.

• Unit of control: DLP: connectors and connector groups. Runtime: individual interactions, prompts, tool calls and outputs.
• When it applies: DLP: at configuration time. Runtime: at execution time, before the action proceeds.
• Possible outcomes: DLP: a connector combination is permitted or not. Runtime: allow, redact, block, rate limit or escalate for human approval.
• Question it answers: DLP: what could this agent be connected to? Runtime: what was this agent allowed to do in this interaction, and what did it do?
• Evidence produced: DLP: the configured policy. Runtime: a per-decision record of policy applied, action taken and outcome.
• Main limitation: DLP: does not evaluate individual calls. Runtime: depends on where it attaches and what it is configured to enforce.

Questions connector-level DLP cannot answer

Supervision of an AI agent is a question about conduct over time, not only about setup. A reviewer, internal or external, will want to move from a policy statement to a specific event. Which tool did the agent call on a given date? What data went into that call? Was the call permitted under the policy in force at that moment? Did a person approve it, and if the policy required approval, where is that record?

Connector-level DLP can show that a policy existed and what it contained. It cannot show that a particular call was evaluated, because no per-call evaluation took place. It also cannot show that a sensitive value was redacted before it reached a tool, or that a request above an allowed rate was stopped. Those facts exist only if something in the execution path made a decision and wrote it down.

This matters for model risk management as well. A firm that classifies an agent as higher risk will need to show that the controls it described are operating, not just defined. A configuration export is evidence of design. Operating evidence has to come from the layer that acts on live traffic.

Compliance teams should also be careful about how they describe these controls internally. Saying that DLP governs agent behavior overstates what it does, and the overstatement is the kind of thing that becomes visible under questioning.

Runtime enforcement in the execution path

Runtime enforcement places a policy decision point between an agent's proposed action and its effect. The layer intercepts a tool call or API action at execution time, evaluates it against policy, and either lets it proceed, changes it, or stops it. OWASP's agentic lifecycle material describes this pattern as tool-call interception with policy-aware controls and authorization, and places runtime enforcement across the Deploy, Operate and Govern stages.

A NIST CSRC conference presentation on runtime execution governance makes a related point: consequential execution requires control, not only reasoning. It describes revalidating authority at the moment of commit and recording receipt or refusal evidence. That presentation is not NIST guidance, and it is not an examiner standard, but it is a useful framing. The decision and its record are produced together at the point of action, rather than reconstructed afterward.

At a minimum, each enforcement decision should produce a record containing the policy applied, the action taken and the outcome, including any refusal. In practice a reviewer will also expect a timestamp, the agent and user identity, the tool involved, and the policy version, so that the decision can be tied to the rules in force at the time. Escalations to human approval should record who approved and when.

There is also an integration decision. Enforcement can attach at a framework hook, at a gateway for tool or MCP server access, or through tool-call interception. These are different integration points with different coverage. A firm should confirm which one applies to its Copilot Studio agents before assuming a given layer sees the traffic it needs to see.

How to sequence the work and where Trussed fits

Start by keeping DLP policies in place and documenting them as the configuration layer. Then inventory what each production agent can actually do through its tools, and decide which actions need enforcement at the call level: those involving sensitive data, external systems, or consequential outputs. Define the evidence record before selecting a tool, so that the selection is tested against what a reviewer needs rather than what a demonstration shows.

Trussed is one example of the runtime layer. It enforces policy in the execution path across models, agents, tools and MCP servers, with allow, redact, block, rate limit and escalate for human approval applied to individual interactions and tool calls. Enforcement generates audit-ready evidence, which Trussed maps to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. It deploys self-managed in the customer cloud, with configurable retention and data residency. Trussed has run continuously in production in a regulated enterprise for more than 18 months, and its customers are in insurance, pharma, healthcare and education. Insurance is where it is deepest.

No runtime layer guarantees regulatory compliance. What it can do is give a compliance leader something concrete to show when asked what an agent was permitted to do and what it did.