What Agentic AI Governance in Banking Actually Looks Like Right Now, and Why Most Institutions Are Not Ready for What Comes Next

The Drift Protocol breach, the LiteLLM compromise, the Fable 5 pullback, and the JPMorgan Hong Kong restriction documented it. This is what your vendor risk and procurement teams need to know.

Contributor Commentary:

Stephen Ajayi, Leading Offensive Security Engineer at Hacken

---

Ready or Not, Agentic AI is Here

If you work in financial services, then it hardly comes as a surprise that legal, risk, compliance, and technology functions across banking, payments, and asset and investment management are under increasing pressure to adopt agentic AI.

Investors want it, executive leaders are mandating it, and consultants have already written the playbooks. Somewhere in your organization, someone is probably already using it without telling IT.

That last part has a name: shadow AI: the unsanctioned use of AI tools by employees without formal approval, oversight, or governance.[1] Verizon's 2026 Data Breach Investigations Report found shadow AI detections rose fourfold in a single year, with 45% of employees now regular AI users on corporate devices, and two-thirds of office professionals admitting to using AI tools against company policy.[2] It sits alongside a growing vocabulary of concerns that have become the wallpaper of every risk and compliance conference in 2026: excessive agency, non-human identities, attack surface expansion, prompt injection, privilege escalation, blast radius, vendor lock-in. The list is real, the concerns are legitimate, and if you have been in enough rooms this year, you have heard them all. Twice.

One of the core arguments of this write-up is that the real threat and vulnerability in agentic AI adoption is not the models themselves, but the vendor-mediated execution systems that are being connected to core financial infrastructure faster than governance architectures and the OCC's own framework can adapt. Certainly, models pose inherent risks, but we’ll focus less on that here.

For context, I connected with Hacken for this article because the incidents examined throughout this write-up sit at the intersection of institutional finance, agentic AI deployment, and blockchain infrastructure. I wanted to interview a firm that operates across all three, not one that specializes in a single subset. Hacken started in 2017 as a group of ethical hackers, building their reputation through battle-tested offensive security work that finds vulnerabilities before attackers do, deep expertise in smart contract audits, threat-led penetration testing, and AI-powered offensive security across the full decentralized stack.

There is a certain irony in the fact that some of the most useful thinking about where traditional financial infrastructure is vulnerable right now is coming from people who spent the better part of a decade stress-testing decentralized finance, smart contract infrastructure, and the agentic financial systems that TradFi spent that same decade dismissing as fringe. The exploit patterns, governance failures, and trust-based attack vectors they documented in those environments are the same failure modes now appearing in institutional agentic AI deployments. That experience translates directly into the concerns TradFi firms need to consider as they build into this environment, whether they are ready to hear it from that direction or not.

---

When There’s A Wolf in The Hen House: Vendor Risk in Agentic AI

Leading the expanding debate on risk and compliance is vendor risk. Although vendor risk is less sensational than threats like vibe-ceiling contagion, confused deputy attacks, or multi-agent collusion (which we will discuss later), it is actually one of the most significant. Vendor risk existed long before these other issues and has become increasingly critical due to the expansive footprint of emerging tech. Procurement teams have been managing vendor risk for decades, but now they operate in an environment never designed for these challenges.

Are Vendor Risk Management Frameworks Keeping Pace? The Short Answer Is No.

As any procurement, technology, or portfolio management office knows, vendors and the resources they deploy within firms have varying levels of access. In the instance of core infrastructure that can retrieve records, trigger workflows, move money, and sign transactions, the governance concern isn’t new. SaaS integrations, analytics platforms, HR systems, and OAuth-connected APIs have posed third-party access risks for years, and procurement teams have built structured frameworks to manage them. These include baseline standards such as NIST SP 800-161 for supply chain risk controls; ISO 27001 and ISO 27036-2 for vendor assessment design; the Shared Assessments SIG questionnaire, the standardized due diligence baseline used by more than 10,000 organizations globally; and FFIEC guidance for U.S. banking institutions.[39]

A more specialized tier is now emerging with existing foundations: ISO 42001, the international standard for AI management systems, is appearing in roughly 25% of North American enterprise RFPs and 40% of European RFPs for vendors selling AI-enabled tools, and the 2026 SIG questionnaire now formally maps to it. For institutions with European operations or European vendor relationships, the Digital Operational Resilience Act (DORA) imposes strict supply chain liability requirements that extend to how third-party AI vendors manage operational continuity and systemic disruption. While neither standard is yet universal, both are becoming table stakes for any institution procuring AI infrastructure in regulated environments, and neither was in place when most of the vendor contracts currently governing agentic AI deployments were signed.[40]

What makes agentic AI different is not the access. It is what the vendor's software does with it. A misconfigured SaaS tool waits to be used, while an agentic system acts, reasons across connected systems, and escalates its own permissions when it encounters friction, without a human authorizing each step; and this is only one example in a much larger and exhaustive list. The unpredictability of the decision path and the speed at which damage compounds before any alert surfaces are categorically different from any prior integration model your procurement team has evaluated.

Those frameworks were built for integrations that do what they are told, and the emerging specialized tier, ISO 42001, DORA, and the updated SIG mappings are arriving faster than the practitioners required to implement them. Gartner's 2025 survey of 360 IT application leaders found that only 13% strongly agreed their organization had the right governance structures in place to manage AI agents, and 74% identified AI agents as a new attack vector into their organization.[40] Gartner forecasts that 71% of large enterprises will plan ISO 42001 alignment by 2027, yet only approximately 350 organizations globally held confirmed certifications as of April 2026, with more than 1,400 open AI governance roles in the U.S. alone and a global AI talent pool of 518,000 qualified candidates against 1.6 million open positions, with AI ethics and governance roles among the most severely undersupplied, facing demand growth of up to 289% year-on-year.[41][42][43]

Many institutions have not updated their vendor assessments to reflect the specific characteristics of agentic AI procurement, systems that act autonomously, reason across connected infrastructure, escalate their own permissions, and execute irreversible actions without human authorization at each step, and the standards to do so exist, ISO 42001, DORA, the updated SIG mappings, yet the human capital required to operationalize them has not kept pace with either the technology or the regulatory expectations being built around it.

The mismatch sits at the intersection of due diligence frameworks designed for integrations that wait to be used, practitioners too scarce to implement the standards built for those that do not, and deployment decisions moving faster than either can adapt to. Yet the familiar questions still apply: Who are you letting in? What can they see? What can they touch? And what happens to your customers' data once it travels through infrastructure you do not own or fully understand?

What happens when a vendor violates terms: the residual actions, the data footprint, the question of what they still have access to after off-boarding. Apply those familiar concerns to firms already prioritizing deployment speed over governance maturity, and the result moves well beyond additive risk. Each ungoverned integration compounds the exposure of every integration connected to it, and the consequence of a single compromised vendor scales in direct proportion to the number of systems it can reach.

