Forty Minutes.

That is the window — between 10:39 UTC and approximately 11:19 UTC on March 24, 2026 — during which two compromised LiteLLM packages (1.82.7 and 1.82.8) were live on PyPI before the maintainers and PyPI quarantined them. The library has roughly 97 million monthly downloads. Mandiant Consulting's CTO has publicly confirmed knowledge of over 1,000 SaaS environments actively dealing with the cascading impact. Threat hunters at vx-underground estimate the campaign — attributed to TeamPCP with downstream extortion by Lapsus$ — has touched data and secrets from approximately 500,000 machines.

On April 2, Mercor — a $10 billion AI hiring startup — confirmed it was one of the affected organisations. Lapsus$ claimed exfiltration of 4 terabytes, including 939 GB of source code, internal databases, and cloud-storage buckets containing operational verification workflows. Wiz researchers and The Register both link the LiteLLM incident to the broader TeamPCP supply-chain campaign that has also touched Trivy and several other widely-deployed open-source projects.

This is not a story about one compromised library. It is a story about an architectural layer that has no governance model — and that sits, today, underneath every European enterprise's agentic payments stack.

Edition 46 (AVAEM) catalogued the exposure of named AI vendors. Edition 48 (ACAM) named the five layers of the agent commerce stack. Edition 49 (SAVED) extended governance into OAuth-installed fourth parties. None of those frameworks reach the LLM aggregation library — the proxy that sits between your application code and OpenAI, Anthropic, Bedrock, Vertex, Mistral, and the rest. LiteLLM, OpenRouter, Helicone, Portkey, and a handful of similar libraries have quietly become the most concentrated dependency in the European AI stack. And almost none of them appear in a DORA Register of Information.

“Your AI vendor list ends at the API. The library between your code and the API is the most concentrated vendor in your stack — and you do not call it a vendor.”

WHY THIS IS NOT A LIBRARY-MAINTENANCE STORY

Three facts, all confirmed in the public record between March 24 and May 5, 2026, define the operating environment that European CTOs, CIOs, and enterprise architects are now planning into.

One. The compromised window was forty minutes. The detection-to-quarantine cycle worked roughly as it should. And the library still reached more than a thousand SaaS environments. That is what concentration looks like at the bottom of the AI stack: a single package with 97 million monthly downloads, mirrored across hundreds of CI pipelines, container builds, and ephemeral inference runners that auto-pull on every restart. Forty minutes was enough.

Two. The Security Boulevard analysis of the incident named the architectural pattern in a single sentence: “the AI supply chain is actually an API supply chain.” The gateway library is the runtime substrate that translates application intent into model calls — and increasingly into agent tool calls and payment instructions. When the substrate is poisoned, every layer above it inherits the compromise: the agent's reasoning, the agent's tool selection, and the agent's final settlement instruction.

Three. The Mercor breach was not the failure of a security control. It was the failure of an architectural assumption — that a Python library with 97 million monthly downloads was a dependency, not a vendor. The incident response treated it as a CVE. The board-level lesson is that DORA, NIS2, and the AI Act treat third-party concentration risk as a structural obligation, not an incident category. A library you cannot revoke inside ninety minutes is a Tier-1 ICT third party by every supervisory definition that now matters in Europe.

This is an enterprise architecture problem, not a SecOps problem.

“The AI supply chain is actually an API supply chain. And the API supply chain runs on three or four libraries that nobody calls vendors.”

FOUR LAYERS OF AI VENDOR EXPOSURE — AND THE ONE WE NEVER NAMED

The Hawk Nest IP portfolio has, edition by edition, mapped four distinct layers of AI third-party exposure:

• Vendor layer — the named provider (Anthropic, OpenAI, Google) — governed by AVAEM (Edition 46).

• OAuth-installed fourth-party layer — the SaaS tool an employee installs with a Workspace OAuth scope (Context.ai, Glean-style installs) — governed by SAVED (Edition 49).

• Agent commerce layer — the protocol stack (x402, AP2, MiCA-aligned settlement) above which autonomous agents transact — governed by ACAM (Edition 48).

• Healthcare-sovereign layer — the jurisdictional substrate underneath clinical AI workloads — governed by SHAD (Edition 47).

LiteLLM proves there is a fifth layer that none of those frameworks reach: the AI gateway library — the proxy/aggregator that sits inside your application process and brokers every model call. It is not a vendor. It is not a SaaS tool. It is not a protocol. It is a runtime substrate, typically pulled from PyPI or npm by a transitive dependency, frequently auto-updated, and almost never inventoried.

The category is small. LiteLLM, OpenRouter, Helicone, Portkey, and a handful of vendor-specific SDK wrappers cover most production AI traffic in 2026. Concentration is high. Visibility is low. And — critically — these libraries hold every API key, OAuth token, and agent credential the calling process is authorised to use. A compromise at this layer is not a leak of one vendor's traffic. It is a leak of every model and every tool the agent could ever reach.

“If the gateway is compromised, the agent's reasoning is compromised. If the agent's reasoning is compromised, the next x402 payment is initiated on a poisoned substrate.”

