NYDFS Part 500 MFA and AI Agents: Applying Section 500.12 to Non-Human Identities

What Section 500.12 requires and to whom it applies

The Second Amendment to Part 500 became effective November 1, 2023. DFS describes its new requirements as phased from November 2023 through November 2025. As amended, Section 500.12(a) states that multi-factor authentication shall be utilized for any individual accessing any information systems of a covered entity, unless the entity qualifies for a limited exemption under 500.19(a). This replaced earlier wording under which each covered entity, based on its risk assessment, used effective controls that might include multi-factor or risk-based authentication.

Entities with a 500.19(a) limited exemption still must use MFA for remote access to information systems, remote access to third-party applications (including cloud-based ones) from which nonpublic information is accessible, and all privileged accounts.

Part 500 defines multi-factor authentication as verification of at least two listed authentication factor types, the first of which is knowledge factors such as a password. DFS's AI industry letter says that as of November 2025 Part 500 requires MFA for all Authorized Users accessing Information Systems or NPI, including customers, employees, contractors and third-party service providers. DFS FAQs add two points: where single sign-on is used, MFA must be enforced at the user's login to the SSO system as part of the identity provider's authentication process, and third-party systems, including cloud service providers, are part of the entity's Information Systems if they store, process or transmit its NPI.

Where the requirement is explicit and where it is interpretation

The explicit part is the scope word: Section 500.12(a) applies to an "individual." The AI industry letter states that it adds no new requirements beyond Part 500 and shows how to use the existing framework to assess AI-related cybersecurity risk. It treats MFA as one of the most effective access controls against AI-enhanced social engineering and unauthorized access. It creates no AI-specific MFA rule.

What the text does not do is say how "individual" applies to service accounts, API keys, automated processes, AI agents or tool-calling credentials. The DFS FAQ ties MFA to a user's login through the identity provider, and it does not describe credentials that authenticate without an interactive login. Likewise, whether a privileged service account falls within "all privileged accounts" for limited-exemption entities is a question the wording leaves open.

Two defensible readings follow. One holds that a non-human identity is not an individual, so Section 500.12 does not reach it directly, while the other access and risk provisions still do. The other holds that an agent acting on behalf of a person, or holding standing privileged access, should be treated conservatively. Either way, the entity should record the decision and its rationale, tie it to the risk assessment, and confirm it with counsel and, where appropriate, DFS. DFS notes that some of its recommendations may go beyond the explicit minimum controls in Part 500, so keep regulation text and guidance distinct when describing what an examiner expects.

Controls that carry the weight when interactive MFA does not fit

MFA is one control in a layered access model. Part 500 is a risk-based program with policies covering governance, access controls, third-party service provider risk, information system monitoring and related areas. Framing non-human identity controls as identity and authentication, access limits, monitoring and third-party controls is a reasonable reading of those areas, but it is interpretation rather than DFS text.

Section 500.7 addresses access privileges. DFS lists 500.7(c), privileged access management and blocking commonly used passwords, for Class A Companies, so its applicability depends on Class A status and any 500.19 exemption. State it conditionally. Asset inventory and monitoring matter because an examiner cannot assess controls over identities the entity has not enumerated or cannot observe. Section 500.11 requires third-party service provider policies to address the provider's access control policies and procedures, including its use of MFA under 500.12. That is relevant to vendors that run AI agents or hold credentials on the entity's behalf. DFS says it reviews policies and procedures on third-party risk during examinations.

For identities that cannot complete interactive MFA, common engineering approaches include workload identity, short-lived credentials, certificate-based authentication and scoped tokens. They reduce credential exposure and limit what an identity can do. They do not replicate a two-factor check, so present them as risk-based controls with a documented rationale, not as MFA equivalents. Finally, a Senior Officer or the Senior Governing Body must review and approve cybersecurity policies at least annually, and policy language on non-human identities and AI agents falls within that review.

Decisions to document for each non-human identity type

Because the text does not settle scope, the defensible position is a written one. For each identity type (AI agent, service account, API key, tool-calling credential), record the following.

• Scope decision: whether the entity treats the identity type as within or outside Section 500.12, with the rationale tied to the risk assessment.
• Entity status: whether the entity is a Class A Company or holds a 500.19(a) limited exemption, and how that changes the MFA and privileged access provisions that apply.
• Privilege status: which identities are privileged, and how MFA or other controls are applied or justified for them.
• Third-party footprint: AI agent platforms, external tools and vendor-held credentials that touch NPI, treated as part of the entity's Information Systems.
• Ownership: a named accountable owner per identity, and the point at which a human approval is required.

Where runtime policy enforcement fits

Runtime policy enforcement addresses one specific gap in this model: showing what an agent was allowed to do and what it did. Trussed enforces policy in the execution path at the level of individual interactions and tool calls, across models, agents, tools and MCP servers. Each interaction can be allowed, redacted, blocked or escalated for human approval, enforced at runtime, not reviewed after the fact. That enforcement generates audit-ready evidence mapped to NYDFS, which supports the access limit and monitoring records listed above, including documentation of human escalations.

This is a complement, not a substitute. Trussed does not replace identity providers, MFA infrastructure or credential management, and it does not decide whether Section 500.12 covers a given identity. Those remain the entity's decisions. Trussed is deepest in insurance, a regulated financial sector, and runs self-managed in the customer cloud with configurable retention and data residency. The scrutiny a regulated enterprise faces over AI activity is the same kind this evidence is designed to answer.