NYDFS Part 500 MFA and AI Agents: Applying 23 NYCRR 500.12 to CrewAI and OpenAI Agents SDK Service Agents

What Part 500 says, and what it does not say

As of November 2026, section 500.12(a) of 23 NYCRR Part 500 provides that MFA "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). Entities with that exemption must still apply MFA to remote access to their 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 types of authentication factors, the first listed being knowledge factors such as a password.

DFS guidance states that the 2023 amendment phased in new requirements from November 2023 through November 2025, and that as of November 2025 MFA must be in place for all Authorized Users, including customers, employees, contractors and third-party service providers. DFS's industry letter on AI-related cybersecurity risk says it imposes no new requirements beyond Part 500 and explains how to use the Part 500 framework to assess those risks.

Two other provisions matter here. Section 500.7(a)(1) requires, based on the risk assessment, that user access privileges to information systems providing access to nonpublic information be limited to those necessary for the user's job. Section 500.11 requires written policies on the access controls of third-party service providers, including their use of MFA as required by 500.12. The text speaks of "individuals" and "users." It does not name agent frameworks or address non-human identities, so any position on service agents is an interpretation, not a quotation of the rule.

Separating human-initiated paths from service-agent paths

The useful question is not which framework built the agent. Whether it runs on CrewAI, the OpenAI Agents SDK or something else, ask who or what presents the credential at each hop, and whether a person is authenticating at that moment.

• Administrator or developer access: People who sign in to deploy agents, change tool permissions or read credential stores are individuals accessing information systems. MFA applies. Privileged and remote paths deserve the closest attention.
• Human approval of an agent action: When a person approves a sensitive action, the approver is an individual. Evidence should link the approval to an MFA-protected sign-in.
• Autonomous call with a stored credential: The agent presents a service account, API key or token with no interactive sign-in. Whether 500.12(a) reaches this path is the open question, so a documented, risk-based position is needed.
• Agent calling a third-party application: The provider's access controls fall under the 500.11 policy. Remote access to third-party applications holding nonpublic information is one of the categories expressly named for MFA.

Building a defensible position for non-interactive agents

A defensible position treats the agent credential as an access path to be justified, not an exception to be ignored. Start with an inventory: every agent, the credential it uses, the systems and third-party applications it can reach, and whether nonpublic information is accessible. Note which credentials have privileged or remote reach, since those are the categories the regulation singles out even for entities with a limited exemption. Confirm also whether your entity holds a 500.19 exemption or is a Class A Company, because that changes which provisions apply.

Then record the rationale where MFA cannot be applied interactively. Controls commonly used for non-interactive identities include narrowly scoped, short-lived credentials, secrets management so keys are not embedded in agent code, least-privilege tool permissions, and human approval for sensitive actions. These are organizational controls, not requirements stated in Part 500. Present them as such: regulation text, DFS guidance and your own interpretation are three separate layers, and the document should keep them apart.

Assign ownership for the position, record it in the risk assessment because 500.7 is risk-assessment-based, and have counsel review it. Extend access reviews and termination to agent credentials. DFS's requirements checklist describes limiting and reviewing user access privileges, including those of third-party service providers, at least annually and terminating access that is no longer necessary. Treating a decommissioned or reassigned agent as analogous to a departure is a reasonable reading, though it is interpretation. The tradeoff is that an examiner may weigh the same facts differently, so the rationale should be specific to each credential rather than a blanket statement.

Where runtime enforcement at the tool-call level fits

Written permissions only help if you can show they were applied. Trussed enforces policy in the execution path on agent tool calls, including calls to MCP servers. Each interaction or tool call can be allowed, redacted, blocked, rate limited or escalated for human approval, enforced at runtime, not reviewed after the fact. Because the decision is made before the call completes, the permitted scope of an agent is a working control rather than only a document.

That enforcement generates audit-ready evidence continuously, mapped to frameworks including NYDFS. For a Part 500 review, the evidence supports two claims: what the agent was permitted to access, and what it did. Escalation for human approval also creates a distinct event. Where the approver authenticates with MFA, the approval can be tied back to the human path described above.

The scope is specific. Trussed operates on individual interactions and tool calls. It does not provide transaction-level governance across tasks and agents or end-to-end tracing of agentic workflows, and it does not replace credential issuance, rotation or your secrets manager. Trussed has no financial-services customers or deployments to cite. It has run continuously in a regulated enterprise for more than 18 months, with customers in insurance, pharma, healthcare and education, and it deploys self-managed in the customer's cloud with configurable retention and data residency.