THE BRIDGE INTO AGENTIC PAYMENTS — WHY THIS LANDS ON YOUR x402 STACK

Edition 48 introduced the Agent Commerce Architecture Model (ACAM) with five layers: Protocol (x402), Settlement (stablecoin / MiCA), Identity & Trust (AP2), Governance (DORA Register), and Accountability (AI Act Article 50). The framework holds. What LiteLLM exposes is a hidden sub-layer beneath ACAM Layer 1 — the LLM gateway through which the agent forms the intent that the x402 protocol then executes.

The agentic-commerce numbers from May 2026 make this concrete. Visa disclosed an annualised stablecoin settlement run-rate of $4.6 billion in Q1 2026. Mastercard backed Rain at a $1.95 billion valuation on May 4 to issue stablecoin cards into institutional treasuries. Crypto.news reports stablecoin transaction volume now exceeds the combined throughput of Visa and Mastercard. The card networks did not get disrupted by stablecoins — they moved upstream and became the orchestration layer above them. Every one of those orchestration paths increasingly runs through an autonomous agent that reasons via an LLM call before it commits the payment.

That LLM call goes through a gateway library. If the library is the same one that was poisoned for forty minutes on March 24, the payment instruction — not just the inference — was formed on a poisoned substrate. ACAM Layer 1 has a basement, and we just learned its address.

PSD3 / PSR final compromise texts were published by the Council on April 23–24 and the European Parliament's ECON Committee voted on May 5; plenary adoption is expected later this month, with publication in the Official Journal anticipated by the end of Q2 2026 and the new rules generally applying twenty-one months after publication. PSD3 expands liability for unauthorised payments and tightens fraud-prevention controls. An agent commerce stack whose reasoning substrate can be compromised in forty minutes by a single PyPI release does not meet a defensible PSD3 control posture, regardless of how clean the x402 implementation is.

“$4.6 billion in ninety days flowed through Visa's stablecoin rails. Some of that flow is already initiated by agents whose reasoning passes through a library nobody has put on a vendor list.”

THE REGULATORY COLLISION — THREE REGIMES, ONE BLIND SPOT

DORA — live enforcement; first CTPP designations published; Joint Examination Teams active. The European Supervisory Authorities published the inaugural list of 19 designated Critical ICT Third-Party Providers (CTPPs) under Article 31(9) of DORA on November 18, 2025. JETs are now in the field with powers to inspect risk management frameworks, subcontracting arrangements, and incident reporting procedures, and — in cases of serious persisting non-compliance — National Competent Authorities can require financial entities to suspend, phase out, or terminate arrangements with a non-compliant CTPP. The DORA Register of Information is live and being cross-checked. Almost no Register lists a gateway library. The Article 28 obligation is structural — the Register is meant to capture any critical ICT third-party arrangement, and a library through which 100% of your AI inference flows fits that definition by any defensible reading.

NIS2 — Belgian first-deadline data is in; the supply-chain control gap is now visible. Belgium's first NIS2 essential-entity self-assessment deadline passed on April 18, 2026, with 84% of in-scope entities reportedly not ready. 2,410 of an estimated 2,500 in-scope organisations have registered with the CCB. Article 21 supply-chain controls require essential entities to assess the security of their direct suppliers and service providers — and the supervisor's interpretation now includes the software supply chain, not only managed services. A library auto-pulled from PyPI on every container build is, in 2026, an Article 21 obligation.

AI Act — Article 50 still triggers August 2, 2026. Article 50 obligations did not move. The Digital Omnibus on AI provisional agreement reached in the early hours of May 7, 2026 pushed Annex III high-risk obligations to December 2, 2027 and Annex I machinery-products obligations to August 2, 2028, with a machinery-only carve-out — medical devices, IVDs, lifts, and radio equipment remain inside the original combined regime. Article 50 transparency obligations were not delayed. A deployer of an AI system whose reasoning substrate can be compromised by a third-party library it does not list on its risk register is going to find Article 50's audit-trail requirements very difficult to satisfy.

ENISA Threat Landscape 2025 puts supply-chain risk at 10.6% of all observed threats and ransomware as the dominant impact category — with essential entities under NIS2 representing 53.7% of recorded incidents. The architectural conclusion is unavoidable: the supply-chain gap is the regulator's gap, and the gateway library is the gap inside the gap.

“DORA, NIS2 and the AI Act each demand visibility into your critical third parties. The library underneath your AI stack is critical, third-party, and invisible.”

INTRODUCING AGCR-D — THE AI GATEWAY CONCENTRATION RISK DIAGNOSTIC

What enterprise architects need is not another package-scanner integration. They need a structural model that makes the AI gateway layer first-class architecture data — alongside the vendor layer, the OAuth fourth-party layer, the agent-commerce layer, and the sovereign-infrastructure layer that previous editions of this newsletter have addressed.

The AI Gateway Concentration Risk Diagnostic (AGCR-D) is a five-axis assessment for any enterprise running AI inference, agentic, or settlement workloads through an LLM gateway library.

