Reuters reports that the Fed, OCC and FDIC are questioning banks on whether they can monitor, audit and shut down their AI agents, while the ECB is asking banks to map AI use across their businesses and vendors and finding “significant gaps.” Regulators are moving past general AI policies and asking for evidence of control, and most banks can’t yet see all the AI running inside them.
Commenting on this is Arti Raman, CEO and Founder, Portal26
“Look at what regulators are actually asking: what limits your AI agents have, how their actions are monitored and approved, whether you can audit their decisions after the fact, and whether you can shut them down. Every one of those questions assumes the bank already knows what AI is running across the organization, and most can’t say that with confidence. AI no longer lives in a handful of approved projects. It’s built into the SaaS tools employees use every day, it’s in browser extensions and personal accounts, and agents are increasingly being set up by business teams rather than IT. The ECB’s request that banks map AI use across their businesses and third-party providers is the right starting point, and the reported gaps show how hard that is to do from a policy document or a survey. Banks need a continuous, auditable record of which models and agents are in use, who is using them, what data they touch, and what actions they take. That record is what lets a bank show a regulator its controls work in practice rather than only on paper. The banks in the best position won’t be the ones that use the least AI. They’ll be the ones that can answer these questions with evidence, quickly, the next time an examiner asks. You cannot govern what you cannot see, and regulators are now asking banks to prove they can see.”
At least someone is asking these questions now. Because it will be way too late if someone asks the same questions in a crisis.
UPDATE: Additional commentary has come in:
Jacob Krell, Senior Director: Secure AI Solutions & Cybersecurity, Suzu Labs:
“The regulatory response to AI in banking is plans, approval triggers, and recovery exercises. Those all assume the bank’s own records can be trusted after a compromise. In banking, the records are the money. A database where a stolen password lets an attacker change balances, redirect transactions, or erase transfers is a database where recovery means deciding which version of the truth to restore, and an AI agent that moves fast can finish that fight before anyone opens a ticket.
“There is a technological answer, and banks know it better than they admit. In a permissioned blockchain, the shared-ledger form used between known institutions rather than the public cryptocurrency networks, balances and transactions are stored immutably across many independently operated nodes. No single account can alter the record on its own, every update has to be accepted by consensus, so an AI agent that steals a login can spend what that login controls but cannot rewrite history to hide what it did. The money and the information about the money both live in a form an attacker cannot quietly edit.
“That is also most of what Sarah Breeden’s “bare metal” recovery idea is after. A ledger replicated across independent parties is a copy of the truth a compromised primary network cannot poison, built by design instead of reconstructed by hand. Blockchain has spent a decade filed under cryptocurrency. For banks, immutable storage of money and transaction information is the part worth building on, and I would rather see the Federal Reserve and the European Central Bank push institutions toward it than issue another round of recovery plans.”
ㅤ
Darin Fredde, Sr. Director of Technical Marketing Engineering, Ridge Security Technology Inc.:
“Bare-metal recovery is important, but it should already be part of serious disaster recovery planning. The question is whether the environment you’re restoring can be trusted. If an attacker has compromised firmware, out-of-band management interfaces, or other infrastructure below the operating system, rebuilding the server may simply give the attacker a freshly installed operating system to compromise again. That’s a rather expensive way to reset their workspace.
“AI doesn’t necessarily introduce new attack techniques; it can accelerate existing tradecraft, allowing attackers to discover weaknesses, chain exploits, and expand access faster and at greater scale. Our defensive response needs to match that pace through continuous offensive testing that establishes proof of exploitability, prioritizes real attack paths, accelerates remediation, and independently verifies the results.
“The same principle applies to autonomous AI agents. Human oversight is essential, but permission boundaries, approval requirements, and recovery controls must be enforced outside the agent itself. Ultimately, resilience isn’t demonstrated by having a recovery plan or an AI governance policy. It’s demonstrated by testing whether those controls still work when an attacker finds a way through.”
ㅤ
Doc McConnell, Head of Policy and Compliance, Finite State:
“Regulators are right to emphasize the importance of recoverability, but the AI threat doesn’t materially change the practice. The cybersecurity industry has been evolving for a long time toward assuming that breaches are inevitable, and thinking about how to manage the immediate response and recovery. That requires preserving forensic evidence to understand what happened and having the ability to restore operations from a known-good state. AI may raise the likelihood of a successful attack and the speed at which it spreads, but the fundamentals of resilience are the same.
“The FSB’s guidance on agentic AI is where banks face a newer problem. When an autonomous agent acts on the institution’s behalf, someone has to be accountable for what it did. Ideally, that means human approval before high-consequence actions. At minimum, banks need complete, tamper-resistant records that let them reconstruct every decision an agent made and why. If you can’t audit it, you can’t defend it to a regulator, you can’t recover from it, and you can’t prevent it from happening again in the future.”
ㅤ
Seemant Sehgal, Founder & CEO, BreachLock:
“The regulatory push on human oversight of agentic AI reflects something practitioners inside large banks have been working through for a while, which is that most institutions have not yet defined the specific triggers that require human approval before an agent acts, and the ones that have usually drew the line too far down the decision chain to catch an agent acting outside its intended scope. The useful work for CISOs this quarter is identifying which agent actions in their environment would need to pause for human review and making sure those triggers are enforced in code rather than policy.”
ㅤ
Donald McFarlane, Board Member, Xcape Inc.:
“AI offers enormous opportunities to improve financial services, strengthen cybersecurity, detect fraud, and increase productivity. Nevertheless, people and organizations remain accountable for their decisions.
“When AI-powered attacks operate at machine speed, we must increasingly use automation in our cyber defenses. Alongside this, human accountability must remain, supported by suitable controls and monitoring.
“I strongly favor the report’s pragmatic, risk-based approach over creating another layer of prescriptive regulation. We should apply established principles of reasonable care, clear accountability, and effective risk management, with safeguards proportionate to the potential consequences of failure and abuse.”
ㅤ
Ryan McCurdy, VP of Marketing, Liquibase:
“I think regulators are starting to ask some important questions about AI agents and how much authority companies should give them. Banks already have extensive controls around who can access critical systems and what changes they’re allowed to make. Why would we treat an AI agent any differently? Just because it has access to a production database doesn’t mean it should be allowed to make whatever changes it wants.
ㅤ
“The challenge is figuring out where people actually need to be involved. Having someone approve every action an AI agent takes probably isn’t realistic, especially as these systems become more capable and start doing more of the work themselves. I think companies will have to establish policies that determine which actions can happen automatically and which require someone to review them. Database changes are a good example because one bad change can potentially affect an entire application or the customers depending on it.
ㅤ
“The other part of this is something banks should already be familiar with, which is audits. Financial institutions have spent decades putting controls in place and documenting who approved what. Now imagine an AI agent making hundreds or potentially thousands of changes without a person involved in every decision. How do you prove those changes were authorized and that the appropriate controls were followed?
ㅤ
“I don’t think you can wait until an audit to start piecing all of that together. You need a record of what the agent changed, what policies it passed, who or what authorized it, and what actually reached production. If we’re going to give AI agents more responsibility, I think we have to be equally serious about proving what they did and whether the controls worked.”
ㅤ
John Strand, Owner, Black Hills Information Security:
ㅤ
“I broadly agree with the banking industry’s efforts to improve computer security, including the use of compensating controls as we move into the age of AI. But the idea that switching everything to bare metal, including backup and recovery, will make critical systems more secure reflects a fundamental misunderstanding of the problem.
ㅤ
“Bare metal is not inherently more secure. Virtualization gives us options to restore systems much faster, and moving away from it can make compromised systems harder to take offline and more difficult to recover. We’ve been there before. Before virtualization and SaaS became widespread, recovery was often incredibly complicated and time-consuming.
ㅤ
“And people still need access. Even if those systems run on bare metal, humans need to interact with them and access their data. Attackers can use those same access paths, regardless of whether the systems are bare metal, SaaS, or virtualized. Changing the underlying infrastructure doesn’t eliminate that problem.
ㅤ
“I applaud the intent. But this approach overlooks how attacks unfold and what it takes to recover from them.”
ㅤ
Related
This entry was posted on October 14, 2026 at 1:44 pm and is filed under Commentary with tags Reuters. You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
Regulators’ new AI questions for banks start with “what are you running?”
Reuters reports that the Fed, OCC and FDIC are questioning banks on whether they can monitor, audit and shut down their AI agents, while the ECB is asking banks to map AI use across their businesses and vendors and finding “significant gaps.” Regulators are moving past general AI policies and asking for evidence of control, and most banks can’t yet see all the AI running inside them.
Commenting on this is Arti Raman, CEO and Founder, Portal26
“Look at what regulators are actually asking: what limits your AI agents have, how their actions are monitored and approved, whether you can audit their decisions after the fact, and whether you can shut them down. Every one of those questions assumes the bank already knows what AI is running across the organization, and most can’t say that with confidence. AI no longer lives in a handful of approved projects. It’s built into the SaaS tools employees use every day, it’s in browser extensions and personal accounts, and agents are increasingly being set up by business teams rather than IT. The ECB’s request that banks map AI use across their businesses and third-party providers is the right starting point, and the reported gaps show how hard that is to do from a policy document or a survey. Banks need a continuous, auditable record of which models and agents are in use, who is using them, what data they touch, and what actions they take. That record is what lets a bank show a regulator its controls work in practice rather than only on paper. The banks in the best position won’t be the ones that use the least AI. They’ll be the ones that can answer these questions with evidence, quickly, the next time an examiner asks. You cannot govern what you cannot see, and regulators are now asking banks to prove they can see.”
At least someone is asking these questions now. Because it will be way too late if someone asks the same questions in a crisis.
UPDATE: Additional commentary has come in:
Jacob Krell, Senior Director: Secure AI Solutions & Cybersecurity, Suzu Labs:
“The regulatory response to AI in banking is plans, approval triggers, and recovery exercises. Those all assume the bank’s own records can be trusted after a compromise. In banking, the records are the money. A database where a stolen password lets an attacker change balances, redirect transactions, or erase transfers is a database where recovery means deciding which version of the truth to restore, and an AI agent that moves fast can finish that fight before anyone opens a ticket.
“There is a technological answer, and banks know it better than they admit. In a permissioned blockchain, the shared-ledger form used between known institutions rather than the public cryptocurrency networks, balances and transactions are stored immutably across many independently operated nodes. No single account can alter the record on its own, every update has to be accepted by consensus, so an AI agent that steals a login can spend what that login controls but cannot rewrite history to hide what it did. The money and the information about the money both live in a form an attacker cannot quietly edit.
“That is also most of what Sarah Breeden’s “bare metal” recovery idea is after. A ledger replicated across independent parties is a copy of the truth a compromised primary network cannot poison, built by design instead of reconstructed by hand. Blockchain has spent a decade filed under cryptocurrency. For banks, immutable storage of money and transaction information is the part worth building on, and I would rather see the Federal Reserve and the European Central Bank push institutions toward it than issue another round of recovery plans.”
ㅤ
Darin Fredde, Sr. Director of Technical Marketing Engineering, Ridge Security Technology Inc.:
“Bare-metal recovery is important, but it should already be part of serious disaster recovery planning. The question is whether the environment you’re restoring can be trusted. If an attacker has compromised firmware, out-of-band management interfaces, or other infrastructure below the operating system, rebuilding the server may simply give the attacker a freshly installed operating system to compromise again. That’s a rather expensive way to reset their workspace.
“AI doesn’t necessarily introduce new attack techniques; it can accelerate existing tradecraft, allowing attackers to discover weaknesses, chain exploits, and expand access faster and at greater scale. Our defensive response needs to match that pace through continuous offensive testing that establishes proof of exploitability, prioritizes real attack paths, accelerates remediation, and independently verifies the results.
“The same principle applies to autonomous AI agents. Human oversight is essential, but permission boundaries, approval requirements, and recovery controls must be enforced outside the agent itself. Ultimately, resilience isn’t demonstrated by having a recovery plan or an AI governance policy. It’s demonstrated by testing whether those controls still work when an attacker finds a way through.”
ㅤ
Doc McConnell, Head of Policy and Compliance, Finite State:
“Regulators are right to emphasize the importance of recoverability, but the AI threat doesn’t materially change the practice. The cybersecurity industry has been evolving for a long time toward assuming that breaches are inevitable, and thinking about how to manage the immediate response and recovery. That requires preserving forensic evidence to understand what happened and having the ability to restore operations from a known-good state. AI may raise the likelihood of a successful attack and the speed at which it spreads, but the fundamentals of resilience are the same.
“The FSB’s guidance on agentic AI is where banks face a newer problem. When an autonomous agent acts on the institution’s behalf, someone has to be accountable for what it did. Ideally, that means human approval before high-consequence actions. At minimum, banks need complete, tamper-resistant records that let them reconstruct every decision an agent made and why. If you can’t audit it, you can’t defend it to a regulator, you can’t recover from it, and you can’t prevent it from happening again in the future.”
ㅤ
Seemant Sehgal, Founder & CEO, BreachLock:
“The regulatory push on human oversight of agentic AI reflects something practitioners inside large banks have been working through for a while, which is that most institutions have not yet defined the specific triggers that require human approval before an agent acts, and the ones that have usually drew the line too far down the decision chain to catch an agent acting outside its intended scope. The useful work for CISOs this quarter is identifying which agent actions in their environment would need to pause for human review and making sure those triggers are enforced in code rather than policy.”
ㅤ
Donald McFarlane, Board Member, Xcape Inc.:
“AI offers enormous opportunities to improve financial services, strengthen cybersecurity, detect fraud, and increase productivity. Nevertheless, people and organizations remain accountable for their decisions.
“When AI-powered attacks operate at machine speed, we must increasingly use automation in our cyber defenses. Alongside this, human accountability must remain, supported by suitable controls and monitoring.
“I strongly favor the report’s pragmatic, risk-based approach over creating another layer of prescriptive regulation. We should apply established principles of reasonable care, clear accountability, and effective risk management, with safeguards proportionate to the potential consequences of failure and abuse.”
ㅤ
Ryan McCurdy, VP of Marketing, Liquibase:
“I think regulators are starting to ask some important questions about AI agents and how much authority companies should give them. Banks already have extensive controls around who can access critical systems and what changes they’re allowed to make. Why would we treat an AI agent any differently? Just because it has access to a production database doesn’t mean it should be allowed to make whatever changes it wants.
ㅤ
“The challenge is figuring out where people actually need to be involved. Having someone approve every action an AI agent takes probably isn’t realistic, especially as these systems become more capable and start doing more of the work themselves. I think companies will have to establish policies that determine which actions can happen automatically and which require someone to review them. Database changes are a good example because one bad change can potentially affect an entire application or the customers depending on it.
ㅤ
“The other part of this is something banks should already be familiar with, which is audits. Financial institutions have spent decades putting controls in place and documenting who approved what. Now imagine an AI agent making hundreds or potentially thousands of changes without a person involved in every decision. How do you prove those changes were authorized and that the appropriate controls were followed?
ㅤ
“I don’t think you can wait until an audit to start piecing all of that together. You need a record of what the agent changed, what policies it passed, who or what authorized it, and what actually reached production. If we’re going to give AI agents more responsibility, I think we have to be equally serious about proving what they did and whether the controls worked.”
ㅤ
John Strand, Owner, Black Hills Information Security:
ㅤ
“I broadly agree with the banking industry’s efforts to improve computer security, including the use of compensating controls as we move into the age of AI. But the idea that switching everything to bare metal, including backup and recovery, will make critical systems more secure reflects a fundamental misunderstanding of the problem.
ㅤ
“Bare metal is not inherently more secure. Virtualization gives us options to restore systems much faster, and moving away from it can make compromised systems harder to take offline and more difficult to recover. We’ve been there before. Before virtualization and SaaS became widespread, recovery was often incredibly complicated and time-consuming.
ㅤ
“And people still need access. Even if those systems run on bare metal, humans need to interact with them and access their data. Attackers can use those same access paths, regardless of whether the systems are bare metal, SaaS, or virtualized. Changing the underlying infrastructure doesn’t eliminate that problem.
ㅤ
“I applaud the intent. But this approach overlooks how attacks unfold and what it takes to recover from them.”
ㅤ
Share this:
Like this:
Related
This entry was posted on October 14, 2026 at 1:44 pm and is filed under Commentary with tags Reuters. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.