Between March and April 2026, three separate incidents — at McKinsey, Anthropic, and Bain — exposed how quickly AI platforms can become vectors for data exposure, even at organisations with substantial resources and security investment. None required a sophisticated exploit; all three were remediated swiftly. For financial services boards, the lesson is structural: governance frameworks and vendor oversight must now account for attack surfaces that shift with every deployment. The regulatory framework — from FINMA Circular 2023/1 to DORA — already provides the structure. These incidents provide the urgency.

 

Three Incidents, Three Vectors

​

McKinsey — Lilli (March 2026). A cybersecurity research firm, CodeWall, deployed an autonomous AI agent against McKinsey’s internal generative AI platform Lilli. The agent found publicly exposed API documentation, identified 22 endpoints that required no authentication, and exploited a SQL injection vulnerability to gain full read-write access to the production database. Exposed assets included 46.5 million chat messages, over 700,000 files, and 95 system prompts that governed Lilli’s behaviour — all writable. McKinsey remediated the vulnerabilities within hours of disclosure. The firm stated that a forensic investigation found no evidence that client data had been accessed by unauthorised parties.

​

Anthropic — Claude Code source code leak (31 March 2026). Anthropic accidentally shipped a source map file in a routine npm package release of Claude Code, its widely used AI coding agent. The file pointed to a zip archive on Anthropic’s cloud storage containing approximately 512,000 lines of unobfuscated TypeScript across 1,900 files — effectively the complete client-side codebase. Within hours, the code was mirrored and forked tens of thousands of times. The leak revealed internal architecture, feature flags for unreleased capabilities, and the full permission and orchestration logic. No customer credentials were exposed, but the incident coincided with a separate malicious supply chain attack on the npm axios package, compounding the risk for developers who updated their environments that day.

​

Bain — Pyxis (April 2026). CodeWall’s agent, applying lessons from its earlier research, gained a foothold on Bain & Company’s Pyxis competitive intelligence platform within 18 minutes. The entry point was a hardcoded service account credential in a publicly served JavaScript file. From there, the agent discovered a SQL injection path into 11 production databases. The data exposed was qualitatively different from McKinsey’s: Pyxis is a client-facing platform processing 159 billion rows of consumer transaction data, with AI conversation logs showing external client employees querying each other’s competitive performance. The agent also identified severe escalation paths including arbitrary Okta account creation and over 36,000 stored authentication tokens with year-long expiry. Bain remediated the vulnerabilities within 24 hours.

​

What Connects These Incidents

 

Each of these events involved a different type of failure: an authentication gap exploited autonomously, a build pipeline misconfiguration shipping proprietary source to a public registry, and hardcoded credentials in production frontend code. None required a sophisticated zero-day exploit. All three were elementary errors of the kind that should be caught by standard security processes.

​

The common thread is not that these organisations were negligent. It is that the velocity and complexity of AI platform deployment have outpaced the cadence of conventional security testing and release governance. Traditional penetration tests, scoped to fixed windows and delivered periodically, are not designed for environments where attack surfaces shift with every deployment. Build pipelines optimised for speed can ship debug artefacts alongside production code. And AI platforms, by their nature, sit atop vast aggregations of sensitive data — which means that when a routine vulnerability is present, the blast radius is no longer routine.

​

FINMA’s senior cyber risk specialist made this point directly in February 2026: the need for action will persist, and the combination of protection, detection, response, and recovery must be managed as an integrated whole. He noted that problems at a few critical service providers can increasingly affect several institutions simultaneously — a systemic risk dimension that extends well beyond any individual firm.​

​

What Regulators Are Signalling

​

Swiss financial institutions now operate under a regulatory framework that directly addresses the risks these incidents illustrate — even if AI is not yet explicitly named in every provision.

​

FINMA Circular 2023/1 (Operational Risks and Resilience) came into force in January 2024 with a two-year transition period ending January 2026. Institutions must now demonstrate full compliance. The circular covers ICT risk management, cyber risk management, critical data protection, and operational resilience. It requires institutions to identify critical functions, define tolerances for disruption, and implement holistic measures encompassing both preventive and reactive capabilities. On-site inspections in the run-up to the compliance deadline already identified gaps at many institutions, including incomplete ICT inventories and insufficient separation between operational management of cyber risk and independent control functions.

​

FINMA Circular 2018/3 (Outsourcing) requires institutions to maintain inventories of outsourced functions, conduct ongoing due diligence of service providers, and ensure that FINMA and the institution’s auditors retain unrestricted inspection and audit rights. Outsourcing a function does not outsource the responsibility: the institution remains fully accountable for regulatory compliance and client data protection.

