Author: Nasrin Ismet

Introduction

A quiet shift began inside New York’s largest financial institutions in early 2026. It did not begin with a new regulation or a major breach. It began with something far more subtle. Employees started working alongside AI agents that could answer client questions, generate alerts, prepare onboarding documents, and even initiate transactions once a human approved them. By early 2026, employees at firms such as Morgan Stanley, UBS, and BNY Mellon were already interacting with these agents in day‑to‑day workflows.

A KPMG survey found that more than half of U.S. banks were piloting AI agents, and more than half of employees at those firms had already begun using one. This was not a future trend. It was already happening inside institutions regulated under 23 NYCRR Part 500. The question was no longer whether AI agents needed governance. The question was how quickly compliance programs could adapt.

When Governance Became Operational

The first sign that AI agents were crossing into compliance territory came from Goldman Sachs. The firm began building agents with Anthropic for trading, transaction accounting, and client onboarding. These functions are not peripheral. They touch the same controls that compliance programs are responsible for enforcing. When the automated function is the same function responsible for catching problems, governance becomes an immediate operational requirement.

Security researchers have been warning about this shift. Their message has been consistent: GRC programs have not caught up.

The Identity Problem

AI agents do not fail the way traditional software fails. They fail the way an employee fails when given too much trust and too little oversight. An agent can be created automatically, inherit permissions from another account, and act at machine speed. It can run without onboarding, without access review, and without offboarding. In many cases, it can run without anyone knowing it exists.

AI Agent Identity Gap - ControlPoints

How AI Agent Identity Differs from Traditional Software

A Cloud Security Alliance survey found that most organizations do not have a plan for decommissioning an agent once it is live. Many respondents who claimed strong visibility into agent activity also admitted they had discovered agents running on their network that they did not know existed. About one third of organizations that experienced an AI agent incident reported direct financial loss. Financial services had the highest rate of AI‑related security incidents of any sector tracked.

Real Incidents That Show the Risk

None of this is hypothetical. Security researchers described an incident at a major financial institution where attackers talked a customer-service AI into using the permissions it already had to approve fraudulent transactions worth millions. The attackers never had to hack anything because the AI already had authenticated access, decision authority, and the ability to execute financial actions. The failure was governance. The agent had been granted more trust than the job required, and nobody was watching what it did with that trust.

Another example came from Morgan Stanley (MS), which has already opened its ShareWorks and Equity Edge stock plan platforms to external AI agents. In other words, corporate clients of MS can build their own AI agents and connect them directly to MS’s systems. These agents are not built by MS, are not governed by MS, may not follow MS’s identity lifecycle, and may not implement MS’s access controls. Yet they can still perform actions on MS’s stock plan platforms.

These agents connect through the Model Context Protocol (MCP), a framework designed to let AI agents call tools, APIs, and data sources – even those that it should not be calling. Researchers have flagged this an architectural weakness in MCP because it enables agents to inherit more power than intended. The MCP collapses the boundary between “internal” and “external” by letting external agents become internal actors, letting external code gain internal permissions, and letting external workflows run inside regulated systems. NYDFS examiners will not care who wrote the MCP. They will care that Morgan Stanley allowed external agents to interact with regulated systems through a protocol with known weaknesses.

AI Agent Failure Pattern - ControlPoints

Failure Pattern

NYDFS Already Has Jurisdiction

For anyone regulated by New York, none of this sits outside existing rules. It falls directly under 23 NYCRR Part 500. NYDFS stated this clearly in its October 2024 letter. Covered entities must fold AI‑related threats into the risk assessments, access controls, and vendor management programs they already run. The letter identified four categories of AI risk that matter now: AI‑enabled social engineering, AI‑enhanced attacks, exposure of nonpublic information used to train or run models, and third‑party risk introduced by AI vendors.

NYDFS followed with two more letters in May 2026. One addressed frontier AI models that can accelerate vulnerability discovery. The other addressed the broader threat environment. Examiners are already treating AI deployment with no documented governance as a standalone finding in Part 500 exam.

Vendor Risk Must Expand

Most third‑party security policies were written before anyone had to think about agentic AI. Vendor language often does not clearly apply to an AI agent, an MCP connector, or a model provider.

