NYDFS AI Cybersecurity Guidance Requirements for AI Platform Teams

What the letter states, and what it leaves to you

The letter is dated October 16, 2024 and is addressed to executives and information security personnel at entities regulated by NYDFS. It states that it imposes no requirements beyond Part 500. Its purpose is to explain how covered entities should use the Part 500 framework to assess and address cybersecurity risks arising from AI. NYDFS describes the approach as risk-based and says regulated institutions must assess and take appropriate steps to address evolving AI-related risks.

The AI-specific risks NYDFS names are social engineering, enhanced cyber-attacks, theft of nonpublic information, and increased vulnerabilities from supply chain dependencies. The letter also describes layered security controls with overlapping protections, so that if one control fails, others can prevent or mitigate the impact. It says the example controls are most effective when used together.

The letter does not prescribe an implementation. It does not define a runtime enforcement mechanism, specify an evidence format, or describe controls for AI agents and tool use. Everything below that connects Part 500 to those areas is practitioner interpretation, and it should be treated that way in your own documentation. As of November 2026, Part 500 remains in force, with the second amendment effective November 1, 2023. NYDFS has since issued related letters on third-party service provider risk, Frontier AI Models (May 21, 2026) and risk assessments (September 10, 2026), which are worth reading directly.

Which expectations bear on platform design

Part 500 requires a cybersecurity program based on the covered entity's risk assessment. It requires written policies covering governance, access controls, third-party service provider risk management, training, system monitoring, vulnerability management, incident response and encryption. Some of this is organization-wide: risk assessment ownership, annual review and approval of policies by a Senior Officer or the Senior Governing Body, and independent audits for class A companies. Platform teams support these but do not own them.

Three of the named risks translate into control points that a platform team does own. Theft of nonpublic information points to data handling in prompts, outputs and tool-call payloads. Supply chain dependencies point to third-party models and external AI services, which fall under the third-party service provider risk management area, where Section 500.11 applies. Social engineering and enhanced attacks point to access control and monitoring, including what an AI agent is permitted to invoke and who or what it acts for.

The practical consequence is that an AI use case is not covered just because the organization has a Part 500 program. Each model, tool integration and external AI service needs to appear in the risk assessment and be tied to a policy area.

Runtime enforcement versus after-the-fact review

Many teams can show a written AI acceptable-use policy and a log of model requests. Fewer can show that the policy changed what happened on a given request. The distinction matters because a log records that something occurred, while a runtime enforcement record documents a decision made on a specific interaction or tool call before it executed: which policy applied, which version, and whether the outcome was allow, redact, block, rate limit or escalation for human approval.

Neither form is defined or required by the letter. But the layered-controls language implies that no single control should carry the whole burden, and a control that is only reviewed periodically cannot prevent or mitigate anything in the moment. A useful test is to take each written AI policy and ask where in the execution path it is technically enforced. Policies with no enforcement point depend entirely on after-the-fact review.

Trussed is one example of this pattern. It enforces policy in the execution path across models, agents, tools and MCP servers, at the level of individual interactions and tool calls, and generates audit-ready evidence from that enforcement, mapped to NYDFS among other frameworks. It can be self-managed in the customer cloud with configurable retention and data residency. Whatever tooling you use, enforcement records should be durable, queryable, and kept separate from application logs so an examiner or independent auditor can retrieve them without reconstructing events from raw telemetry.

Tradeoffs and governance considerations

Enforcement in the execution path adds a dependency to every model and tool call, so availability and latency need to be engineered and tested as seriously as any other shared platform service. Policies that block too broadly push teams toward unmanaged AI use, so rollout often starts with narrow, high-risk actions and expands as policy matures. Human approval escalation suits consequential tool calls but should be reserved for them, or reviewers will become a bottleneck.

Governance remains shared. Senior officers and governing bodies are expected to oversee third-party service provider risk, and cybersecurity policies need at least annual review and approval. Platform teams contribute by making AI policies concrete enough to enforce and by producing records that leadership and auditors can examine. Because the letter frames its controls as layered, runtime enforcement should sit alongside risk assessment, access management and monitoring, not replace them.