Mapping NYDFS Part 500 to AI agent governance

Here is a situation a New York-regulated insurer could face in its next examination. A claims agent runs under a service account in the claims platform. In March it releases a $480,000 settlement payment that a human adjuster would have sent to a manager first. Nothing was breached, and the claim was valid.

The examiner pulls the payment in a sample and asks three things. What initiated it. What that initiator was allowed to do. Who reviewed that account's access this year.

The firm can answer the first from application logs. The other two are harder. The service account could release payments of any size, because the platform's roles have no field for an amount. The annual access review listed it as "claims automation, owner: IT." Nowhere did anyone write down that a model was now deciding which payments to release.

The scenario is illustrative. The questions are not invented. Each one traces to a section of Part 500 that is already in force. In Who answers for the agent? we said we would work through that mapping section by section. This is that piece.

What Part 500 is, and what NYDFS has said about AI

23 NYCRR Part 500 is the cybersecurity regulation of the New York State Department of Financial Services. It applies to banks, insurers and other firms licensed under New York's banking, insurance and financial services laws, which the rule calls covered entities. It took effect on March 1, 2017. A second amendment took effect on November 1, 2023, and its last phased requirements, the expanded multi-factor authentication rule and the asset inventory rule, became due on November 1, 2025. Every section discussed here is now in force.

The regulation does not mention AI agents. NYDFS has addressed AI in three industry letters, and none of them changes the rule.

• October 16, 2024. Cybersecurity Risks Arising from Artificial Intelligence and Strategies to Combat Related Risks explains how the existing rule applies to AI. It says it does not impose new requirements. Most of it covers AI as a threat, such as deepfakes and AI-enhanced attacks. It also asks firms to cover their own use of AI in risk assessments, to watch AI-enabled products for unusual queries that could extract nonpublic information, and to identify every information system that uses or relies on AI.
• May 21, 2026. Two letters. Measures Regulated Entities Should Consider in a Heightened Cybersecurity Threat Environment recommends privileged access reviews, phishing-resistant MFA, and logging and alerting that promptly identify anomalous activity. It says it does not establish new legal requirements. Heightened Cybersecurity Risks Associated with Frontier AI Models, addressed to CISOs, asks firms to evaluate whether their logging and security event alerting are sufficient for the heightened threat. It also says it imposes no new requirements.

None of the three letters names AI agents. So the mapping below is our reading of how existing text applies to software that makes decisions. Where we are not sure, we say so.

What an AI agent is, in Part 500's terms

Every section below turns on one question: when an agent acts, whose activity is it? Part 500 has two definitions that matter.

An authorized user is an employee, contractor, agent or other person who takes part in the firm's business and is authorized to use its systems and data. In our reading, "agent" there means a person acting for the firm, not software. An AI agent is probably not an authorized user in its own right.

A privileged account is an authorized user account or a service account that can perform "security-relevant functions that ordinary users are not authorized to perform." The rule names service accounts directly.

So an AI agent reaches a firm's systems through one of three doors, and each one is already in scope:

1. A person's account. The agent runs in a user's session or as a copy of their role. Its activity is that user's activity under 500.7 and 500.14. We covered why that is a problem in Your AI agent inherited your permissions.
2. A service account. If the account can perform security-relevant functions, it is a privileged account, with the extra duties that brings.
3. A third party's system. A vendor's agent working on the firm's data falls under the third-party service provider rules in 500.11, which this piece does not cover.

This is where we most want counsel's view. Our reading is that the rule does not need to name agents to reach them, because it already reaches every account and system they use. The gap is in the evidence. The controls Part 500 expects were designed for people and for scripts that do the same thing every time. An agent is neither.

The mapping at a glance

The exposure and evidence columns are our reading. The requirements column paraphrases the rule; read the section text before relying on it.

Here is the opening example run through that mapping.

The application log answers the examiner's first question. The decision record answers the other two.

Section by section

500.6 Audit trail

What the rule requires. To the extent it applies and based on its risk assessment, a firm must keep systems designed to reconstruct material financial transactions well enough to support its normal operations and obligations. It must also keep audit trails designed to detect and respond to cybersecurity events that could materially harm normal operations. Records are kept for at least five years.

Where the agent creates exposure. When a script moves money, reconstruction is mechanical. The script did what its code says. When an agent moves money, the transaction record still shows the amount, the account and the time. It does not show why the agent acted, what it was permitted to decide, or whether a person should have seen it first. In our reading, a reconstruction that ends at "the service account released it" may not be sufficient once the thing behind the service account makes choices. That is a judgment for counsel and examiners, not a settled point.