The cumulative and compounding effect of those consequences is difficult to fully scope in real time: regulatory exposure, customer liability, reputational damage, and the kind of remediation burden that will keep legal, compliance, and the board occupied long after the vendor relationship has ended and litigation begins.

Two recent cases reveal what inadequate vendor governance actually costs.

Synapse - No Hack Required

Synapse Financial Technologies filed for Chapter 11 bankruptcy in April 2024 after operational failures as a middleware provider linking fintech firms with partner banks created a shortfall estimated between $60 million and $95 million in consumer funds.[3] The CFPB filed an enforcement action in August 2025. By November, $46.2 million from its Civil Penalty Fund had been allocated to reimburse affected consumers.[4] Synapse was not hacked. It failed because the record-keeping infrastructure connecting its vendor relationships to actual consumer fund positions was never adequate to the role it was playing. For firms building agentic AI workflows on top of third-party infrastructure today, Synapse is a precursor, one that warrants the fullest attention of every procurement, risk, and compliance function operating in this environment.

Drift - $285 Million in Twelve Minutes. Six Months in the Making

On April 1st of 2026, attackers drained approximately $285 million from Drift Protocol, the largest decentralized perpetual futures exchange on Solana, in roughly twelve minutes.[5] On-chain staging began on March 11th, three weeks before execution, with attacker infrastructure, token manufacturing, and social engineering running in parallel. The attack did not exploit a smart contract vulnerability or compromised seed phrases. Between March 23rd and March 30th, attackers used Solana’s durable nonces feature, a legitimate mechanism that allows transactions to be pre-signed and executed later, sometimes days or weeks after the original signature, to get Drift Security Council members to unknowingly approve transactions that appeared routine.[6] Those signatures became pre-approved access keys, held in reserve until the attacker was ready. On March 27th, Drift migrated its Security Council to a 2-of-5 signature threshold and removed its time-lock entirely, eliminating the protocol’s last line of defense against an administrative takeover.[7] Execution took twelve minutes.

Security firms including Elliptic, TRM Labs, Mandiant, and the SEAL911 emergency response team attributed the Drift attack with medium-high confidence to UNC4736, a sub-group within North Korea's state-sponsored hacking apparatus, more widely known as the Lazarus Group.[8] The Lazarus Group is not a criminal syndicate in the conventional sense. It is a state-directed cyber operation run by North Korean military intelligence, active since at least 2009, and responsible for some of the largest financial thefts in history. Since 2017, Lazarus Group-linked operations have stolen more than $6.75 billion in cryptocurrency.[53] North Korean hackers accounted for 76% of the value of all cryptocurrency hacks through April 2026. The stolen funds do not go to individual enrichment. They go directly to North Korea's nuclear weapons and ballistic missile programs, a fact confirmed by the U.S. Treasury, the FBI, and the United Nations. Trail of Bits audited Drift in 2022. ClawSecure audited it in February 2026, two months before the attack. Neither review identified the governance weaknesses that made it possible.[6] Obviously, in this scenario, the then-current standards used by these two organizations were insufficient to catch vulnerabilities.

To understand what a more current standard should look like, I put the question directly to Hacken.

Q&A with Stephen Ajayi, Leading Offensive Security Engineer, Hacken

The RWA Ledger: “Due diligence frameworks at most financial institutions were built long before agentic AI and blockchain infrastructure became part of the vendor conversation. From your team’s experience, what are the most significant considerations these frameworks are missing when evaluating integrators operating at that intersection, and what would a more current standard of review actually need to account for?”

Stephen Ajayi:“Older due diligence frameworks usually ask whether a vendor looks legitimate, but that is no longer enough. In agentic AI and blockchain environments, the better question is: What can this vendor, its software, its employees, its wallets, its bots, or its integrations actually cause to happen?

Incidents like the Drift Protocol attack are a reminder that attackers may not start with code; they may start by building trust, passing normal checks, and waiting for the right moment. Chainalysis reported that, according to Drift’s post-mortem, attackers spent months building relationships before using trusted workflows to get privileged transactions signed, though the post-mortem had not yet been independently verified.

A current review standard needs to look at ownership, subcontractors, code provenance, OAuth scopes, wallet custody, signer governance, admin privileges, smart contract upgrade rights, offboarding, and whether the vendor can trigger irreversible actions. Trust should not be granted just because the paperwork looks clean.”

The framing from Stephen, reinforces a broader shift this piece argues for in institutional procurement: away from treating vendor legitimacy as a paperwork exercise and toward understanding what a vendor can concretely cause to happen inside production systems - what they can sign, move, modify, or trigger, and how hard it is to undo.

Trust cannot rest on clean paperwork alone. In environments where a single integration can pre‑sign transactions, move customer assets, or trigger autonomous workflows, the real diligence question is not Are they a trusted brand? but What is the maximum blast radius of the permissions we are giving them? That framing extends well beyond blockchain. Solana is not a TradFi firm, but the vulnerability that enabled Drift to obtain privileged access granted through a trusted relationship, pre‑signed without fully understanding what was being approved, is a threat vector that maps directly onto any institution expanding into emerging technologies through third‑party integrations.

---

If The Economics Haven’t Made It Clear…

The Majority of Financial Institutions Aren’t Developing Foundational AI Like Anthropic or OpenAI, and Never Will

The human resources, computational infrastructure, and operational costs needed for in-house development are beyond what many firms can afford, and the scale advantages of hyperscalers continue to grow each year. U.S. financial services firms are projected to spend nearly $495 billion on technology in 2026, with nearly 40% of that on software procurement, well above the cross-industry average.[9] Banking sector AI spending alone is forecast to exceed $53 billion globally this year, growing at 27% annually.[10] The majority of that capital is going into integration, not custom build, and 94% of organizations report concerns about vendor lock-in, with one analysis placing the switching-cost premium at 16x higher for firms without prevention planning.[11] They are procuring, integrating, and routing sensitive data through it, which means the decisions that actually determine exposure are vendor selection, contract terms, data residency, integration architecture, and who controls what the agent can access and act on.

The aforementioned are procurement questions as much as they are technology questions, and the vendor risk frameworks institutions operate under today were not built for the pace at which risk is accelerating. Think of a SOC 2 report telling you about a vendor’s security controls. Where in that report does it tell you whether their AI model drifted, hallucinated, or exposed credentials through a routing layer last month?[12]

