NYDFS AI Compliance: Applying Part 500 Access, Audit, and Third-Party Controls to LLM Traffic
The NYDFS Cybersecurity Regulation, 23 NYCRR Part 500, requires covered financial entities to enforce least-privilege access, maintain audit trails, monitor authorized user activity, and govern third-party service providers. When employees and AI agents send data to LLMs, those requirements apply to the prompt traffic. NYDFS issued specific guidance in October 2024 on AI-related cybersecurity risks, and it maps to controls already in Part 500. This piece walks the Part 500 sections that land on AI inference traffic and shows how to enforce access and produce the audit trail the regulation requires.
The NYDFS Cybersecurity Regulation, 23 NYCRR Part 500, requires every covered entity to limit user access privileges, maintain audit trails, monitor the activity of authorized users, and hold third-party service providers to security requirements, with the Second Amendment adopted November 1, 2023 and its provisions phased in through November 2025. The regulation is published by the New York Department of Financial Services, which also issued guidance in October 2024 on the cybersecurity risks that artificial intelligence introduces. That guidance did not create new controls. It pointed at the Part 500 controls that already govern how a covered entity handles data, and those controls follow a prompt to a model. I want to walk the specific sections that land on AI traffic.
The Part 500 sections that touch AI traffic
Four requirements in Part 500 apply directly to prompts sent to an LLM.
Access privileges (500.07). Covered entities must limit user access privileges to information systems that provide access to nonpublic information and periodically review them. A model endpoint reachable by any authenticated user, with any data, contradicts the least-privilege standard this section sets.
Audit trail (500.06). Covered entities must maintain audit trails designed to detect and respond to cybersecurity events. For AI usage, an audit trail that omits what data a prompt carried cannot support detection or response.
Monitoring authorized users (500.14). The regulation requires monitoring designed to detect unauthorized access or use of nonpublic information by authorized users. An employee sending nonpublic information to an external model is precisely the authorized-user activity this section targets.
Third-party service providers (500.11). Covered entities must implement written policies for the security of third-party service providers. An external model provider receiving nonpublic information through prompts falls inside that scope.
Where existing controls miss the AI channel
A covered entity that has implemented Part 500 across its estate still tends to have a hole on AI traffic. The access-privilege reviews cover applications and databases and rarely enumerate which roles may send which data to which model. The audit trail captures system and application events and misses the content of a prompt. Monitoring watches file access and network flows, and the prompt travels as an encrypted API call whose payload the monitoring stack does not parse. The third-party policy governs vendors procured through the normal path, and a model API that an engineer wired into a tool last quarter was never entered into that inventory. The AI channel sits across all four controls and inside none of them.
The access and audit decision Part 500 requires
Meeting 500.07 and 500.06 for AI traffic means deciding per request whether a caller may send this data to this model, and recording that decision. The decision runs on the request path, before the prompt leaves. A policy decision point in front of the model evaluates each call and commits a record:
That single record answers the access decision (was this caller permitted), the audit-trail requirement (what happened, with full context), and part of the monitoring obligation (an authorized user attempted to send nonpublic information). One enforcement point on the traffic covers three sections at once.
Why the audit trail has to be independent
Part 500 audit trails exist to detect and respond to events, which presumes the record is trustworthy. A log written by the same AI application that made the decision is self-attested, and it can be selectively written, suppressed, or lost on a crash after the model responded but before the log committed. An audit trail produced independently on the traffic, before the response returns, holds up when DFS asks a covered entity to reconstruct what happened. This is the same independence principle that governs financial audit, applied to AI decisions. Related sector coverage sits in DORA AI compliance and finance DORA AI inference controls.
DeepInspect
This is the gap DeepInspect closes for NYDFS-covered entities. DeepInspect is a stateless proxy that sits inline in front of your AI traffic and is model-agnostic, so one layer covers OpenAI, Anthropic, Bedrock, Vertex, Azure OpenAI, and self-hosted endpoints. For every request it evaluates the caller identity and role, the data classification in the prompt, and organizational policy, then returns a pass or block decision before the traffic reaches the model. Enforcement adds under 50 milliseconds in internal testing, and the default on ambiguity is deny, which matches the least-privilege posture 500.07 sets.
For every decision it commits an identity-bound audit record before the response returns, written independently of the calling application. That record gives a covered entity the access, audit-trail, and monitoring evidence Part 500 requires on the AI channel that its existing controls do not parse. DeepInspect does not replace your cybersecurity program under Part 500. It enforces the access and audit provisions on the traffic where nonpublic information reaches a model. Let's talk today.
Frequently asked questions
- Does NYDFS Part 500 apply to AI usage?
Yes, Part 500 governs how covered entities handle nonpublic information, and its access, audit-trail, monitoring, and third-party provisions apply when that information reaches an LLM through a prompt. The October 2024 DFS guidance pointed at these existing controls rather than creating new ones.
- Which Part 500 sections apply to LLM traffic?
Access privileges under 500.07, audit trail under 500.06, monitoring of authorized users under 500.14, and third-party service provider policies under 500.11 all apply when data flows to a model endpoint.
- Why do existing Part 500 controls miss AI prompts?
Access reviews, audit trails, and monitoring were built around applications, databases, and network flows. A prompt travels as an encrypted API call whose payload those controls do not parse, so the content of what an authorized user sends to a model is not captured.
- What audit trail does DFS expect for AI decisions?
A trail that supports detection and response, which for AI usage means recording who sent what data to which model under which policy. A log missing the prompt data context cannot support the detection purpose the audit-trail requirement sets.
- Can application logs meet the Part 500 audit-trail requirement for AI?
They usually fall short, because they lack data classification and are written by the same system that made the AI decision. An independent, identity-bound record produced on the traffic before the response returns is the stronger evidence for 500.06.