Agentic AI Workflow Governance in Fintech for 2026

On October 13, Reuters reported that the Fed, OCC, and FDIC have started asking banks pointed questions about AI agents. What limits are placed on these systems. How their actions are monitored and approved. Whether agent decisions can be tracked and audited. What stops an agent from exceeding its authority. Whether humans stay involved in key decisions. And how the bank would shut an autonomous system down.

Supervisors are still gathering information, and none of it is a rule yet. If you run engineering at a fintech, that doesn't buy you much time. Every one of those questions is about to show up in your sponsor bank's diligence questionnaire, your next SOC 2 walkthrough, or an enterprise customer's security review, phrased slightly differently and with a deadline attached.

Most fintech teams respond to that pressure the same way. They add a review step. Then another one. Within a quarter, the agentic AI development workflows that were supposed to make delivery faster are waiting on a governance meeting that happens on Thursdays.

There's a better pattern, and it's the one platform teams already used to make deployment both safer and faster: move the controls out of the calendar and into the path the work travels. We call it governance in the path. Keep the two human decisions that need judgment. Automate every other control into the platform, so it runs on every agent action without anyone scheduling it.

This guide covers why governance breaks in fintech, what the questions from regulators and bank partners actually require, and how to build delivery, compliance, and operational controls that hold up without slowing your AI development teams down.

‍

Why fintech teams struggle to govern agentic AI development workflows

The short version: your controls were designed for humans working at human speed, and agents broke both assumptions at once.

A fintech's change management process usually assumes a person wrote the code, a different person reviewed it, and the volume is low enough that a human can look at every change touching money movement. Agents raise the volume, blur who wrote what, and act through credentials that were never meant to be held by software. The controls still exist on paper. They just stop describing what's happening.

We covered the full list of reasons pilots stall in 10 reasons fintech agentic AI workflows stall. Three of them are governance problems specifically, and they compound.

The first is that governance gets added as meetings. When nobody can explain what an agent is allowed to do, the safe answer is to have a human approve everything it does. That works for a pilot with one workflow. It doesn't survive the second team, because the approver becomes the slowest step in the delivery loop. Cadence equals your slowest approval loop, and you just added a new one.

The second is that evidence gets reconstructed after the fact. Ask most teams to show which agent made a given change, on whose authority, with what permissions, and you'll get a week of log archaeology and a partial answer. That's the failure we've called the unowned change, and in a regulated environment it's the one that ends programs, because nobody in your second line can approve a control they can't see working.

The third is that every team governs its own agents. One squad has a careful approval flow, another runs agents on a shared service account, and a third wired an MCP server to production from a laptop. None of them did anything unreasonable. There just wasn't a paved route, so each team built its own, and your compliance posture is now the posture of your least careful squad.

All three are AI implementation challenges that look like culture or process problems. They're platform problems.

‍

What regulators and bank partners are actually asking

The formal rulebook still doesn't cover agents. The revised interagency model risk guidance issued April 17, 2026 (SR 26-2 at the Fed, OCC Bulletin 2026-13 at the OCC) replaced SR 11-7 and says it directly: "Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance." The agencies have said a request for information on bank AI use is coming.

That gap is now being filled informally. The questions in the Reuters report are aimed at banks, but fintechs inherit them. A sponsor bank's third-party risk team can't approve a partner whose agents it can't explain to its own examiners.

Translated into what your platform has to be able to show, the six questions become six capabilities:

1. Every agent has a defined scope of action, written down somewhere a machine enforces it.
2. Every agent action is logged with enough context to reconstruct it.
3. Approvals are recorded, attributable to a named human, and tied to the change they approved.
4. Authority is enforced by the platform, so an agent physically can't exceed it, rather than by a policy document that says it shouldn't.
5. You can show where humans make decisions and why those points were chosen.
6. You can stop any single agent, quickly, without taking down the services it shares infrastructure with.

None of these is exotic. Each one is a platform engineering capability your team has probably already built for human engineers in some form. The work is extending it to a new kind of user.

‍

Governance in the path: three layers of control

Governance for agentic AI development workflows splits cleanly into three layers, and the mistake most teams make is solving all three with the same tool, usually a human reviewer.