Evidence a governed agent produces. A decision record written at the moment of the action, kept for the same period as the rest of the audit trail:

• the agent, and the run or task it was part of
• the person or process that delegated the task
• the mandate in force at that moment, with its version
• the verdict: permit, escalate to a person, deny, or permit and flag for audit
• the approver, for anything escalated
• the transaction it produced, so the two records join

500.7 Access privileges and management

What the rule requires. Based on its risk assessment, a firm must limit each user's access to systems holding nonpublic information to what the job needs. It must keep privileged accounts few, use them only for the functions that need them, review all access at least once a year, remove access that is no longer needed, and promptly end access after departures. Class A companies, the covered firms above the rule's revenue and headcount thresholds, must also monitor privileged access activity and run a privileged access management solution.

Where the agent creates exposure. "What the job needs" assumes the job is known in advance. An agent's job is assembled at runtime from the tools it holds and the context it reads, so access gets granted for everything it might do. The annual review then checks the account, not the decisions made with it. A scope that allows payment release has no field for amount, timing or counterparty, so a reviewer can confirm the account has an owner but not that its use matched anyone's intent. Departures are a second gap. When the employee who set up an agent leaves, the agent can keep running on authority nobody now holds.

Evidence a governed agent produces.

• a written mandate per agent: what it may decide, the limits, who granted it, and when it was last reaffirmed
• a comparison of what was granted against what was used, so unused authority can be removed the way unused access is
• every mandate tied to its grantor, so a departure flags each one that person granted
• a per-action record of privileged actions taken by agents, which supports the Class A monitoring duty

500.9 Risk assessment

What the rule requires. A periodic risk assessment, documented under written policies, reviewed and updated at least once a year and whenever a change in business or technology causes a material change in cyber risk. The policies must set criteria for rating risks, criteria for judging whether controls are adequate, and requirements for how each risk is mitigated or accepted. The 2024 AI letter adds that assessments should cover the firm's own use of AI.

Where the agent creates exposure. In our reading, giving an agent authority to make business decisions is the kind of technology change that can trigger an update. The harder problem is data. An assessment needs to know which decisions agents make, at what value, and how often they hit a limit. Without that, it can only rate "AI agents" as a category.

Evidence a governed agent produces.

• the decision types delegated to agents, and who delegated each one
• counts and values of decisions by type, agent and business unit
• escalate and deny rates per agent and per policy, so a rising deny rate becomes a measured signal rather than a guess
• a record of who accepted the risk when a business owner widened a mandate, which maps to the rule's "mitigated or accepted" requirement

500.12 Multi-factor authentication

What the rule requires. Since November 1, 2025, MFA for any individual accessing any of the firm's information systems, unless the CISO approves reasonably equivalent or more secure controls in writing and reviews them at least once a year. The 2024 AI letter recommends factors that resist AI-driven social engineering, such as digital certificates and physical security keys, over SMS, voice or video.

Where the agent creates exposure. This is the section where our reading is most likely to be challenged. The rule says "individual." An agent is not an individual and cannot meaningfully complete MFA. Where the rule lists minimum MFA coverage for firms with a limited exemption, it excludes service accounts that prohibit interactive login, which suggests the drafters expected non-interactive accounts to be treated differently. Our reading is that 500.12 does not require MFA for the agent itself.

The real exposure is what happens after login. MFA proves a person was present when the session started. When that person hands a task to an agent that acts for hours on the session or a token derived from it, every later action carries the assurance of the login, not of the decision.

Evidence a governed agent produces.

• each agent action linked to the authenticated person who delegated it, with the scope and expiry of that delegation
• step-up approval: actions above a limit go to a person who authenticates with MFA at the moment of approval, so the strongest control lands on the decision that matters
• a record of who approved, when, and with what factor type

500.13 Asset management and data retention

What the rule requires. Since November 1, 2025, written policies for a complete, accurate and documented inventory of information systems. Each asset is tracked, where applicable, by owner, location, classification or sensitivity, support end date and recovery time objective, and the policies set how often the inventory is updated and validated. The 2024 AI letter asks firms to identify all information systems that use or rely on AI.

Where the agent creates exposure. An inventory is a snapshot. A developer can create an agent in an afternoon, a SaaS vendor can switch one on in a release, and an agent can start another agent at runtime, some lasting only as long as one task. The inventory will always be behind. Note also that the rule inventories information systems, not agents. Whether each agent must be its own line, or is a component of the system it runs in, is a question for counsel. The AI letter's wording is the closer fit.