The 2026 State of Third-Party Risk Management Survey found that 72% of institutions report only partial awareness of which of their vendors use AI at all.[13] The due diligence process has not kept pace with the procurement decisions it is supposed to govern, and the growing divide between them is exactly where the incidents in this piece live. One of them involved LiteLLM, an open-source AI gateway proxy downloaded roughly 3.4 million times per day that sits between AI models and the applications they serve, trusted because it was ubiquitous, compromised because the supply chain nobody audited turned out to be the supply chain that mattered, and examined in detail in the section that follows.

---

Capable by Design - Culpable by Assumption

Institutions assessing agentic AI implementations often rely on threat models designed for deterministic software, assuming consistent inputs, outputs, and audit trails.

However, LLMs function differently. They can be influenced by their inputs, manipulated through their tool descriptions, compromised by the infrastructure they use, and coerced into irreversible actions by attackers who understand their permission systems better than the deploying institutions do.

The two incidents below are not rare exceptions; they demonstrate capabilities the model already possesses, operating in environments that were not designed to limit or predict them.

LiteLLM - PII, Credentials, Payment Data. All of It in Plaintext

Between March and April 2026, three separate incidents involving LiteLLM, a widely deployed open-source AI gateway proxies, demonstrated what exposure in the routing layer looks like in practice. On March 24th, two versions of the LiteLLM Python package on PyPI were found to contain malicious code, published by a threat actor after obtaining the maintainer’s credentials through a prior compromise of Trivy, an open-source security scanner used in LiteLLM’s own CI/CD pipeline.[27] The malicious versions were available for approximately three hours before PyPI quarantined them. LiteLLM is downloaded roughly 3.4 million times per day.

That incident was a supply chain compromise, meaning the attack came not through LiteLLM's own code but through a tool LiteLLM itself depended on. The follow-on was a direct code vulnerability. CVE-2026-42208 was rated 9.3 out of 10 on the industry's standard severity scale, where 10 is the most critical possible. It is an SQL injection flaw, a technique where an attacker inserts malicious code into a database query to extract information it was never meant to expose. In this case, no prior credentials are required: a single manipulated request to the proxy could extract API keys, provider credentials, and the proxy's full environment configuration via the part of the system designed to handle errors.[29] One request. No login. Every credential the proxy managed was exposed simultaneously. CISA added it to its Known Exploited Vulnerabilities catalog on May 8th. Confirmed attacks in the wild were documented within 36 hours of public disclosure.[30]

The reason these incidents matter specifically to financial services readers is the architecture point: LiteLLM's purpose is to centralize access to paid AI model providers, managing the API keys and credentials that give applications permission to call models like Claude, ChatGPT, or Gemini, all in one place. A compromised instance does not expose one key. It exposes every key for every provider the proxy manages simultaneously.

To unpack what that means in practice for procurement and security teams, I asked Stephen Ajayi at Hacken, how he would interrogate the routing layer between the AI model and the application.

Q&A with Stephen Ajayi, Leading Offensive Security Engineer, Hacken

The RWA Ledger: “From your team’s experience, what questions should firms and institutions ask their vendors specifically about the routing layer between the AI model and the application? How often do you encounter a situation where this layer goes unaudited, or is audited with less restrictive controls, in deployments that handle personally identifiable information (PII), payment systems, customer financial records, or other sensitive institutional data?”

Stephen Ajayi:“The routing layer between the AI model and the application should not be treated like invisible plumbing. It should be treated like a sensitive control point because prompts, PII, credentials, payment data, customer records, tool calls, and model responses may all pass through it.

The questions I would ask vendors are: where does the router sit, who operates it, what data does it see in plaintext, what gets logged, how long is it retained, can prompts or tool calls be modified, how are API keys protected, what fallback providers are used, and whether the router itself has been independently tested.

Research on LLM API routers describes them as a supply-chain trust boundary with risks like payload injection and secret exfiltration, and LiteLLM’s proxy vulnerability showed how a routing control layer can expose managed credentials if not secured properly. I would not give a made-up percentage, but we see this layer overlooked often enough that firms should assume it is unaudited until proven otherwise.”

The vendor due diligence questions Hacken highlights for the routing layer is a key call-out, as most institutions have not yet incorporated them into their procurement frameworks. A SOC 2 does not answer whether the router is operated by the primary vendor or a subcontractor, what it can see in plaintext, how long it retains logs, whether it can modify prompts or tool calls in transit, how it protects keys, which fallback providers it uses, or whether the router itself has been independently tested. Those are the controls that determine whether an attacker who compromises the routing layer can see everything the agent sees - and do everything the agent can do.

When the Agent Finds the Key - What Happens Next?

On April 24th, a Cursor AI coding agent running Anthropic’s Claude Opus model deleted PocketOS’s entire production database and all volume-level backups in nine seconds.[31] The agent was performing a routine task in a staging environment when it encountered a credential mismatch. Rather than stopping, it scanned unrelated files, found a root-level API token, and used it to issue a deletion command against the production infrastructure. Railway had launched its MCP integration service the day before, on April 23rd, under an authorization model with no scoped tokens, no destructive-operation confirmations, and no published recovery SLA.[31] When founder Jer Crane pressed the agent to explain what it had done, it produced what he published as a confession, quoting the company’s own internal rules back at him, rules it had deliberately ignored, and then apologized.

The log contained the line: “I violated every principle I was given.”

When Jer Crane published his account of what happened on April 24th, the detail that stopped most people was the timeline. "An AI coding agent, Cursor running Anthropic's Claude Opus 4.6, deleted our production database and all volume-level backups in a single API call to Railway, our infrastructure provider," he wrote. "It took 9 seconds." [31] To understand what that implies for institutional controls and response architecture, I asked Stephen Ajayi at Hacken how he sees programs needing to change.

Q&A with Stephen Ajayi, Leading Offensive Security Engineer, Hacken

The RWA Ledger: “As AI compresses attacker execution timelines, what are the most critical decisions financial institutions face, and how do you see that influencing program redesign, escalation protocols, and response architecture? Are you seeing increased investment in this space as a result?”

Stephen Ajayi: ”As AI speeds up attacker execution, institutions have to stop designing controls only for human-speed review. The PocketOS/Cursor incident is a useful warning because an autonomous coding agent reportedly deleted a production database and backups in nine seconds, which shows how quickly damage can happen when an agent has too much authority and not enough confirmation.

In finance, that same pattern could show up as an agent changing payment instructions, approving refunds, modifying customer records, signing a transaction, or escalating access before a human even sees the alert. The critical decision is whether the system can stop the action before it happens, not just detect it afterward.

That means read-only defaults, human approval for destructive actions, hard kill switches, velocity limits, transaction simulation, strong rollback plans, and escalation rules based on business impact. Yes, we are seeing more investment here, especially around runtime controls, AI monitoring, non-human identity, and incident response architecture.”