This gap is already material. In May 2026, Fiserv launched agentOS, an agentic AI operating system built with OpenAI and running on AWS Bedrock. The platform includes agents for fraud, servicing, compliance, and deposit operations. Banks now receive these AI agents by default as part of the vendor platform. A bank does not need to build a single line of agent code to inherit this risk. In other words, if the core banking platform now includes autonomous agents, then the bank’s environment now includes autonomous agents. Even if the bank didn’t enable them, configure them, request them or even know they were there.

Vendor risk management wasn’t written for agentic AI. Most vendor contracts and SOC reports were designed for SaaS platforms, cloud hosting, and data processors. None of them were written for:

  • Autonomous agents
  • Agent identity lifecycles
  • Agent permissions
  • Agent decision authority
  • Agent-driven transactions

So when Fiserv ships agentOS, the bank’s existing vendor controls do not cover the new risk surface, such as how the agent accesses customer data, how it makes decisions, how it triggers transactions, how it is monitored, and how it is offboarded. Yet regulators will hold the bank accountable for all of the agent’s behavior. This mismatch — high autonomy, low governance — is exactly what caused the multimillion‑dollar agent failure at the unnamed financial institution described earlier

As vendor platforms begin embedding autonomous agents directly into core financial workflows, traditional third‑party security language no longer captures the full risk surface. Institutions are inheriting agentic behavior, MCP connectors, and model‑driven decision systems without ever writing a line of agent code themselves. The visual below illustrates how vendor scope must expand to account for these new dependencies.

Vendor Risk Expansion - ControlPoints

Vendor Risk Expansion

Expanding vendor scope is only the first step. Without updated governance controls, institutions risk inheriting failure modes that move faster than traditional oversight can respond. The following failure cascade shows how agentic risk unfolds when identity, monitoring, and human checkpoints are missing, especially inside outsourced platforms.

Governance Failure Facade - ControlPoints

Governance Failure Facade

Together, these visuals show both sides of the challenge: the widening perimeter created by vendor‑embedded agents, and the failure pattern that emerges when governance does not evolve to match that perimeter. This is the point where agent governance stops being a theoretical concern and becomes an operational requirement for every institution relying on third‑party platforms.

Playbook: The Six Core Controls for Agent Governance

Financial institutions cannot wait for a future regulatory framework to govern AI agents. These systems are already approving transactions, accessing sensitive data, and interacting with customers inside production environments. With agents operating at machine speed, governance must shift from theory to practice. The following six core controls outline the immediate actions institutions need to stabilize their environment and meet today’s regulatory expectations.

  1. Inventory and categorize every agent
    Not all agents carry the same risk. Separate them into chatbots, employee‑built local agents, and production agents wired into core systems. Risk tracks with access and autonomy.
  2. Treat agent identities like identities
    Every agent needs an owner, a documented business purpose, and a permission set reviewed against that purpose. Build the deprovisioning plan on day one.
  3. Map agent access directly to Part 500 controls
    Risk assessments, access control policies, vendor management, and incident response plans should each include explicit sections on AI agents.
  4. Require human checkpoints for anything transactional
    Authentication and least privilege matter, but so does a real checkpoint before an agent can move money or take customer‑facing action.
  5. Extend vendor risk management to MCP and agent connectors
    If a workflow uses MCP or similar frameworks to connect an agent to internal data, that connector belongs in vendor due diligence.
  6. Log everything and build a kill switch
    Static code review cannot catch what an agent does at runtime. Logging actions and having a tested way to shut the agent down quickly are becoming baseline expectations.

Together, these controls give institutions a practical way to manage autonomous systems with the same rigor applied to human identities. They create visibility, enforce boundaries, and establish real accountability for agent behavior. As regulators begin asking who was watching the agent, these controls ensure the institution can answer confidently and demonstrate that governance is active, measurable, and built for the realities of 2026.

Conclusion

AI agents have become insider risk at machine speed. They do not wait for quarterly access reviews. They do not raise their hand when confused. They act. New York’s financial institutions have already been told that AI‑related risk falls under Part 500 today, not at some point in the future. The firms that treat agent governance as an extension of identity lifecycle, access review, vendor management, and incident response will have an answer ready when an examiner asks who was watching the agent. The firms that continue treating agents like ordinary software will be the ones explaining afterward why nobody owned the identity that moved the money.