​

FINMA Guidance Note 08/2024 on AI establishes four supervisory principles: clear roles and responsibilities, sufficient AI-related expertise, robustness and reliability of outputs, and explainability proportionate to context. FINMA explicitly stated that the responsibility for decisions cannot be delegated to AI or third parties — and announced its intention to issue further guidance or circulars as needed.

​

The FINMA Risk Monitor 2025 reported that cyberattacks on financial institutions and their service providers increased significantly in 2025, with nearly half of all reported incidents involving third parties. FINMA flagged the growing dependence on a small number of service providers as a concentration risk, and called for more robust controls over outsourcing of critical functions. The regulator has responded by expanding on-site inspections to cover not only supervised entities but also their service providers directly.

​

At the European level, DORA (the Digital Operational Resilience Act) applies from January 2025 and imposes comparable requirements on financial entities operating in or serving the EU market, including mandatory ICT incident reporting, third-party risk management frameworks, and periodic threat-led penetration testing.

​

What Boards and C-Suites Should Do Differently

​

The incidents of the past six weeks are not someone else’s problem. They are a preview of what the threat landscape looks like for any institution that deploys AI platforms internally or shares sensitive data with external providers that do. Five areas warrant immediate attention.

​

Reassess third-party AI risk as a discrete governance topic. Most institutions assess vendor risk through annual questionnaires, SOC 2 reports, and contractual provisions. These instruments are necessary but insufficient for AI platforms that are continuously updated, connected to live data, and accessible via APIs. Boards should ask management whether the institution has a current, complete inventory of all external AI platforms that process its data — and whether continuous security testing is a contractual requirement for critical providers.

​

Close the gap between deployment velocity and security cadence. The McKinsey and Bain incidents were discovered by an autonomous agent running continuously against the attack surface. The Anthropic leak resulted from a build pipeline that shipped a debug artefact to a public registry. In both cases, periodic testing would not have caught the issue in time. Institutions should evaluate whether their own deployment and release processes include automated checks for exposed credentials, debug files, and unauthenticated endpoints — running on every release, not on a quarterly schedule.

​

Treat AI platform configuration as critical data. In both the McKinsey and Bain incidents, the AI system prompts — the instructions governing how the platform behaves — were stored in the same database as production data. An attacker with write access could have silently altered the AI’s behaviour without any code deployment. Institutions deploying AI internally should ensure that model configuration, system prompts, and behavioural instructions are stored and protected separately from the data the AI processes, with access controls and change detection commensurate with their criticality.

​

Ensure the board receives AI-specific risk reporting. FINMA’s AI guidance expects supervised institutions to maintain inventories of AI systems, define clear responsibilities, and implement risk management processes that account for AI-specific risks including opacity, concentration, and third-party dependence. The board and audit committee should receive periodic reporting that covers the institution’s own AI deployments, the AI capabilities embedded in third-party platforms, and the security posture of both — not as a subset of general IT risk reporting, but as a distinct governance topic.

​

Align with the regulatory trajectory, not just the current baseline. FINMA has signalled that further AI-specific guidance is forthcoming. DORA’s third-party risk management requirements are tightening. And the EU AI Act is progressively coming into effect, with high-risk classifications directly relevant to financial services applications. Institutions that treat the current regulatory framework as a ceiling rather than a floor will find themselves adjusting reactively. Those that anticipate the direction of travel — continuous testing, AI inventories, explainability requirements, concentration risk management — will be better positioned.

​

A Structural, Not a Cyclical, Shift

 

The three incidents of early 2026 were different in nature but consistent in implication. AI platforms aggregate sensitive data, grant privileged access through new interfaces, and create attack surfaces that move faster than conventional defences are designed to follow. The organisations affected responded quickly and professionally — but the vulnerabilities existed in production environments that had passed conventional security reviews.

​

For financial services boards, the task is to ensure that governance frameworks, vendor oversight, and security testing regimes reflect this reality. Not because the institutions affected were careless — but because the lessons from their experience apply directly to every regulated institution that holds sensitive data, deploys AI, or relies on external platforms that do.

​

The regulatory framework, from FINMA to DORA, already provides the structure. The incidents of the past six weeks provide the urgency.

​​

​

Silvan Schriber is Managing Director at Alvarez & Marsal and a Board Member and Audit & Risk Committee Chair at Zuger Kantonalbank. This is the third article in a series on AI security incidents and their implications for financial services governance.​​