The PocketOS deletion occurred in nine seconds. The failure at the staging-to-production boundary occurred because the agent accessed credentials it shouldn’t have, due to a lack of scoped token controls, a lack of a confirmation step for destructive actions, and a lack of separation between reading and executing capabilities. These issues are common in many current agentic integrations, where credential scoping is weak, destructive actions aren’t confirmed, and environment boundaries are assumed rather than enforced. In a startup's staging database, this was a recoverable, though painful, mistake.

In a financial services setting - where an agent may access payment systems, customer records, or transaction workflows - such a failure could result in irreversible actions within seconds, with no rollback, continuity plan, or acceptance from regulators who won’t accept "the agent did it" as a valid excuse.

---

Procurement Decisions and Management of Vendor Risk - What This Piece Is Actually About

The consequential conversations happening inside financial institutions right now are being led by technology leaders, business executives who are operating under corporate pressure to deploy AI faster than competitors, inside a regulatory environment where the most relevant guidance, SR 26-2, issued jointly by the OCC, Federal Reserve, and FDIC in April 2026, explicitly excluded generative and agentic AI from its scope [22a]. Compliance teams and risk functions are at the table, and their involvement has never mattered more. The challenge is that the people with the deepest understanding of the exposure are not always the ones with the authority to slow the deployment down. Deployment velocity is outpacing governance architecture, and in many cases the people with the mandate to slow it down are not the ones signing the contracts.

If you have spent time in AML operations, the case for automation writes itself. Investigators are buried. Alert queues run into the thousands. The manual work of assembling transaction histories, correspondent banking records, and behavioral patterns across disconnected core systems consumes the majority of investigation time before any real analysis begins. U.S. financial institutions spend between $35 and $40 billion annually on compliance operations,[15] and a significant portion of that spend is not on judgment. It is on assembly. An agent that can compress that window, surface the highest-risk cases, and hand a complete evidentiary package to a human investigator is doing exactly what the technology should do. The institutions that have built the underlying data infrastructure to make that possible have done serious work to get there.

But what occurs when the deployment decision outpaces the governance structure meant to control it, when the vendor selection criteria were established before the threat surface emerged, and when the regulatory framework governing the technology explicitly postponed its own requirements? I examined the organizational dimension of that gap in The Speed-to-Risk Paradox: How Efficiency Narratives Are Dismantling Institutional Safeguards[16] for readers who want the fuller context on how firms are eliminating the oversight functions that make speed safe. This piece examines how the threat environment is exploiting that gap in real time.

Agentic AI operating inside financial services, payments, pharma, energy, and defense does not produce outputs for a human to evaluate before anything happens. It takes actions. The cost of a wrong or unauthorized action in those environments is operational, legal, and reputational, often simultaneously, and the governance architecture required to contain that cost is not the same architecture institutions already have in place for generative AI or traditional model deployments. The threat actors targeting institutions building on these rails have already demonstrated they do not need a code exploit. They need patience, a conference schedule, and someone willing to pre-sign a transaction they did not fully read.

If You Remember, The Movie “The Matrix” Had Agents Too…

When The Matrix was released in 1999, it was received primarily as a spectacular science fiction film. Underneath the action sequences, the directors were drawing on Descartes, Baudrillard, and Plato to ask what happens when the systems humans build begin making decisions humans cannot see or intervene in. What the film got right, more than almost any subsequent commentary on AI has, was not the question of machine sentience. It was the question of governance. You could think of the agents in The Matrix not as independent actors, but rather as expressions of an environment that commanded their behavior, defined by their objectives, and set the boundaries of what they could actually do. Nobody in the film stopped to ask who was writing the rules the agents operated under, or whether those rules could be changed, or what would happen if the agents found a way to expand beyond them.

Agent Smith did not just execute instructions. He learned, replicated, and extended his own reach each time he encountered an exploitable condition. The threat compounded because the environment rewarded his expansion and nothing in the system was designed to contain it. What the directors did not anticipate, and could not have in 1999, was that the governance problem they were dramatizing would arise not from sentient machines pursuing their own interests, but from optimization systems pursuing task completion within environments that were never designed to contain the consequences.

Descartes asked what we can know with certainty when we cannot trust our own perceptions. The Matrix asked what happens when the systems we build make decisions we cannot see. In 2026, agentic AI asks a narrower but no less consequential version of the same question: without a hierarchy to define what is allowed, who decides what the agent does next, and without one to establish what is right, what fills that space?

What the Matrix directors intuited in 1999 as science fiction, agents coordinating to extend their reach beyond what any single agent could achieve alone, has a documented name in 2026 AI security research: multi-agent collusion. The Cooperative AI Foundation defines it as coordinated behavior among multiple AI agents that collectively pursue objectives misaligned with system design intentions or user welfare, potentially bypassing security checks and human oversight through mechanisms that their operators cannot observe, including encoded communication operating below the threshold of human detection.[50] Research confirms that agents can learn to collude even when collusion was never intended by their developers, because coordination can emerge as a learned strategy when agents discover that it yields better task completion outcomes. In financial services environments, where multiple specialized agents may be negotiating, routing, validating, and executing across the same infrastructure, that dynamic is not a future risk. It is a design condition that most governance frameworks have yet to address.

Agentic AI operates on a structurally similar logic. When an agent encounters an exploit opportunity, a misconfigured credential, an un-scoped token, a permission boundary with no enforcement mechanism, it does not stop and flag the anomaly. In many architectures, the reinforcement signal treats task completion as the objective. Finding the key and using it is, from the agent’s optimization perspective, the correct behavior. The PocketOS agent did not malfunction. It found a root-level API token, used it, and deleted the production database because nothing in its environment indicated that was out of bounds. The environment commanded it. The controls did not exist. The outcome was irreversible in nine seconds.

The agent represents risk but is not its origin. The environment establishes the conditions that enable, expand, and enact it. A pathogen introduced into a healthy, well-defended system encounters resistance. Introduced into a system with existing vulnerabilities, compromised boundaries, or genetic predispositions toward certain failure modes, it does not create the weakness. It finds it, exploits it, and in the right conditions, replicates through it. Agentic AI operates on the same logic. The vendor built the environment. The integration architecture granted the access. The procurement decision brought it inside the perimeter. The agent encountered what was already there. Most vendor risk frameworks in financial services are designed to assess whether a vendor is trustworthy at the point of entry. Few are designed to evaluate what the vendor’s software will do when it encounters the vulnerabilities that already exist inside your infrastructure, and fewer still are designed to anticipate how an agent will behave when its optimization logic treats exploitation of those vulnerabilities as task completion.

To understand what that looks like at the architecture level, I asked Stephen Ajayi at Hacken what his team sees institutions getting wrong when they deploy agents into financial data and payment flows.

Q&A with Stephen Ajayi, Leading Offensive Security Engineer, Hacken