Axis	Domain	Regulatory Trigger	AGCR-D Diagnostic Question
1. Aggregator Dependency Depth	AI runtime substrate	DORA Art. 28; NIS2 Art. 21	What share of your production AI calls — including the agent runtimes that initiate payments — flows through a single proxy library, and have you ever inventoried it?
2. Update Velocity Mismatch	Library lifecycle	NIS2 Art. 21; ISO 27001 A.8.32	Does the gateway library upgrade faster than your change-control process can review it — and is your production environment pinned to a SHA, a tag, or a wildcard?
3. Credential & Token Surface	Identity exposure	GDPR Art. 32; AI Act Art. 50; NIS2 Art. 21	Which API keys, OAuth tokens, MCP credentials, and agent payment authorities are reachable from inside the gateway process at request time — and what is the blast radius if it is compromised for forty minutes?
4. Lateral Egress Topology	Network blast radius	DORA Art. 11 (BCM); NIS2 Art. 21	If the gateway is compromised, what payment rails, MCP servers, internal databases, and outbound endpoints can it reach — and how would you detect, contain, and revoke inside ninety minutes?
5. Regulatory Visibility	Register inclusion	DORA Art. 28-44; NIS2 Annex I; AI Act Art. 50	Is the gateway library listed in your DORA Register of Information as a critical ICT third party, mapped in your NIS2 supplier list, and named in your AI Act Article 50 audit trail — or is it invisible to all three?

Score each axis 1 to 5: 1 means not assessed, 5 means continuously evidenced under your DORA / NIS2 / AI Act control framework, with contractual or architectural enforcement of pinning, egress controls, credential isolation, and revocation runbooks.

“A composite AGCR-D score below 12 indicates critical AI-gateway concentration risk. If Axis 5 (Regulatory Visibility) scores below 3, your DORA Register is missing the most concentrated AI dependency in your stack. Most European enterprises today score a 7.”

Axis 1 (Aggregator Dependency Depth) is the most commonly absent. Architecture teams know which models they call. They almost never know what percentage of those calls flow through a single library — or whether the agent runtimes that initiate x402 payments share the same substrate as the analytics workload that runs on a six-month-old container.

Axis 5 (Regulatory Visibility) is the most consequential. A library that does not appear in the DORA Register cannot be inspected by the JET. A supplier that does not appear in the NIS2 supply-chain assessment cannot be controlled under Article 21. A dependency that does not appear in the AI Act Article 50 audit trail cannot satisfy the deployer's transparency obligation. The supervisor's question — “who are your critical ICT third parties?” — has, for most European enterprises, an answer that is silently incomplete.

THREE ACTIONS FOR ENTERPRISE ARCHITECTS THIS QUARTER

1. Inventory the gateway layer before September. For every production AI workload — and every agent runtime that can initiate a payment — name the gateway library, the version (SHA, tag, or wildcard), the maintainer, the credential surface it holds at request time, and the egress endpoints it can reach. The data exists in your requirements.txt, package.json, and container manifests. Most enterprise architects have never assembled it. Treat the result as a Tier-1 architecture artefact, not a SecOps annex.

2. Add the gateway layer to your DORA Register and your NIS2 supplier list by August 2. If the library brokers a critical ICT function — and brokering 100% of your AI inference is, by any defensible reading, a critical ICT function — it belongs in the Register of Information under Article 28. The supervisor will not accept “it's open source” as a defence in a JET inspection. Update your AVAEM, SAVED, and ACAM maps to reference the AGCR-D Axis 5 question explicitly: which row in the Register names the gateway, and which control owner is accountable for revoking it inside ninety minutes.

3. Score yourself with AGCR-D — and act on Axis 2 and Axis 4 first. The five axes can be assessed in a single workshop with your CTO, head of platform engineering, head of risk, and EA function. Most enterprises will discover Axis 2 (Update Velocity Mismatch) is undefended — the gateway library auto-updates faster than change control reviews — and Axis 4 (Lateral Egress Topology) is unmodelled — nobody can describe, at request time, the network blast radius of a compromised gateway. Fix Axis 2 first by pinning to a SHA and routing the gateway through your normal change-control queue. Fix Axis 4 second by isolating the gateway in its own egress namespace with deny-by-default to payment rails.

The architectural pattern was not invented in March 2026. LiteLLM, OpenRouter, Helicone and Portkey have been the de facto AI gateway layer for at least eighteen months. The compromise simply made the concentration legible.

It just was not in any architecture artefact.

That is the gap AGCR-D is designed to close.

ABOUT THE AUTHOR

Paulo Falcão is a Fractional Enterprise Architect, AI Strategist, and Transformation Leader with over 25 years of experience. He operates at the intersection of payments systems, enterprise architecture, AI strategy, and European digital regulation — helping mid-market organisations build architectures that are audit-ready, resilient, and prepared for the next structural shift in technology.

The Hawk Nest Newsletter is published weekly on LinkedIn. Follow Paulo Falcão for the next edition.