NYDFS Third-Party Service Provider Controls for Copilot Studio Connectors and Plugins

What Section 500.11 requires, as of November 2026

Section 500.11(a) requires each covered entity to implement written policies and procedures designed to ensure the security of information systems and nonpublic information that are accessible to, or held by, third-party service providers. Those policies must address four things: identification and risk assessment of providers, the minimum cybersecurity practices a provider must meet to do business with the covered entity, due diligence to evaluate the adequacy of those practices, and periodic assessment of providers based on the risk they present and the continued adequacy of their practices.

Section 500.11(b) adds that the policies should include guidelines for due diligence and/or contractual protections, to the extent applicable. These cover the provider's policies and procedures for access controls, including its use of multi-factor authentication as required by Section 500.12, and for the use of encryption under Section 500.15 to protect nonpublic information.

DFS has also said that covered entities remain ultimately responsible for protecting their systems and nonpublic information and are expected to ensure providers implement the necessary controls. Its third-party guidance asks for a risk-based, continuously adaptive approach, with providers classified by system access, data sensitivity, location and service criticality. DFS's AI cybersecurity guidance states that it imposes no new requirements beyond Part 500 and identifies provider due diligence before use as one of the most important requirements for AI-related risk. The AI guidance explains how the existing framework applies. It is not a separate AI mandate.

Connectors and plugins as third-party touchpoints

A Copilot Studio agent reaches external systems through connectors and plugins, and many of those are operated by third parties. For Section 500.11 purposes, each one is a path through which nonpublic information can be sent to a provider or returned from one. The agent is a new caller, and the provider is a party whose systems are now reachable from it.

The first practical step is an inventory. Section 500.11(a)(1) requires identification of providers, and NIST's generative AI profile similarly suggests inventorying third parties with access to organizational content and auditing plugins. Every connector and plugin an agent uses should map to a provider record with a risk tier. Without that mapping, neither due diligence nor any runtime policy has a stable subject.

The second step is to recognize what 500.11(b) actually examines. The provider's own access controls, MFA and encryption are the provider's. No control on your side can verify them. What you can govern is what your agent sends to the provider and what it accepts back. That boundary decides which obligations can be met before deployment and which must be met on each call.

Why runtime controls need to sit in the execution path

Due diligence tells you what a provider says it does. A contract records what it has agreed to. Periodic assessment samples its condition at a point in time. None of these shows what a connector or plugin was allowed to do, or did, at the moment of a specific call. That gap is where an examiner's follow-up questions will land.

NIST SP 800-228 treats authentication and authorization of API calls as runtime controls: authenticate the calling service, authorize it using that identity, and authenticate the end user, which is often a non-person entity such as a service account. It also notes that runtime tooling can apply cross-cutting policy instead of relying on each service's own logic. That is general API guidance, and no source states that it satisfies NYDFS. It does support the design principle that decisions about individual calls belong where the calls pass through, not in a review that happens afterward.

In practice, enforcement in the execution path means a policy decision is made before the call completes. The decision can allow it, redact fields from the payload, block it, rate limit it, or hold it for human approval. A review after the fact can identify a problem, but it cannot prevent one.

The limits matter. Runtime enforcement does not assess a provider's internal security, does not replace due diligence, and does not substitute for contractual protections or periodic assessment. It governs the covered entity's side of the interaction.

Where Trussed fits

Trussed is the runtime layer in this model. It enforces policy in the execution path of agents, tools and MCP servers, at the level of individual interactions and tool calls: allow, redact, block, rate limit, or escalate for human approval. Enforcement happens at runtime, not after the fact, and it generates audit-ready evidence that is mapped to NYDFS among other frameworks. Trussed can be deployed 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. It does not perform provider due diligence, draft contracts or run periodic assessments, and it is not a substitute for them. Those remain the covered entity's responsibility under Section 500.11. Its role is to make the runtime portion provable.