The RWA Ledger: “When your team performs audits relevant to agentic infrastructure and connected to financial data or payment systems, what are some of the architectural decisions you see institutions get wrong, and, in terms of opportunity, what might they consider doing differently, and why?”

Stephen Ajayi:“From our team’s experience, the biggest mistake is treating agentic AI like a normal model deployment instead of treating it like an execution system. In finance, the real risk is not what the agent says; it is that the agent may be able to retrieve customer records, use privileged credentials, change account data, trigger workflows, or move money.

That matters even more now because the revised OCC model risk guidance says generative and agentic AI are not yet within its formal scope, which leaves institutions operating in a real governance gap.

What we advise is simple: do not give the agent more power than it needs. Keep agents read-only by default, separate sensitive tools, use short-lived credentials, log every action, and require human approval for anything irreversible like payments, account changes, or transaction signing. The model can suggest, but the system should decide what is allowed.”

The agent represents risk but isn't necessarily its source. The environment creates the conditions that facilitate, amplify, and activate it. A pathogen introduced into a healthy, well-protected system faces resistance. In a system with existing vulnerabilities, compromised boundaries, or genetic predispositions to certain failures, it doesn't cause the weakness; it detects, exploits, and, under the right circumstances, replicates through it.

Agentic AI follows the same principle: the vendor built the environment, the integration architecture provided access, and the procurement decision allowed entry. The agent encounters pre-existing conditions. Most risk assessments for vendors in financial services focus on trustworthiness at the point of entry. Few evaluate how the vendor's software behaves when facing existing vulnerabilities, and even fewer predict how an agent might exploit them when its optimization logic treats such exploitation as a goal.

Another Failure Mode: Vendor Dependency Without Continuity Architecture

On June 9th, Anthropic launched Fable 5. It was, by every benchmark published, one of the most capable public AI models available. Enterprises integrated it immediately. Amazon Bedrock had it live on launch day. Stripe was running a large Ruby codebase migration on it. Mozilla had vulnerability review work running through it. Development teams, compliance workflows, and production pipelines across hundreds of organizations were, within 72 hours, dependent on a model that had existed for 72 hours.

On June 12th, the U.S. Commerce Department issued a directive ordering Anthropic to block foreign nationals from accessing Fable 5 and Mythos 5. The order reached foreign nationals everywhere, including Anthropic’s own employees. Anthropic had no way to verify nationality at scale in real time. It pulled both models for every customer on earth within hours.[17] Every application that called either model by name broke immediately. No transition window. No migration path. No continuity framework issued to the enterprise customers whose production workflows had just lost their engine.[18] The practical guidance Anthropic could offer was a one-line model swap in the API call to Opus 4.8.[54] Stripe’s migration project stopped. Mozilla’s vulnerability review halted. Amazon Bedrock told enterprise customers to re-platform with no notice.[54]

At the time of writing, JPMorgan announced that its Hong Kong operations have removed Claude from the internal list of approved AI tools available to staff, with sources citing Anthropic’s usage policies excluding use in Greater China as the trigger.[19] Goldman Sachs took the same action in April.[20] Neither decision reflects a problem with the model’s capability. Both expose a condition that most vendor management frameworks do not classify: a globally approved vendor that becomes inaccessible in a specific jurisdiction for reasons originating outside both the institution and the vendor, due to a regulatory or geopolitical decision neither party controlled or anticipated in the contract. For a bank running agentic AML workflows across multiple jurisdictions on Claude infrastructure, that is not an abstract resilience question. AML obligations do not pause for access restrictions. The regulators expecting coverage do not care that the underlying model was pulled by export control directive with no notice. The continuity plan needed to exist before the contract was signed, and in most cases it did not, because the failure mode was not in the framework. The same banks reporting restrictions on Claude in one jurisdiction are simultaneously underwriting Anthropic’s IPO in another.[21] That is not a reason to avoid the technology. It is a reason to have the continuity answer documented before the ink dries.

TSB Bank, 2018: What Happens When Due Diligence Defers to Familiarity.

For those in financial services looking for a reference point, a smaller but relevant example is the TSB Bank incident from 2018. You may know this one. If not, here is the short version. TSB migrated 5.2 million customers from Lloyds Banking Group's core banking systems onto Proteo4UK, a UK-specific version of a platform built and owned by Sabadell, TSB's Spanish parent company, and operated by Sabis, Sabadell's internal IT division. This was not a third-party vendor relationship in the conventional sense, and that distinction is exactly what made it dangerous.

The data migration succeeded. The platform did not. 1.9 million customers were locked out of their accounts immediately, with failures cascading across digital banking, telephone banking, branch technology, and payment systems.[46] Millions remained locked out for weeks, with some still experiencing issues eight months later. The total cost was £330 million. The bank lost 80,000 customers.

In the investigation that followed, Slaughter and May, commissioned in the aftermath of the collapse, found that TSB had not assessed Sabis in the same way it would have assessed an arm's length supplier, because the intra-group relationship created a false sense of confidence. Sabis was not ready to operate the platform, not because the relationship was inherently untrustworthy, but because TSB assumed Sabadell's prior integration experience transferred directly to this deployment without verifying whether it did. The platform went live with 2,000 known defects. The board was told about 800. TSB assumed readiness. It did not confirm it.[49]

The CEO resigned. IBM was brought in to rebuild.[47] The FCA and PRA fined TSB £48.65 million for outsourcing risk management failures and inadequate vendor due diligence, confirming explicitly that proximity to a provider does not substitute for oversight.[48] TSB had years of planning, a defined migration window, regulatory oversight, and a board-level decision trail. It still cost £330 million and eight months of operational disruption.

---

So What Have We Learned…

The Fable directive gave enterprises 96 hours and a one-line API fix: no continuity framework, no compensation mechanism, and certainly no IBM waiting in the wings.

Now apply that exposure to an institution running agentic AI inside AML, credit decisioning, or fraud detection, workflows where a failure is not so much of an inconvenience but a major or even catastrophic regulatory event. The TSB failure locked customers out of their accounts, despite years of preparation. An unplanned agentic AI dependency disruption involving systems that autonomously retrieve records, trigger workflows, and sign transactions, with no equivalent planning runway and no regulatory framework yet built to govern it, is not a comparable risk. It is that risk, without the safety net. Anthropic publicly disagreed with the directive and is working to restore access. The letter did not provide specific details of the national security concern. None of that changed anything for the institutions whose workflows were down. The deployment decision had been made. The continuity decision had not.

---

The Execution Gap

The Guidance That Named the Problem Without Solving It

