Adding AI Agents and LLM Providers to a NYDFS Part 500 Risk Assessment

Step 1: Scope the update and build the inventory

Section 500.9(a) requires the risk assessment to be reviewed and updated at least annually, and whenever a change in the business or technology causes a material change to the covered entity's cyber risk. Deploying agents that call tools and reach nonpublic information (NPI), or sending NPI to an external LLM provider, is a candidate for that trigger. Record the determination and the reasoning, even if the conclusion is that the change is material. Section 500.9(b) requires the assessment to be carried out under written policies and procedures and to be documented, so the AI-specific method belongs in those documents rather than in a side spreadsheet.

DFS's October 2024 letter says assessments should address three areas: the entity's own use of AI, the AI used by third-party service providers (TPSPs) and vendors, and vulnerabilities from AI applications that could threaten the confidentiality, integrity and availability of information systems or NPI. These work well as the top-level categories of an AI asset inventory. That structure is our interpretation, not a DFS template.

Each inventory entry should be specific enough to score and to audit.

• Named business and technical owner for the agent or provider relationship
• Agent identity, the tools it can call, and the permissions behind each tool
• Data classes reachable, with NPI flagged explicitly
• LLM provider, the service used, and where prompts and outputs are processed and retained
• Human approval points for consequential actions
• Date of last review and the next scheduled review

Step 2: Identify threats and vulnerabilities

DFS names deepfakes and other AI-posed threats as risks an assessment must take into account, and the October 2024 letter frames AI risk across the entity's own use, vendor use, and application vulnerabilities. The agent and LLM scenarios below are practitioner threat scenarios that we map to that framing. DFS does not enumerate them.

For your own agents, the main scenarios are NPI placed in prompts or returned in outputs, permissions broader than the task requires, and tool actions that run without review. A single agent can combine these: a broad credential, a tool that writes to a system of record, and no approval step.

For LLM providers, the scenarios concern what the provider can access or retain, how much of a business process depends on one provider, and what changes when the provider alters its service or its own subprocessors. Add AI-enabled social engineering, including deepfakes, as a separate threat to the organization regardless of whether it deploys any AI itself.

As Part 500 defines it, risk assessment incorporates threat and vulnerability analyses. For each scenario, write down the threat, the vulnerability that makes it possible, and the asset affected.

Step 3: Score the risks

DFS does not require a particular framework or standard for the risk assessment. Entities may choose the methodology that suits their risk and operations, provided the assessment addresses their unique risks as 500.9 requires. DFS also prescribes no scoring scale. What 500.9(b) does require is written criteria for evaluating and categorizing identified risks or threats, so the scoring model must exist before the scores do.

A likelihood and impact model is sufficient. Anchor impact to confidentiality, integrity and availability of information systems and NPI, and anchor likelihood to factors such as the breadth of agent permissions, the volume of NPI in scope, and the degree of provider dependency. Part 500 describes risk assessment as identifying, estimating and prioritizing risk while considering mitigations provided by controls planned or in place. Give credit only for controls that are in place and operating, and keep planned controls visible as separate remediation items.

Record the rationale for each score. Because the AI letter is guidance rather than a new rule, a clear written rationale tied to the 500.9 factors is what lets a reviewer follow your reasoning.

Step 5: Define evidence and place runtime enforcement

Design evidence around what a reviewer will ask: what did you decide, why, what controls did you put in place, and how do you know they operated. The documentation set is the assessment itself with scoring rationale, the inventory with owners and review dates, TPSP assessments for each LLM provider, and access reviews for agent permissions. Evidence that controls operated is different. It consists of records of policy decisions on individual interactions, redacted or blocked requests, and human approval records for escalated actions. Set retention for these records in policy before they are needed. Part 500 text does not tell you what to keep for AI, so these are design choices you should justify in writing.

Controls that are only reviewed after the fact can show what happened but not that anything was prevented. This is where enforcement in the execution path fits. Trussed enforces policy at runtime across models, agents, tools and MCP servers, with decisions to allow, redact, block, rate limit, or escalate for human approval at the level of individual interactions and tool calls. That enforcement generates audit-ready evidence mapped to NYDFS, and it can be deployed self-managed in the customer cloud with configurable retention and data residency.

The boundaries matter. Runtime enforcement is a control and an evidence source. It does not replace the risk assessment, the TPSP diligence process, or your scoring decisions.