NYDFS Part 500 Third-Party Service Provider Policy for AI Agents Using Hosted Tools

What 500.11 requires and why hosted tools fall in scope

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. The policies must address identification and risk assessment of those providers, the minimum cybersecurity practices they must meet, due diligence to evaluate the adequacy of those practices, and periodic assessment based on the risk they present.

Section 500.11(b) adds guidelines for due diligence and contractual protections, to the extent applicable. They cover the provider's access controls including multi-factor authentication under 500.12, its use of encryption under 500.15 for nonpublic information in transit and at rest, notice to the covered entity of a cybersecurity event directly affecting its systems or nonpublic information held by the provider, and representations and warranties about the provider's cybersecurity policies.

Part 500 defines a third-party service provider as a person that is not an affiliate, provides services to the covered entity, and maintains, processes or is permitted access to nonpublic information through those services. A hosted tool therefore comes into scope to the extent nonpublic information can reach it. That is an application of the definition, not a DFS statement about any particular AI product. DFS's AI and TPSP guidance letters state that they add no new requirements. They explain how existing Part 500 duties apply, and they call TPSP policies with due diligence guidelines one of the most important requirements for combating AI-related risk.

A separate policy position for each hosted tool

DFS expects TPSP policies to be risk-based and tailored to the service and the sensitivity of the data and systems involved. A single entry reading "AI vendor" does not meet that expectation, because the three hosted tools move data in different directions. The risks below are design hypotheses to evaluate against your own configuration, not documented findings.

Web Search sends queries out to external content. The exposure is that a query assembled by a model can carry nonpublic information, such as a customer name, account detail or internal matter, to the provider. The policy should state that only public and low-sensitivity internal data classes may appear in a query. Enforcement should inspect the query before it leaves the boundary, redact or block identifiers, and escalate queries that reference specific customers or transactions. Limit the tool to agents with a documented business need.

File Search retrieves from vector stores built from uploaded documents. Two questions matter. Which data classes may be uploaded at all? And does an agent retrieve only what the requesting user or workload is entitled to see? Over-permissioned retrieval is the main risk, since a store populated for one purpose may be queried by an agent serving another. The policy should name approved document collections per agent, bind retrieval to entitlements, block calls that target collections outside that mapping, and require approval for the most sensitive classes.

Code Interpreter runs model-generated code in a hosted sandbox. The policy should specify which files may be passed to it, since code the model writes can read, transform and emit the contents of those files. Define permitted file classes, block uploads that contain restricted nonpublic information, apply rate limits to execution calls, and route unusual requests to a human approver. The output returned to the agent also needs a rule, because derived data can carry the sensitivity of its inputs.

Dividing evidence between the provider and the covered entity

DFS states that covered entities remain ultimately responsible for protecting their information systems and nonpublic information, and are expected to ensure providers implement the controls needed to do so. Running a tool on provider infrastructure does not move that responsibility.

A practical way to apply this is a per-tool matrix with columns for permitted data classes, the 500.11 hook, the enforcement action and the evidence produced. Mark separately the cells the provider must evidence and the cells you enforce yourself. Provider-side cells follow the 500.11(b) topics: access controls and MFA, encryption in transit and at rest, retention and event notice, and representations and warranties, evidenced through due diligence and contract terms. Covered-entity cells are the ones no vendor can complete for you: which data classes reach each tool, which agents may call it, with what arguments, and who approved exceptions.

Confirm that the provider's event-notice path feeds your incident process. Where 500.17 applies to your entity, notification to DFS is required within 72 hours of determining that a cybersecurity incident impacting the business has occurred. Which Part 500 sections apply depends on 500.19 exemptions and Class A status, so confirm scope before finalizing the matrix.

Why runtime enforcement matters to an examiner

DFS states that it reviews information security policies and procedures, including those addressing TPSP risk, during examinations. A written policy and a vendor attestation show intent and provider posture. Neither shows what a specific agent was permitted to do at a specific moment, or what it actually did. That gap is an inference from how the evidence is structured, not a DFS statement, but it is the gap examiners tend to probe when a policy claims control over a data flow.

Enforcement placed in the execution path closes it by design. When each tool call is evaluated before it leaves the organization's boundary, the decision (allow, redact, block or escalate) is made against the written policy, and the record of that decision is a by-product rather than a reconstruction. Evidence produced after the fact from application logs depends on someone remembering to log the right fields. Evidence produced by the enforcement point exists because the control operated.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, at the level of individual interactions and tool calls. Its actions are allow, redact, block, rate limit and escalate for human approval. It generates audit-ready evidence mapped to NYDFS and other frameworks, and it can be self-managed in the customer cloud with configurable retention and data residency. It does not claim end-to-end tracing of agentic workflows or transaction-level governance. Its scope is the individual call and the decision made on it.

Implementation sequence for compliance leaders

Start by adding each hosted tool to the TPSP inventory and assessing it on its own data flow. Use the factors in DFS's AI guidance: the AI-specific threats facing the provider, how those threats could affect your entity, and how the provider protects itself.

Next, write the tool-level rules: permitted data classes, allowed calls and arguments, and the action for each class of exception. Decide which exceptions are blocked outright and which go to a human approver, and name the approver role. Send these rules through the same annual approval route as the rest of the cybersecurity policy set.

Then set the reassessment trigger. Section 500.11(a)(4) ties periodic assessment to the risk presented and the continued adequacy of provider practices, so adding a tool or changing its configuration should prompt a review before the next scheduled cycle.

Finally, evaluate any enforcement layer against three criteria. Does it sit in the path before data leaves the boundary? Does it decide per call, not per application? Does it write a durable decision record that maps to your policy language? A control that fails any of these will leave the examiner relying on attestations.

• Inventory each hosted tool as its own TPSP entry
• Define permitted data classes and actions per tool
• Assign an approver role and an approval record
• Set scheduled and event-driven reassessment triggers
• Test that decision records map to policy rules