Delivery governance decides what gets built and what gets shipped. Compliance governance proves that your obligations were met on every change. Operational controls limit what an agent can do at runtime and stop it when something goes wrong.

Only the first layer needs regular human judgment. The other two should run automatically, on every action, and produce their own evidence. That split is the whole idea.

‍

Delivery governance: two human gates, sized to risk

Tensure's Spec-to-Ship model runs one loop: clarify, spec, approve, build, validate, accept, release, measure. Agents can support most of those stages. Two stay human. Someone approves the spec before the build starts, and someone accepts the build before it ships.

Those two gates are the right place for human judgment, and they're worth defending. Approving a spec is a business decision about what correct means. Accepting a build is a decision about whether what came back matches it. An agent can draft both artifacts. It shouldn't sign off on either.

What slows teams down is applying the same gate depth to every change. A copy fix in an internal admin tool and a change to how a payment is routed don't deserve the same review, and when they get it, your fastest work moves at the speed of your riskiest.

Tier the gates by risk instead. Base the tiers on what the change touches and how reversible it is, rather than on which team wrote it.

At the low end sits work that's internal, non-production, or trivially reversible: test generation, documentation, service scaffolding, CI failure diagnosis. Here the spec approval can be lightweight and the acceptance can be automated against the acceptance criteria, with a human sampling the output rather than reading all of it.

In the middle is production work that's reversible with a known rollback: most feature work, dependency updates, defect remediation. A named human approves the spec and accepts the build, and the platform enforces that those are two different people.

At the high end is anything touching money movement, ledger logic, credit decisions, customer data access, or a system without a tested rollback. Full spec review, human acceptance, and in most fintechs, a second approver from risk or compliance. Agents can still do a lot of the work here. They just don't get to run it unsupervised.

The tiers only work if the spec is good enough to review. If your acceptance criteria only make sense to the engineer who wrote them, the gate turns into a conversation and the cadence goes with it. Specs written for agents look different from user stories written for people, which we covered in from user stories to specs for AI agents.

Once the tiers exist, the cadence question gets concrete. Weekly gate decisions give you a standard delivery rhythm. Twice weekly is where most AI-enabled teams should land. Daily is AI-native, and you only get there when the low tier is mostly automated and the high tier has a dedicated approver who isn't also running three other meetings.

‍

Compliance governance: evidence as a byproduct

Your existing obligations don't care whether a person or an agent made the change. SOC 2 change management, PCI-DSS change control for anything in cardholder data scope, segregation of duties, access reviews, and records retention all apply to the action. The question is whether proving compliance costs you a review meeting or costs you nothing.

It should cost nothing, and it can, if the policy lives in the pipeline instead of in a document.

Policy as code is the core of this layer. The rules your compliance team cares about get written as checks that run on every agent change before it can merge or deploy: no agent can approve its own pull request, no change to a high-tier service merges without a recorded human acceptance, no credential with production write access gets issued without a ticket reference, no change to cardholder data scope deploys outside the approved path. Our compliance and policy enforcement work is mostly this: turning the policy binder into checks the platform runs.

Then make evidence a byproduct of the work. Every gate decision, every policy check result, every agent run should write a structured record automatically: which agent, which version of the model and prompt and tool definitions, acting for which human, under which tier, with what result. When your auditor asks for a sample of twenty changes with approvals, you run a query. When your sponsor bank asks how you know an agent didn't exceed its authority, you show them the check that would have blocked it and the log of it passing.

Pin versions as part of that record. Agents drift quietly when a model updates or someone edits a shared prompt template, and a log that says "the agent did X" is much less useful than one that lets you replay the exact run from three weeks ago and get the same answer.

Fintechs have an advantage over banks here. You don't have twenty years of change advisory process to unwind. You can build the evidence trail into the platform before the first audit asks for it, which is far cheaper than retrofitting it after a finding.

‍

Operational controls: what an agent can do at runtime

Delivery and compliance governance decide what should happen. Operational controls make sure nothing else can.

