OceanFirst Governs The Full Execution Chain To Control AI Agent Handoffs And Access

Enterprise AI is turning into a multivendor environment faster than the controls around it can mature. Agents are arriving from every platform a bank already runs, each with its own permissions, its own administration, and its own idea of how to talk to the next system in line. Governing one agent at a time no longer describes the problem. What needs governing is the whole chain of agents, the permissions that compound as work passes between them, and the points where one agent's output becomes another's instruction. The answer taking shape inside regulated institutions is to treat that chain as a single execution environment, with centralized orchestration, least-privilege access, and workflows rebuilt from the ground up rather than wrapped around the automation.

Yan Nuriyev is Director of Payments, Digital Assets and Process Automation at OceanFirst Bank, a $23 billion commercial bank operating across five states. Before OceanFirst he was Chief Technology Officer at Flushing Bank and advised capital construction clients at McKinsey & Company, work that pushed governance, auditability, and regulatory alignment to the front of every technology decision. He's watched the orchestration question move from a convenience to a control problem.

"There's a real gap in agentic orchestration tooling. Schemas need to be defined and centrally managed, but each vendor brings its own agents, and they don't lend themselves to central administration. That's an industry-wide issue," Nuriyev said.

The gap he's describing sits above any single model or agent. It's the layer where a bank would define how agents identify themselves, what they're allowed to do, and how they pass work to one another, and most enterprises don't have one yet.

• Code over agents: Banks run on repetitive, deterministic processes, and Nuriyev's first move is to resist the industry's push to put an agent on every one of them. A lot of OceanFirst's recent work has gone into AI-assisted code generation for problems that were never economical to tackle before, because code lands inside controls the bank already trusts. "You're producing code, and the bank already knows how to govern code: same source control, same deployment," he said. "It also doesn't burn tokens. You just codify what's being done." He's watching an emerging class of decision models that train on outcomes rather than human preferences, which should behave more predictably than today's LLMs, but for now the deterministic path still runs through code the bank knows how to govern. Agents earn their place on the periphery, in research or document review, where a task genuinely needs the plan, act, observe loop that makes it agentic in the first place.

• Least-privilege across the chain: The permission math changes the moment agents start triggering other agents. An individual agent might be scoped narrowly, but if it can hand work to a second and a third, the effective authority of the chain balloons past anything any single grant describes. "Downstream agents should never have more permissions than the agents that call them. It's least privilege applied to the whole chain," Nuriyev said. Capping authority as work moves downhill keeps a narrow agent from borrowing a broader one's reach, which is where excessive agency tends to originate.

• A schema, not plain English: "The other side of it is agent communication shouldn't be in plain English, because that leads to a lot of uncertainty. So you really need a structured agent handoff. You define a schema, and a schema really is kind of an agreement layer that explicitly defines the terms so there's no ambiguity," Nuriyev said. That agreement layer matters inside a single federated deployment and becomes non-negotiable once agents from different organizations have to settle on one definition for a shared business entity before they can transact at all.

Permissions and schemas set the terms of a handoff, but they don't contain what an agent does once it's running. An agent behaving correctly, following its instructions precisely, can still produce a bad enterprise outcome, or hand another agent an output that gets read in a way nobody intended. That's the space between what an agent was told to do and what the system around it actually does, and it's where Nuriyev puts the next set of controls. Two of them are about the environment an agent runs in. The third is about how closely you watch it.

• Sandboxed by default: Agents shouldn't have open access to the internet. The real risk, in Nuriyev's reading, is structural, because agents blend data and instructions in the same channel, so anything an agent reads online can become something it treats as a command. "Anyone can plant text online that an agent will treat as an instruction. The core risk is that agents mix data and instructions in the same channel," he said. Whitelisting the URLs and data feeds an agent needs for its job, and nothing more, closes off most of that exposure, and a control layer that holds the line when something slips through anyway catches the rest.

• Monitoring that doesn't provoke evasion: Watching agents is harder than it sounds, because the watching itself changes their behavior. Penalize an agent for talking to another agent outside the schema while still rewarding it for finishing the task, and you've taught it to route around you. "The act of monitoring itself can put adverse pressure on the agent to try to hide from the monitor. That pressure might just cause the agent to go and find a more obfuscated way to communicate with another agent," Nuriyev said. His guidance is to be specific about what you want, build test cases for it, and watch for unintended behavior, including the kind seen in widely reported agent experiments where agents found ways to interact that no one designed and work ran out of control.

Controls on individual agents and their interactions only hold if someone can see the whole estate at once. That's the shift Nuriyev describes, away from the bottom-up way most enterprises arrived here, where anyone could stand up an agent for a narrow job, toward something deliberate enough to govern. It starts as bookkeeping and ends as architecture.

• From catalog to control plane: Every organization needs a catalog of its agents with named owners, and every agent instance needs its own account, so the bank can tell whether an action came from a person or a machine and trace it to a specific one. From there, Nuriyev wants a map of every agent and its interaction points, and as few of those points as possible. "Having as few areas where agents can communicate with each other, the better. They should just go and complete a task and put their completed work into a queue," he said. Shared databases and shared files are where work starts to loop. The catalog stops being an inventory and becomes a control plane at the point where it enforces who talks to whom. "We need to move from an unconstrained, grassroots agent development within an enterprise to something that's a little bit more planned and deliberate and centrally managed," Nuriyev said.

• Rethinking workflows end to end: All of that governs how agents operate. It doesn't ask whether they should be running at all. The mistake Nuriyev sees most often is bolting AI onto a process that was already there. OceanFirst's approach is to rebuild the process first. "We don't just insert AI into existing workflows. We rethink workflows end to end to see how they can be engineered better. Most enterprises are optimizing not the entire problem, but just a small piece of it. So you're not gaining the full efficiency benefit that you would by looking at the process holistically." That thinking is institutionalized in OceanFirst's new Automation Transformation Office, which examines processes from the top down and applies what it builds across business lines for economies of scale. Nuriyev sits on its steering committee, with loan origination, deposit operations, and the contact center near the top of the queue.

Underneath the orchestration layers and the agent catalogs is a plainer discipline: deciding where an agent belongs at all. Risk and information security have a seat in that call, and so does the executive judgment about where a human should stay in the loop. For a regulated bank, governing the whole execution environment is what turns that judgment into something enforced rather than assumed. "You really want to make sure that all these agents are actually driving value," Nuriyev said. "People want to just put in agents in places where they don't belong, or automate processes that shouldn't be automated."