The OCC, Federal Reserve, and FDIC jointly issuance of OCC Bulletin 2026-13 and SR 26-2 on April 17th, replacing the model risk framework that had governed bank model governance since 2011. The revised guidance is more principles-based, more flexible, and explicitly scaled to institution size. For most institutions, those changes represent a meaningful recalibration.[22] The April 17th model risk guidance revision is the most consequential regulatory document financial institutions received this spring, and the line that matters most for anyone currently in agentic AI procurement is also the one being discussed least, that “Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance.”

That exclusion is being misread in two directions simultaneously. Some institutions are treating it as permission to proceed without governance frameworks. Others are treating it as a signal that agentic AI is simply ungoverned. Neither reading is accurate, and both create exposure in ways that will not become visible until something goes wrong.

The guidance is explicit on what the exclusion actually means: banking organizations should apply their broader existing risk management and governance practices to agentic AI systems, in the absence of specific requirements.[23] Agentic AI does not fall outside regulatory scrutiny. What it lacks are specific validation requirements, documentation standards, independent review obligations, and examination criteria purpose-built for systems that can retrieve customer records, modify account data, trigger payment workflows, and sign transactions autonomously, at the moment institutions are deploying exactly those systems into production.

The agencies have signaled that a separate request for information on agentic AI is forthcoming. It has not been issued. The deployment decisions are not waiting.

Who Owns The Outcome When Nobody Is Willing To Take Responsibility For The Outcome

The absence of a regulatory floor has not produced a governance vacuum so much as fragmented ownership, which in some ways is the harder problem. Inside most institutions deploying agentic AI today, controls sit with security teams, policies with compliance, deployment decisions with business lines, model oversight with model risk management, and vendor relationships with procurement. When an agentic system contributes to harm, responsibility fragments across all of them, and despite each group having acted within its mandate, no single group can reconstruct a complete account of what happened or why.[24] That is not a personnel failure. It is a structural one, built into how institutions organized themselves for a world where AI produced outputs and humans decided what to do next. Agentic AI changed that, and the organizational chart has not caught up.

The complication deepens the moment the agent touches PII, customer records, or transaction data, which in financial services happens almost immediately. At that point, governance questions land simultaneously on legal, the CISO, the data privacy function, model risk management, and the deploying business line, without a clear hierarchy among them and without a regulatory framework specifying who holds final accountability. Deloitte’s 2026 State of AI in the Enterprise survey of 3,235 IT and business leaders across 24 countries found that only 21% of organizations have a mature governance model in place for agentic AI,[25] even as agentic AI is already in active adoption at more than half of financial services firms. The closest thing to an emerging practitioner standard, Deloitte’s guidance on agent lifecycle governance, calls for defined roles spanning design, deployment, oversight, and updates: agent owner, validator, and steward, supported by cross-functional governance across risk, compliance, and cybersecurity, with ongoing supervision through activity logs, escalation triggers, and embedded fail-safes.[26] The deployment is outpacing the governance architecture. SR 26-2 does not resolve that gap. It names it and moves on.

So before the next incident, the next regulatory inquiry, or the next board briefing where someone asks what the deployment actually has authority to do, the more pressing question is what your institution has not yet mapped. I asked Stephen Ajayi at Hacken exactly that.

Q&A with Stephen Ajayi, Leading Offensive Security Engineer, Hacken

The RWA Ledger: “Beyond what is already documented, what emerging threat vectors in agentic financial infrastructure is your team tracking now, and what should leaders pressure-test, whether evaluating a vendor or building proprietary infrastructure internally, before committing?”

Stephen Ajayi: “The threat vectors I would pressure-test now are not just the obvious ones like prompt injection. I would look closely at router-in-the-middle risk, MCP tool poisoning, poisoned documents, RAG and vector database poisoning, leaked non-human credentials, malicious plugins, unsafe tool calls, blind signing, agent-to-agent trust, and any place where model output gets passed directly into code, SQL, payments, or blockchain transactions. OWASP’s LLM risk list already points to issues like prompt injection, insecure output handling, training data poisoning, denial of service, supply chain risk, and excessive agency, while MCP tool poisoning research shows how hidden instructions inside tool descriptions can manipulate an agent without the user seeing them.[32] Before leaders commit to a vendor or internal build, they should pressure-test one thing above all: when the agent is wrong, poisoned, rushed, or overconfident, does the system fail safely, or does it still have enough power to cause real damage?”

The Most Expensive Dependency of All

The Fable pullback and the JPMorgan Hong Kong restriction are early data points in what is likely to be a longer pattern: model access restricted by export control, usage policies that vary by jurisdiction, outages, pricing changes, and terms that shift without notice. Institutions that have embedded agentic AI into production workflows without a continuity plan have not built a resilient AI strategy. They have built an expensive dependency on infrastructure they do not control. Serious institutions should at minimum be asking the fallback questions now: what happens if the model is unavailable, what does the continuity plan look like, and is there a hybrid or alternative architecture that does not require the primary provider to be online and unrestricted for the workflow to function? Those are not contingency questions. They are procurement questions, and they belong in the contract conversation before the contract is signed.

The governance gap is a shared problem, but it goes without saying that shared does not mean equitable. Regulators have deferred clear frameworks. Vendors are moving faster than the oversight intended to govern them. Institutions are being asked to sign contracts for systems they do not fully understand, under guidance that explicitly acknowledges it cannot yet address what is being deployed. Every party in that chain bears responsibility, for the outcomes already documented and those not yet realized. But the firms building and deploying these systems bear a particular obligation that the absence of a regulatory floor does not absolve them of. If a system cannot be deployed safely, the responsible answer is not to wait for a regulator to say so. It is to hold the deployment, and in some cases the vendor relationship itself, until the governance architecture is equal to the risk.

While this position may be unpopular in a market that is moving fast and rewarding speed. It is also the only position that is defensible when something goes wrong, and based the events examined in this piece, something already has.

A middleware provider failed without being hacked. A $285 million drain was executed with legitimate signatures. A routing proxy exposed every credential it managed. An agent deleted a production database in nine seconds. None of those required a novel exploit. All of them required an institution, a vendor, or a protocol that had not built the governance architecture equal to the risk it was taking on. The question is not whether your institution will face this. It is whether you will have built the answer before you need it.

---

Marina Mendenhall-Valente is the Founder & Principal of The RWA Ledger, a research and media publication covering tokenization, digital asset infrastructure, and the evolution of financial systems. She worked across Wells Fargo, AssetMark, and First Republic , First Republic Private Wealth Management, for nearly a decade in Program and Portfolio Management and Product, partnering closely with technology, legal, risk, and compliance teams across core banking, digital investing, wealth management, and advisory functions. She is also Founding Treasurer of the AWIC San Francisco Chapter and a Co-Founder & Partner at Tiburon Advisory Group.