Start with identity. Every agent gets its own identity, scoped to the task, with short-lived credentials issued by the platform. Shared service accounts are the single most common reason agent programs can't pass a security review, and the OWASP Top 10 for Agentic Applications ranks identity and privilege abuse third for that reason. When an agent acts on behalf of a person, that person's permissions should bound what the agent can reach. Secrets and identity management for agents is the same discipline you already apply to people and services, with shorter lifetimes and narrower scopes.

Then control the tools. Agents act through tools, so the tool layer is where authority actually gets enforced. Keep a registry of approved tools and MCP servers, pin their versions, review their definitions, and have the platform issue the credentials they use. Teams wire their own tool stacks when the governed route is slower than the ungoverned one, so make the registry the easy option. The same thinking that built your golden paths for human engineers applies here.

Contain the blast radius. Rate-limit agents per action, put circuit breakers on calls into core services, and scope each agent's network and data access to what its task needs. A retry loop with write access to a ledger service is a very different incident from a retry loop that can only hit a sandbox.

Build the kill switch, and test it. This is the question regulators asked most directly: how would you shut it down? The honest answer at most fintechs right now is "revoke the shared service account and hope," which also stops every other workflow using it. Per-agent identity makes a per-agent stop possible. Run it as a drill the way you'd test a failover, with a named owner and a time target. A kill switch nobody has pulled is a diagram.

Finally, watch agents the way you watch services. Agent runs need traces, error budgets, and alerts, wired into the same observability and SLO stack your on-call team already uses. If agent failures only show up in a separate dashboard nobody checks, you'll hear about them from a customer.

‍

Where governance goes wrong

Governance in the path isn't free, and some versions of it make things worse.

Logging everything and reading nothing is the most common. A structured log of every agent action is only evidence if someone can query it and the fields mean something. Decide up front which questions the log has to answer (the six above are a good start) and design for those, rather than capturing every token and hoping.

One tier for everything is the second. Teams that are nervous about agents often put every change in the high tier "for now." That's governance by committee with extra steps, and it teaches engineers that the governed route is the slow one, which is exactly how shadow agent stacks get built.

Waiting for the policy before the pilot is the third. Some fintechs freeze agentic work until compliance has written a full AI policy. The policy then gets written in the abstract, by people who've never seen an agent run, and it either blocks everything or says nothing. Start with one low-tier workflow, build the controls around it, and let the policy describe controls that already exist. That's the argument behind starting one workflow wide.

And treating governance as a security project is the fourth. Security owns a lot of the operational layer, but delivery governance belongs to product and engineering, and compliance governance needs your compliance lead in the room while the checks are designed. When one team owns all three layers, the other two get built badly.

‍

A sequence that works

You don't need all of this before agents touch anything. You need it in roughly this order.

Inventory first. List every agent that can currently write to a repository, a pipeline, or a production system, along with the credential it uses. Most teams find more than they expected, and the list itself is your first piece of audit evidence.

Then fix identity. Move each agent off shared accounts onto its own scoped, short-lived identity. This is the change that unlocks almost everything else, including attribution and a working kill switch.

Then tier the work and set up the two gates for each tier, starting with the low tier so you get a fast, fully automated path working early. That's the proof point that governance can make delivery faster.

Then encode policy as checks in the pipeline and turn on structured evidence for every run. Test the kill switch on a real agent. Only then widen to the middle tier, and later the high tier, as the controls prove themselves.

Each step maps to how far you can safely move along the maturity stages. Teams at Agent-Enabled can run bounded workflows with human supervision on a fairly thin control set. Agentic Delivery, where agents plan, build, and test from governed specifications, requires the full governed agent platform: identity, tool control, automated evaluation, risk-based approvals, and rollback. Autonomy is earned one control at a time, and you're only as far along as your weakest pillar, whether that's Platform Engineering, the SDLC Operating Model, or Business Intent and Requirements.

If you want to know where your team stands across those three, our agentic engineering maturity assessment scores each pillar separately and shows which one is setting your limit. For the platform side of the work, our agentic engineering practice builds governed agent platforms that stay observable, governed, and yours, with no lock-in.

And if a sponsor bank questionnaire is already sitting in your inbox asking how you'd shut an agent down, talk to us. That's a question with a concrete answer, and it's a lot easier to give once the platform can show it.