NYDFS Part 500 vs Reg S-P access control requirements: can one control set cover AI agents?

Where the two regimes start from different places

Part 500 is the NYDFS Cybersecurity Regulation. It requires a risk-based cybersecurity program with written policies covering governance, access controls, third-party service provider risk management, training, monitoring, vulnerability management, incident response and encryption. Which sections bind a given entity depends on its 500.19 exemption status and on whether it is a Class A company. That status changes obligations such as privileged access management under 500.7(c) and the scope of MFA.

Amended Regulation S-P is the SEC's framework, with safeguards and disposal rules, an incident response program and service provider oversight. Its applicability follows the SEC's registrant categories, not DFS licensing. An institution subject to both regimes therefore starts with two separate applicability determinations, and the first comparison point is scope, not controls.

That difference matters for AI agents because an agent often touches the same nonpublic information regardless of which regime a given record falls under. The control can be shared. The obligation it supports may not be.

Requirement-by-requirement view for AI agents

The table sets out what Part 500 text requires, how that reads when the actor is an agent, and whether the control is a candidate for sharing or needs a regime-specific overlay in the Reg S-P mapping.

• Access limitation and privileged accounts: Part 500.7(a) limits user access privileges on systems that provide access to nonpublic information to what the job needs, based on the risk assessment. It also limits the number of privileged accounts and their use. For an agent, scope access per tool and per data store. Treatment: shared baseline.
• Periodic access review: Part 500.7(a) requires review of all user access privileges at least annually, with removal of access no longer necessary. For an agent, include its credentials and tool permissions in the review. Treatment: shared baseline, with review cadence set to the stricter expectation.
• Authentication: The amended MFA text requires MFA for any individual accessing a covered information system, with narrower scope for 500.19(a) exempt entities. CISO-approved compensating controls must be reapproved annually. How agent credentials meet this is an open interpretation point. Treatment: document the reasoning once, reuse it.
• Third-party service providers: DFS expects TPSP policies to address access controls, encryption, due diligence and contractual protections for providers with access to systems or nonpublic information. Model and tool vendors fall in scope. Treatment: shared vendor tiering, with regime-specific contract and oversight terms.
• Incident response and notification: Part 500 requires written incident response policies. Notification triggers and clocks are defined per regime. Treatment: regime-specific. Keep one detection path and one decision record, with separate notification workflows.
• Evidence and approvals: Class A companies must monitor privileged access activity. CISO written approvals are documented governance artifacts. Treatment: one underlying evidence store, rendered in the format each examiner requests.

Does one control set hold up?

For access control, a shared baseline is defensible. Least privilege, periodic review, authentication and vendor access are universal safeguards concepts, and 500.7 states them in unusually specific terms. Writing the control set to the most specific text, then mapping it clause by clause to the Reg S-P safeguards provisions, avoids maintaining two parallel programs.

The claim weakens at four points. Applicability differs, so a control may be mandatory under one regime and a good practice under the other. Notification timing is set per regime, so a shared detection capability still needs separate clocks. Evidence expectations differ in format and in what examiners ask first. And the review cadence, annual under 500.7, is a floor for humans that says nothing about agents acting continuously.

The practical position is a single control library with regime tags, not a single undifferentiated control set. Each control carries its source requirement, its owner and the evidence it produces.

Treating an AI agent as an actor

Part 500.7 is written in terms of users and privileged accounts. DFS's October 16, 2024 industry letter states that it imposes no new requirements beyond Part 500 and explains how to apply the existing framework to AI cybersecurity risk, including through access controls and TPSP management. It names risks such as social engineering, theft of nonpublic information and supply chain dependencies, and stresses layered, overlapping controls so that other controls limit impact if one fails.

The text does not settle whether an agent or its delegated credentials count as a user or a privileged account. Decide this explicitly, document the reasoning, and apply it consistently. Treating agents with broad tool access as privileged accounts is the more conservative reading and brings monitoring expectations into view.

An annual review confirms what an agent was permitted to do. It does not show what the agent did at 2:14 on a Tuesday when it queried a customer data store through a tool call. Closing that gap means enforcing access at runtime, at the level of the individual interaction, instead of reviewing it after the fact. The same layered logic DFS describes applies: scoped credentials, authentication, vendor controls and runtime enforcement each cover failure in the others.

Evaluating mechanisms that enforce policy in the execution path

Whatever mechanism you choose, test it against the questions an examiner would ask. Does it decide before the tool call completes, or only record it afterward? Can it act on a single interaction, not just a session or an application? Can it redact or block part of a response, and route a high-risk call to a human?

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, with allow, redact, block, rate limit and escalate for human approval, scoped to individual interactions and tool calls. It generates audit-ready evidence mapped to NYDFS, among other frameworks, and deploys self-managed in the customer cloud with configurable retention. Insurance is where it is deepest. Use the same criteria for any alternative.

• Enforcement happens before the action completes, not after
• Decisions are scoped to individual tool calls and data stores
• Escalation to human approval is supported and recorded
• Evidence is durable, retention is configurable and records map to each regime
• Deployment keeps nonpublic information within your own cloud boundary
• Policy changes are versioned so past decisions can be reconstructed