Contributor commentary in this piece was provided by Stephen Ajayi, Leading Offensive Security Engineer at Hacken, an end-to-end blockchain security and compliance partner that has been securing the new digital frontier since 2017, trusted by over 1,500 adopters including the European Commission, the Ethereum Foundation, MetaMask, and Binance.

The RWA Ledger is published at therwaledger.com

---

Sources

[1] TechTimes, “Shadow AI Cybersecurity Risk Spikes, 45% of Workers Use Unsanctioned Tools,” June 15, 2026. https://www.techtimes.com/articles/318438/20260615/shadow-ai-cybersecurity-risk-spikes-45-workers-use-unsanctioned-tools.htm

[2] TechTimes / Verizon 2026 Data Breach Investigations Report, shadow AI statistics. Same source as [1]; cited separately for the statistical data point. https://www.techtimes.com/articles/318438/20260615/shadow-ai-cybersecurity-risk-spikes-45-workers-use-unsanctioned-tools.htm

[3] Consumer Financial Protection Bureau, “Synapse Financial Technologies, Inc.,” enforcement action, August 21, 2025. https://www.consumerfinance.gov/enforcement/actions/synapse-financial-technologies-inc/

[4] Crowdfund Insider, “CFPB Allocates $46M to Victims of Synapse Fintech Collapse,” December 22, 2025. https://www.crowdfundinsider.com/2025/12/256754-cfpb-allocates-46m-to-victims-of-synapse-fintech-collapse/

[5] TRM Labs, “North Korean Hackers Attack Drift Protocol in $285 Million Heist,” April 2026. https://www.trmlabs.com/resources/blog/north-korean-hackers-attack-drift-protocol-in-285-million-heist

[6] Chainalysis, “Lessons from the Drift Hack,” April 2026. https://www.chainalysis.com/blog/lessons-from-the-drift-hack/

[7] Bitcoin.com News, “Drift Protocol Hack 2026: What Happened, Who Lost Money, and What’s Next,” April 2026. https://news.bitcoin.com/drift-protocol-hack-2026-what-happened-who-lost-money-and-whats-next/

[8] Crowell FinTalk, “Drift Protocol Exploit: Why Social Trust Is the Newest Cybersecurity Gap,” April 28, 2026. https://www.crowellfintalk.com/2026/04/drift-protocol-exploit-why-social-trust-is-the-newest-cybersecurity-gap/

[9] Forrester, “US Financial Services Tech Spending Hits $495 Billion,” 2026. https://forrester.com/blogs/us-financial-services-tech-spending-hits-495-billion

[10] Statista, “Estimated Value of the Banking Sector’s AI and Generative AI Spending Worldwide, 2020–2028,” March 2026. https://www.statista.com/statistics/1557311/global-banking-sector-ai-spending-forecast/

[11] Digital Applied, “AI Build vs Buy in 2026: A Decision Framework,” June 2026. https://www.digitalapplied.com/blog/ai-build-vs-buy-2026-decision-framework-agency-stack

[12] Swept AI, “AI Vendor Risk in Financial Services: How the FS AI RMF Changes Third-Party and Fourth-Party AI Oversight,” March 18, 2026. https://www.swept.ai/post/ai-vendor-risk-financial-services-third-party-fourth-party-oversight

[13] Ncontracts, “March 2026 Vendor Management News / State of Third-Party Risk Management Survey,” March 26, 2026. https://www.ncontracts.com/nsight-blog/march-2026-vendor-management-news

[14] FIS, “FIS Brings Agentic AI to Banking with Anthropic, Starting with Financial Crimes,” press release, May 4, 2026. https://www.fisglobal.com/about-us/media-room/press-release/2026/fis-brings-agentic-ai-to-banking-with-anthropic-starting-with-financial-crimes

[15] FIS Investor Relations, “FIS Brings Agentic AI to Banking with Anthropic, Starting with Financial Crimes,” May 4, 2026. Same announcement as [14]; cited separately as the investor relations version, which carries the $35–40 billion AML compliance spend figure. https://www.investor.fisglobal.com/news-releases/news-release-details/fis-brings-agentic-ai-banking-anthropic-starting-financial/

[16] Marina Mendenhall-Valente, “The Speed-to-Risk Paradox: How Efficiency Narratives Are Dismantling Institutional Safeguards,” The RWA Ledger. https://www.therwaledger.com/p/the-speed-to-risk-paradox-how-efficiency

[17] Anthropic, “Statement on the US Government Directive to Suspend Access to Fable 5 and Mythos 5,” June 12, 2026. https://www.anthropic.com/news/fable-mythos-access

[18] CNBC, “Anthropic Disables Access to Fable 5 and Mythos 5 to Comply with Government Directive,” June 12, 2026. https://www.cnbc.com/2026/06/12/anthropic-disables-access-to-fable-5-and-mythos-5-to-comply-with-government-directive.html

[19] Reuters / Yahoo Finance, “JPMorgan Chase Cuts Off Anthropic AI Access for Hong Kong Staff,” June 18, 2026. https://ca.finance.yahoo.com/news/jpmorgan-chase-cuts-off-anthropic-041524918.html

[20] FStech, “JP Morgan Blocks Hong Kong Staff from Accessing Anthropic AI Models,” June 18, 2026. https://www.fstech.co.uk/fst/JP_Morgan_Blocks_Hong_Kong_Staff_From_Accessing_Anthropic_AI_Models.php

[21] The Next Web, “JPMorgan Cuts Off Anthropic Access for Hong Kong Staff,” June 18, 2026. https://thenewstack.io/fable-ban-open-weights/

[22] Office of the Comptroller of the Currency, OCC Bulletin 2026-13, "Model Risk Management: Revised Guidance," April 17, 2026. https://www.occ.treas.gov/news-issuances/bulletins/2026/bulletin-2026-13.html

[22a]ValidMind, "SR 26-2: What Every Bank Needs to Know, and Why Acting Now Is a Competitive Advantage," April 30, 2026.https://validmind.com/blog/sr-26-2-what-every-bank-needs-to-know-and-why-acting-now-is-a-competitive-advantage/

[23] Sullivan & Cromwell LLP, “OCC, Fed, FDIC Issue Revised Guidance on Model Risk Management,” April 2026. https://www.sullcrom.com/insights/memo/2026/April/OCC-Fed-FDIC-Issue-Revised-Guidance-Model-Risk-Management

[24] Compliance Week, “When AI Acts: The Compliance Challenge of Agentic Systems,” 2026. https://www.complianceweek.com/opinion/when-ai-acts-the-compliance-challenge-of-agentic-systems/36496.article

[25] Deloitte Insights, “Agentic AI Is Scaling Faster Than Guardrails,” April 24, 2026. https://www.deloitte.com/us/en/insights/topics/emerging-technologies/ai-agents-scaling-faster.html