Our position goes further than the rule: inventory is required and worth doing, but it cannot be the control, because the agent nobody found is the one most likely to cause the problem.

Evidence a governed agent produces.

• a record of every agent that acted through the authority check, registered or not, with the systems it acted on and the authority it acted under
• the grantor of each mandate, which gives the inventory its owner field
• a reconciliation: an agent that appears in decision records but not in the inventory is a finding

One honest limit: this covers actions routed through the check. An agent that never touches that path is invisible to it too.

500.14 Monitoring and training

What the rule requires. Risk-based controls to "monitor the activity of authorized users" and detect unauthorized access to, use of or tampering with nonpublic information. Controls against malicious code, including web and email filtering. Cybersecurity awareness training at least once a year, including social engineering. Class A companies must also run endpoint detection and response and centralized logging with security event alerting, unless the CISO approves equivalent controls in writing. The May 2026 frontier AI letter asks firms to evaluate whether their logging and security event alerting are sufficient for the heightened threat.

Where the agent creates exposure. When an agent acts under a person's credentials, its activity is logged as that person's. A July 2026 Cloud Security Alliance research note found that most organizations cannot clearly distinguish AI agent activity from human activity. Monitoring then watches the wrong actor. In our view, an action that falls inside the agent's scope but outside anyone's intent raises no alert at all, because nothing in the log marks it as unauthorized.

Evidence a governed agent produces.

• the agent and the person it acts for, recorded separately on every action
• every escalate and deny logged as an event when it happens, because an attempt outside the mandate is itself a security signal

What this mapping does not cover

This piece is about agents a firm deploys itself, not AI used by attackers, which is most of what the 2024 letter addresses. It also leaves out four sections that matter for agents: 500.4 on cybersecurity governance, 500.11 on third-party service providers, 500.16 on incident response, and 500.17 on notifying NYDFS. Each deserves its own treatment.

Three questions we think an examiner could ask

This is our expectation, not a prediction of how any examiner will behave. If the mapping above is right, the questions reduce to three.

1. Which agents hold privileged access, and who reviewed that access this year?
2. What evidence shows what each agent was allowed to do at the time it acted?
3. What stopped an agent from going past that?

In our view, identity, access and logging controls can answer part of the first. The second and third need a record of authority, which those tools were not built to keep.

Where BotAris fits

BotAris produces the evidence in the right-hand column of the mapping. People define each agent's mandate in the Authority Model as policy they own, with a named grantor. The enforcement point checks each consequential action against that policy in the action path and resolves it to permit, escalate to a person, deny, or permit and flag for audit. The Accountability Ledger records the mandate the action was checked against, the verdict, the grantor and any approver, at the moment of the decision.

BotAris does not replace your identity provider, your privileged access management, your endpoint detection, your logging or your asset inventory. It uses them as inputs. Because the check sits on the action rather than on a registered agent, it also covers agents that are not in the inventory yet.

BotAris is not a compliance product, and using it does not make a firm compliant with Part 500. Compliance is a judgment about the whole program. What it changes is the answer to the examiner's second and third questions. In the opening example, under a mandate that matched the adjusters' own approval limit, the $480,000 payment would have been escalated to the claims manager, and the record of that escalation would have been in the sample.

Sources. New York State Department of Financial Services, 23 NYCRR Part 500, via Cornell Legal Information Institute: 500.6 Audit trail, 500.7 Access privileges and management, 500.9 Risk assessment, 500.12 Multi-factor authentication, 500.13 Asset management and data retention, 500.14 Monitoring and training. NYDFS, Second Amendment to 23 NYCRR Part 500, effective November 1, 2023, for the definitions in 500.1 and the compliance dates in 500.22 (copy hosted by Gibson Dunn). NYDFS, Cybersecurity Risks Arising from Artificial Intelligence and Strategies to Combat Related Risks, industry letter, October 16, 2024. NYDFS, Measures Regulated Entities Should Consider in a Heightened Cybersecurity Threat Environment, industry letter, May 21, 2026. NYDFS, Heightened Cybersecurity Risks Associated with Frontier AI Models, industry letter, May 21, 2026. Cloud Security Alliance, Hugging Face's Autonomous AI Agent Breach, research note, July 20, 2026. The mapping of exposure and evidence to each section is our position. The opening scenario is illustrative.