NYDFS Part 500 Step-Up Authentication for Copilot Studio Agent Actions

What Part 500 says about authentication, and what it leaves open

Current 500.12(a) states that multi-factor authentication shall be utilized for any individual accessing any information systems of a covered entity. Entities with a 500.19(a) limited exemption have a narrower set of required MFA cases, which include remote access to third-party applications, including cloud-based ones, from which nonpublic information is accessible. DFS's AI industry letter adds no new requirements. It explains how covered entities should apply the existing Part 500 framework, including risk assessment and access controls, to AI-related cybersecurity risk, and it names robust access controls, including MFA, as a defensive measure.

Two details matter for agent design. Part 500 defines an authorized user as any employee, contractor, agent or other person that participates in the business operations of a covered entity and is authorized to access its systems and data. And DFS FAQ text states that MFA must be enforced at the user's login to the SSO system, as part of the identity provider's authentication process.

Together these mean the documented MFA point is sign-in. Nothing in this text says whether a later agent-initiated action needs its own authentication event, and it does not settle whether an agent is itself an MFA subject. Treat per-action step-up as an additional layer that you can defend through the risk assessment under 500.9 and 500.2(b), which DFS describes as the foundation of the cybersecurity program. DFS does not require a specific framework for it, so document why each tier exists.

Where platform controls end and runtime enforcement begins

A Copilot Studio agent acts on behalf of a signed-in user and can call connectors, flows and other tools. The user's session may have been authenticated hours earlier at a lower assurance level than the action now requires. Sign-in establishes who the user is. Connector permissions establish what the user's identity can reach. Data policy settings constrain which services can be combined. None of these, on their own, evaluates a specific tool call against the assurance of the originating authentication, and none produces a decision record an examiner can read.

That gap is the reason for a control point in the execution path. NIST's agent identity guidance points the same way: define risk thresholds that trigger human review, keep the ability to contain or revoke an agent's authority at runtime, and avoid long-lived bearer tokens and static secrets in favor of ephemeral access acquired when a task starts. A sign-in-only model cannot do any of that after the session begins.

Keep the division of labor clear. The identity provider continues to enforce MFA at login. The runtime control decides, per action, whether the existing authentication is sufficient for what the agent is about to do.

Classify agent actions into risk tiers

Start from your own risk assessment, not a generic template. Inventory every connector, flow, plugin and MCP tool the agent can call, then assign each action to a tier based on what it can do to nonpublic information and sensitive systems. The following example tiers are a starting point. Record the rationale for each assignment, because examiners will ask why an action sits where it does.

• Tier 1: Low-sensitivity read: Reads public or non-sensitive data. Allow under the existing session.
• Tier 2: Nonpublic read: Reads nonpublic information within the user's normal scope. Allow, with redaction where the output exceeds what the task needs.
• Tier 3: Record change or data movement: Modifies a record or moves data to another system or a third-party or cloud application. Step-up if the originating authentication is stale or weak.
• Tier 4: Privileged or bulk action: Calls a privileged API or acts at bulk scale. Escalate for human approval, or block.

Evaluating runtime enforcement approaches

Whatever you build or buy, test it against a short set of questions. Does the enforcement point sit in the execution path at each tool call type you use, and does it evaluate policy before the action runs? Can it return allow, redact, block or escalate, with thresholds tied to your risk tiers? Does it preserve the originating authentication's method, time and assurance level so the decision traces to the identity provider's MFA event? Can decision records be exported for examiners, and is retention configurable?

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, scoped to individual interactions and tool calls. Outcomes include allow, redact, block, rate limit and escalate for human approval, and the enforcement produces audit-ready evidence mapped to NYDFS among other frameworks. It can be self-managed in the customer's cloud with configurable retention and data residency. Trussed does not claim transaction-level governance or end-to-end tracing of agentic workflows, and it has no financial-services customers to cite. Insurance, a regulated financial sector, is where it is deepest. Its production record includes 18+ months in a regulated enterprise and 99.95% uptime on live production traffic.

The practical next step is independent of any vendor: pick the five highest-consequence actions your agents can call, assign tiers, and write down the trigger and approver for each.