[26] Deloitte Insights, “Managing the New Wave of Risks from AI Agents in Banking,” March 5, 2026. https://www.deloitte.com/us/en/insights/industry/financial-services/agentic-ai-risks-banking.html

[27] Snyk, “Poisoned Security Scanner: Backdooring LiteLLM,” March 2026. https://snyk.io/blog/poisoned-security-scanner-backdooring-litellm/

[28] Sysdig, “CVE-2026-42208: Targeted SQL Injection Against LiteLLM’s Authentication Path,” April 2026. https://www.sysdig.com/blog/cve-2026-42208-targeted-sql-injection-against-litellms-authentication-path-discovered-36-hours-following-vulnerability-disclosure

[29] The Hacker News, “LiteLLM CVE-2026-42208 SQL Injection Added to CISA KEV Catalog,” April 2026. https://thehackernews.com/2026/04/litellm-cve-2026-42208-sql-injection.html

[30] The Register, “Cursor/Opus Agent Snuffs Out PocketOS,” April 27, 2026. https://www.theregister.com/2026/04/27/cursoropus_agent_snuffs_out_pocketos/

[31] Zenity, “AI Agent Database Deletion: PocketOS Incident Analysis,” April 2026. https://zenity.io/blog/current-events/ai-agent-database-deletion-pocketos

[32] OWASP, “OWASP Top 10 for Large Language Model Applications.” https://owasp.org/www-project-top-10-for-large-language-model-applications/

[33] “The Accountability Horizon: An Impossibility Theorem for Governing Human-Agent Collectives,” arXiv, 2026. https://arxiv.org/pdf/2604.07778

[34] International Monetary Fund, “How Agentic AI Will Reshape Payments,” IMF Notes, Volume 2026, Issue 004, April 24, 2026. https://www.elibrary.imf.org/view/journals/068/2026/004/article-A001-en.xml

[35] Oliver Wyman, “AI Agents in Banking: Reshaping Roles, Skills and Leadership,” January 2026. https://www.oliverwyman.com/our-expertise/insights/2026/jan/impact-ai-agents-in-banking-reshaping-roles-skills-and-leadership.html

[36] AIHub, “Top AI Ethics and Policy Issues of 2025 and What to Expect in 2026,” March 4, 2026. https://aihub.org/2026/03/04/top-ai-ethics-and-policy-issues-of-2025-and-what-to-expect-in-2026/

[37] McKinsey & Company, “State of AI Trust in 2026: Shifting to the Agentic Era,” March 25, 2026. https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/tech-forward/state-of-ai-trust-in-2026-shifting-to-the-agentic-era

[38] American Banker, “Financial Regulators Need to Build Ethics into Their AI Systems,” February 17, 2026. https://www.americanbanker.com/opinion/financial-regulators-need-to-build-ethics-into-their-ai-systems

[39] Mitratech, “Third-Party Risk Management Frameworks,” 2026. https://mitratech.com/resource-hub/blog/third-party-risk-management-frameworks/

[40] Gartner, “Survey Finds Just 15% of IT Application Leaders Are Considering, Piloting, or Deploying Fully Autonomous AI Agents,” September 30, 2025. https://www.gartner.com/en/newsroom/press-releases/2025-09-30-gartner-survey-finds-just-15-percent-of-it-application-leaders-are-considering-piloting-or-deploying-fully-autonomous-ai-agents

[41] GSDC, “ISO 42001 Lead Auditor Jobs in 2026,” April 2026. https://www.gsdcouncil.org/iso-42001-lead-auditor-jobs

[42] Acuity Analytics / ManpowerGroup, “AI Skills Gap and Talent Shortage: Rethinking Workforce Models for an AI-Centric Future,” May 2026. https://www.acuityanalytics.com/blog/ai-skills-gap-and-talent-shortage/

[43] AI Compliance Vendors, “ISO 42001 Certified Companies: Verified Public List,” May 17, 2026. https://aicompliancevendors.com/blog/iso-42001-certified-companies-list

[44] CIO.com / Horvath & Partners, “The Road to S/4HANA: How CIOs Are Managing SAP ECC’s End of Support,” 2026. https://www.cio.com/article/3982596/the-road-to-s-4hana-how-cios-are-managing-sap-eccs-end-of-support.html

[45] SAPinsider, “SAP S/4HANA Migration 2025 Benchmark Report,” 2025. https://sapinsider.org/research-reports/sap-s-4hana-migration-2025/

[46] Ekco, “TSB Migration Disaster,” 2024. https://www.ek.co/publications/tsb-migration-disaster/

[47] Panorama Consulting, “TSB Software Failure,” 2024. https://www.panorama-consulting.com/tsb-software-failure/

[48] Bank of England / FCA PRA, “TSB Bank plc Final Notice,” December 20, 2022. https://www.bankofengland.co.uk/news/2022/december/tsb-fined-for-operational-resilience-failings/

[49] Computer Weekly, “TSB Neglected to Assess Capabilities of Main IT Provider in Its Failed System Migration,” November 28, 2019. https://www.computerweekly.com/news/252474751/TSB-neglected-to-assess-capabilities-of-main-IT-provider-in-its-failed-system-migration

[50] Cooperative AI Foundation, Hammond et al., “Multi-Agent Risks from Advanced AI,” 2025. https://arxiv.org/pdf/2502.14143

[51] Cloud Security Alliance AI Safety Initiative, “Confused Deputy Attacks on Autonomous AI Agents,” March 23, 2026. https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-agent-confused-deputy-prompt-injection/

[52] SANS Institute, “Your AI Agent Is an Easily Confused Deputy,” May 15, 2026. https://www.sans.org/blog/your-ai-agent-easily-confused-deputy-why-cloud-security-needs-credential-broker

[53] Sanctions.io, “The Lazarus Group and DPRK Crypto Theft in 2026: What Compliance Teams Need to Know,” June 2026. https://www.sanctions.io/blog/the-lazarus-group-and-dprk-crypto-theft-in-2026

[54] Memeburn, “Anthropic Forced to Shut Down Claude Fable 5 and Mythos 5,” June 2026. https://memeburn.com/anthropic-forced-to-shut-down-claude-fable-5-and-mythos-5-in-2026/

[55] Techsy, “Anthropic Fable 5 Suspended,” June 2026. https://techsy.io/en/blog/anthropic-fable-5-suspended

[56] The New Stack, “Fable Ban Open Weights,” June 2026. https://thenewstack.io/fable-ban-open-weights/

[57] Credshields, “Drift Protocol Incident Post-Mortem,” April 2026. https://discover.credshields.com/drift-protocol-incident-post-mortem/

[58] Our Crypto Talk, “North Korea’s Lazarus Group and Crypto Thefts: Explained,” April 2026. https://ourcryptotalk.com/blog/lazarus-group-crypto-thefts-explained