Why New York Is the Regulator That Matters More in 2026
With the CFPB operating at reduced capacity, the regulators with both the authority and the staff to push on AI risk are increasingly at the state level, and New York is at the front of that group. The Department of Financial Services supervises banks chartered in the state and a long list of non-bank licensees, including mortgage bankers, lenders, money transmitters, and insurers, which means Part 500 reaches far past New York-chartered banks. If your institution holds a DFS license of almost any kind, this regulation applies to your AI systems whether or not you think of yourself as a New York company.
We run the vendor side of this. Two of our NYDFS-supervised customers have reviewed our security program against Part 500 as part of their own diligence, and those reviews are more specific about AI than anything we see from the federal interagency process. The controls below are what those reviews focused on.
Part 500 Is in Full Effect, in Phases That Are Now Complete
23 NYCRR Part 500 is not new, and its Second Amendment finished phasing in during 2025, so there is no remaining grace period to point at. The amendment took effect on November 1, 2023, and the obligations turned on in stages: the 72-hour cybersecurity-event and ransomware-payment notice duties under 500.17 by December 2023, the general controls by April 2024, the governance and CISO-reporting requirements under 500.4 along with encryption under 500.15 and incident response and business continuity under 500.16 by November 2024, then access-privilege management under 500.7, vulnerability scanning, and training by May 2025, and finally multi-factor authentication under 500.12 and asset management and data-retention limits under 500.13 by November 2025.
Every one of those dates has passed. A covered entity deploying an AI agent in 2026 is deploying it into a fully effective control regime, not building toward a future one.
The October 2024 Letter Did Not Add Rules. It Aimed Part 500 at AI.
The piece that ties this to AI specifically is the DFS industry letter of October 16, 2024, titled "Cybersecurity Risks Arising from Artificial Intelligence and Strategies to Combat Related Risks." The most important sentence in it is the one that says it imposes no new requirements. The letter does not create an AI rule. It tells covered entities how to use the existing Part 500 framework to assess and address AI risk, which is a sharper instruction than a new rule would be, because it removes the argument that AI is unregulated until a dedicated standard appears. The existing controls already apply, and the letter says how.
For a vendor or a bank standing up an AI agent, that means the Part 500 program is the AI governance program. The risk assessment under 500.9 has to account for AI threats. The third-party security policy under 500.11 has to cover AI vendors. The authentication, access, monitoring, and training controls all have to be read with AI in mind. The letter walks through that mapping, and we build to it.
The Threats the Letter Names, and Where an AI Agent Sits in Each
The letter groups AI-related cybersecurity risk into a few categories, and each one lands on a specific part of an AI deployment.
The first is AI-enabled social engineering, including deepfaked voice and video used to defeat identity checks and to run more convincing phishing. For an institution running a voice agent, this cuts both ways: the agent is a channel an attacker can target with a synthetic caller, and the agent's own authentication has to assume the voice on the line may be generated. The second is the larger attack surface that comes from AI systems holding or processing big stores of nonpublic information, which makes those systems a higher-value target and raises the cost of a breach. The third is the way AI lowers the barrier to entry for attackers and increases the speed and scale of attacks, which compresses the time a defender has to detect and respond. The letter also points at the supply-chain risk that AI products and their dependencies introduce, which is the third-party angle.
Read against an AI agent, those threats say: harden the authentication, lock down the data stores and the model infrastructure, shorten detection time, and run real diligence on the AI supply chain. The rest of this is how.
Authentication That a Deepfake Cannot Defeat
The most concrete instruction in the letter is on authentication. It says covered entities should use forms of authentication that AI-generated deepfakes cannot impersonate, and it names digital certificates and physical security keys as examples. This is a direct shot at voice biometrics and knowledge-based questions as a sole factor, because both are now defeatable at scale by generated audio and by data an attacker can assemble.
On our own infrastructure we moved administrative access to the AI systems, the prompt store, the model configuration, and the deployment pipeline onto phishing-resistant, hardware-backed authentication rather than one-time codes, because a one-time code phished through a convincing synthetic call is exactly the failure the letter describes. For customer-facing voice agents that handle sensitive actions, we treat a voiceprint as a signal, never as the sole factor, and we step up to an out-of-band factor the customer holds before the agent will move money or change account details. Part 500.12 requires MFA for access to nonpublic information; the AI letter is the reason to make that MFA phishing-resistant rather than SMS-based.
Privileged Access on the Model and Prompt Store
Section 500.7 requires limiting and periodically reviewing access privileges. The question NY reviewers asked us that the federal process did not was where the privileged access to the AI system itself sits. Who can change a production prompt. Who can alter a retrieval source. Who can read the request logs, which contain customer data. Who can deploy a new model version.
We treat the prompt store, the retrieval configuration, and the request logs as systems holding nonpublic information, which puts them inside the same least-privilege regime as the core banking systems. Access is role-scoped, time-bound where it can be, reviewed on a set cadence, and logged. A production prompt change is a reviewed and recorded action, not an edit anyone with repository access can make, because a prompt is part of how the agent decides what to disclose and what to do. Most AI programs we look at have strong controls on the core and treat the AI configuration plane as a developer convenience. Under 500.7 that gap is a finding.
The Third-Party Diligence NY Asks For Beyond the Federal Baseline
Section 500.11 requires a third-party service provider security policy and due diligence. The federal interagency third-party guidance covers similar ground, but the NY reviews go further on AI specifics. The artifacts our DFS-supervised customers asked for, beyond the standard package, included the model lineage and which foundation-model providers sit upstream, the data-flow diagram showing exactly which nonpublic information leaves the customer's environment and where it is processed, the encryption posture for AI-specific assets like prompts and retrieval indexes, the authentication standard on our own administrative access, and our incident-response triggers for AI-specific failures. One customer required a contractual notice obligation when an upstream foundation model changes in a way that could affect outputs, which is an AI-specific clause a generic vendor security policy does not contain.
We can produce these because we built the program expecting the question. A vendor that cannot produce a data-flow diagram and a model-lineage map is asking the bank to take the AI supply chain on faith, and under 500.11 the bank cannot.
Data Minimization Is a Control Now
The November 2025 phase brought 500.13, which requires policies for asset management and for the secure disposal of nonpublic information no longer necessary for business operations. For AI systems this is the control most programs have not internalized, because AI pipelines tend to accumulate data. Prompts and retrieval indexes hold copies of customer information, request logs hold transcripts, and fine-tuning or evaluation sets can quietly become long-lived stores of nonpublic data.
We apply retention limits to each of those stores and dispose of data on a schedule tied to need, not convenience. Customer data does not become a permanent training or evaluation corpus by default. The reason to do this is partly 500.13 and partly the threat the letter named: the larger the store of nonpublic information sitting in the AI system, the bigger the target and the worse the breach. Minimizing what the agent retains is a security control, not only a privacy one.
What We Hand a NY-Regulated Customer
When a DFS-supervised institution runs its Part 500 diligence on our AI deployment, the package we provide includes the SOC 2 Type II report, the data-flow diagram and the list of upstream model providers, the encryption and key-management posture for the AI-specific assets, the administrative-authentication standard, the access-control and review evidence for the model and prompt plane, the retention and disposal schedule for each data store, and the AI-specific incident-response triggers and notice commitments. That package maps to the Part 500 sections the October 2024 letter pointed at, so the customer's CISO can attach it to their own program rather than rebuild it. The institutions that move fastest on AI in New York are the ones whose vendor hands them a Part 500-shaped file on the first request, because the regulation is fully in effect and the diligence is not optional.
Ramkumar Venkataraman
CTO & Co-Founder