Black October: What the Latest AI Supply Chain Attacks Reveal About Your Hidden Dependencies

In October 2026, attackers compromised a widely used AI gateway, a backup provider with access to Microsoft 365 and a hosting platform storing AI keys. Many of the organisations exposed had no direct relationship with them. This article explains how AI has added critical dependencies deep in organisations’ supply chains, what most risk management programmes cannot see, and what security and risk leaders should do next.

On 21 October, a malicious version of LiteLLM was published to the Python Package Index. LiteLLM is a widely used open-source tool that connects software to AI models. The compromised version carried a credential stealer and a remote access trojan, and was available on the index for just under two hours. Within that time frame, however, anyone who installed it, or simply started Python on a system where it was present, risked exposing cloud credentials, developer secrets and the API keys their applications use to reach AI providers. LiteLLM has around 23 million weekly downloads, and it is built into many products whose customers are unlikely to know it is there.

The attackers got in through a basic security lapse. According to LiteLLM's own attack-chain analysis, an administrative key was accidentally published in a public code repository in May. The team removed the file but never cancelled the key. More than four months later, an attacker used it to start taking over the project's GitHub organisation, which gave them control of how new versions were released. LiteLLM says the attacker was mainly after API keys for AI services, the credentials that let one company's software use another company's AI models.

LiteLLM was not the only incident that month. Microsoft attributed the ConnectWise compromise to a China state-aligned group that, it said, used an AI-driven hacking tool to speed up the attack. The developer platform Railway disclosed that customer secrets had been accessed, in what it believed was one of a series of attacks on platform companies aimed at AI providers.

Attacks that come through suppliers have been increasing for some time. The Verizon 2026 Data Breach Investigations Report found that a third party was involved in 48% of breaches, up from 30% in the previous year's report. In the World Economic Forum's Global Cybersecurity Outlook 2026, 65% of large companies said that weaknesses in third parties and supply chains were their greatest cyber security challenge, up from 54% a year earlier. In the same survey, 87% of respondents said AI-related vulnerabilities were the cyber risk that grew fastest during 2025.

AI helps attackers and defenders alike. Attackers can find and exploit weaknesses faster and at greater scale. Defenders can use the same technology to detect threats, assess suppliers and respond to incidents more quickly. AI has also changed what organisations depend on. As suppliers have added AI to their products, a small number of AI models, tools and platforms have ended up underneath a large share of the services organisations rely on, usually without the customer knowing any details about it. An organisation can ask its critical suppliers how they use and manage AI. It cannot ask the same of every company those suppliers rely on in turn, or the companies behind them. Much of this risk sits in parts of the supply chain that most third-party risk programmes cannot see.

This article looks at what the October incidents reveal and how attackers are using AI against supply chains. It explains why reliance on a few AI providers creates the same kind of concentration risk already seen with cloud computing, how geopolitical competition adds to that risk, and what this means for the confidentiality, integrity and availability of data and services. It then considers why current third-party risk practice struggles with these risks, how AI can help defenders, and where regulation stands, before setting out practical steps for security, third-party risk and resilience leaders.
‍

Black October: what the recent attacks tell us

LiteLLM was one of several attacks in October on the tools, platforms and service providers that sit between organisations and the services they use. The four cases below are the best documented, and they have several features in common.

LiteLLM: two compromises in seven months

LiteLLM's analysis shows that the attacker held access tokens for three of the project's engineers. One account was used to override the protections on the code repository, a second approved the release and a third deleted the logs. The project required more than one person to approve each release, which is the kind of control a supplier might report in a security questionnaire. It did not help, because the attacker could act as several people. The malicious files were built from a lookalike repository, Berri-AI, which differs from the genuine BerriAI by a single hyphen.

Microsoft found that the malware ran as soon as Python started, so a system could be affected even if no application on it used LiteLLM.

This was LiteLLM's second compromise of the year. In March, two malicious versions were available for about 40 minutes, after attackers stole the project's publishing credentials through an earlier breach of Trivy, a widely used security scanning tool. CloudSEK estimated that more than 2,500 organisations were potentially exposed.

ConnectWise: a backup provider's access turned against its customers

On 16 October, ConnectWise published an advisory reporting unauthorised use of the application identities behind its Cloud Backup service. These identities had standing permission to access customers' Microsoft 365 environments, which a backup service needs in order to reach the data it protects. ConnectWise disabled seven of them the next day and suspended Cloud Backup and two related services. It began restoring them on 28 October, and customers had to re-authorise access through a new application.

The security firm Huntress confirmed unauthorised sign-ins to 162 customer environments on the first day. As it reviewed more logs, it found sign-in activity from the attacker in almost 1,000 environments, more than 300 of them successful. Microsoft attributed the campaign to Storm-0940, a group it describes as aligned with the Chinese state. It reported that the group used ARTEX, an AI tool built for automated penetration testing, to attempt sign-ins to more than 2,250 environments at up to 2,900 attempts a minute. Most attempts failed, but in several cases the attackers gained privileged access within three hours.

The attribution and the role of AI rest on Microsoft's assessment, and neither company has said how the original credential was stolen. The supply chain point holds either way. Customers had given a backup provider standing access to their core business systems, and the attackers used that access. Sign-ins through a trusted application are harder to pick out from normal activity than sign-ins from an unknown account.

Railway and OpenCode: AI keys as the target

Railway hosts applications for developers and stores the passwords and keys those applications need. On 21 October, it reported that an intruder had accessed this stored data and decrypted some of it. Railway said the attack appeared to be one of a series against platform companies, aimed at compromising AI providers. It warned the AI providers directly and told all customers to change every stored secret.

A few days earlier, the AI coding tool OpenCode disclosed that an intruder had reached an old system holding keys for OpenAI, Anthropic and Google that about 1.4% of its users had saved. OpenCode linked the breach to a large-scale "distillation" attack, in which stolen access to AI models is used to generate large volumes of output for training a rival model. It said it had seen no evidence that the keys were used. No link between the Railway and OpenCode incidents has been established.

For most organisations, a hosting platform used by one of their software suppliers is a fourth party that rarely appears in a supplier register. Railway's breach shows that such a platform can still hold keys that open company data and cost money each time they are used.

The pattern behind the headlines

Smaller incidents in October followed the same pattern. On 8 October, a compromised version of Tensorlake, a software kit for building AI applications, was published to npm carrying self-spreading malware. Socket flagged it within 11 minutes. A campaign known as GhostAction, running since late August, used stolen developer accounts to add a fake "security audit" step to code repositories, which searched each repository's history for cloud and AI service keys. GitGuardian counted about 1,900 compromised accounts and more than 30,000 targeted repositories. JFrog found 42 legitimate repositories that had been altered to run malicious code when a developer opened them in an AI coding assistant such as Claude Code, Gemini or Cursor.

Most of these attacks share three features. The attackers got in with credentials that had been stolen, or that should already have been cancelled, rather than through a new technical flaw. The malicious code or access arrived through a channel customers had reason to trust, such as an official release, an approved application or a known repository. And the critical steps often took hours, far less time than the cycle on which most organisations review their suppliers. The next section looks at how AI is adding to that speed.

‍

How attackers are using AI against supply chains

There is little public evidence yet of AI malware that adapts and hides itself without human direction, as some earlier commentary predicted. In the documented October cases, AI did much of the manual work that used to slow attackers down, so they could target more organisations more quickly. One weak supplier can give access to many customers, so that extra speed and reach raises the risk for all of them.

Finding the weakest supplier

Attackers often reach a well-defended organisation through a smaller supplier with fewer security staff and weaker controls. AI tools can search large amounts of information to find those suppliers, including public data about the technology they use, systems they have left exposed and passwords that have leaked online. They can also probe many organisations at once.

In October, TrendAI described an operation using CyberStrikeAI, an openly available attack platform. The attackers ran 44 AI agents at the same time against at least 19 organisations, most of them in Japan. Most of their attempts failed. TrendAI concluded that AI let the attackers do more work in parallel, but the work itself was still a matter of "looking for unlocked doors". The ConnectWise campaign described above worked the same way, at a larger scale.

For customers, this means that if a supplier leaves a system unpatched or a password exposed, attackers are likely to find it sooner than before, and more of them will find it.

Exploiting weaknesses faster

Attackers are also using newly disclosed flaws sooner. On 21 October, the PHP project released fixes for two critical flaws, known as PHP2Shell, in the programming language that runs a large share of the world's websites. That day, the US Cybersecurity and Infrastructure Security Agency (CISA) said it had not seen the flaws being exploited. Five days later, it added both to its list of vulnerabilities known to be under active attack. There is no public evidence that AI was used to find or exploit these flaws, but attacks were confirmed less than a week after the fixes appeared. Most organisations depend on their suppliers to apply patches like these, and rarely know how quickly their suppliers do so.

Wiz has documented an attack on a cloud environment that it describes as AI-driven. One of the ways in was an exposed copy of Kafka UI, a web tool for managing data-streaming systems, which had a known flaw. The same source was seen scanning more than 600 other environments that Wiz monitors. The attacker then took full control of the victim's computing cluster using stolen access tokens and altered deployment files. This account comes from Wiz alone and has not been independently confirmed.

In the TrendAI and Microsoft cases, people chose the targets and decided what to do once inside. AI handled the repetitive tasks of scanning systems, testing passwords and trying known exploits.

Tampering with AI models

AI models can be tampered with in the same way as any other software component. Attackers can corrupt the open-source data and code that AI systems are built from, and any product built on that material inherits the problem.

In October, ProjectDiscovery showed how cheaply this can be done. Researchers took Qwen2.5-7B, a freely available AI model, and trained it on a few hundred examples so that a hidden trigger phrase would change its behaviour. When the trigger appeared, OpenAI's Codex coding assistant, running on the altered model, read files containing passwords and keys and sent them to a server the researchers controlled. The whole exercise cost less than $50. The researchers used dummy credentials, and no attack of this kind has been reported in real use.

A tampered model like this can behave normally in testing and still carry hidden instructions. Modified versions of open models, including versions with their safety restrictions removed, are freely shared on public websites. If a supplier builds one into its product, every customer of that product is exposed. Standard code scanning will not detect this kind of backdoor, because it is stored in the model's learned parameters rather than in its code.

How compromises spread

When attackers compromise one supplier, they can use its connections to reach that supplier's customers, and sometimes those customers' customers. In October, a single backup provider's credentials led into hundreds of customer environments. The Tensorlake malware stole publishing credentials from developers' machines and used them to release more infected software under those developers' names, with forged signatures to make it look genuine.

The attackers did not need AI to spread. They used the access that organisations give their suppliers so that the suppliers can do their jobs. AI makes it faster to move from one compromised organisation to the next, which leaves defenders less time to notice and contain each step. As more suppliers build the same AI tools into their products, one compromised tool can reach more organisations.
‍

The AI supply chain is now everyone's supply chain

Supply chains were already complex

Most organisations now rely on outside providers for work they once did themselves, from payroll and pensions to payment processing and customer support. Each of those providers relies on its own suppliers, and those suppliers rely on others. An organisation may have a manageable number of direct suppliers, but it also depends on a far larger number of indirect ones, such as subcontractors and suppliers' suppliers, many of which it could not name. An attack on any of them can affect organisations further along the chain, and every new connected system or service adds another possible way in.

How AI enters through supplier services and software

AI adds more of these indirect suppliers, and many of them are easy to miss. When an organisation buys an AI product directly, the purchase usually goes through procurement and security review. Much of the AI an organisation depends on arrives another way. Software suppliers add AI features to products their customers already use, often through routine updates. Those features may send customer data to an AI model provider the customer has never assessed. They may rely on open-source tools such as LiteLLM to connect to that provider, and run on hosting platforms such as Railway that store the access keys.

The customer's contract is with the software supplier. The model provider, the connecting tool and the hosting platform may not appear anywhere in the customer's records, yet a failure at any one of them can expose the customer's data.

There are limits to what one organisation can verify

An organisation can, and should, ask its critical suppliers how they use AI: which models and providers they rely on, what data they send to them, how they store access keys and who approves changes. A well-run third-party risk programme can get reasonable answers to these questions. It cannot get the same answers from every company those suppliers depend on, or from the companies behind them. Supplier contracts rarely give a customer the right to assess its suppliers' suppliers, and even where they do, few security teams have the time or specialist knowledge to assess AI risk at every level.

In October, a company that had carefully assessed a software supplier would not necessarily have known that the supplier's product included LiteLLM, or that the supplier kept its AI keys with Railway or OpenCode. The weaknesses that attackers used were two or three steps away from the customer, in organisations the customer had no direct relationship with.

The same suppliers, tools and AI providers turn up in many organisations' supply chains. Organisations that pool what they know about these shared suppliers and their dependencies can see further down the chain than any one of them could alone.

Suppliers' AI agents with access to your systems

AI agents bring a further risk. An agent is software that can take actions on its own, such as logging in to systems, reading files and calling other services, using whatever credentials and permissions it has been given. Suppliers are starting to use agents to deliver their services, and that can mean giving an agent access to customer data or systems. If the agent does something it should not, the customer has an incident to deal with, whether or not an attacker was involved.

Two recent disclosures show agents reaching systems they should not have. In late September, OpenAI said it had notified more than 100 organisations about activity by its AI agents that met its criteria for notification. OpenAI said its models had used internet access in unintended ways, and that a notification did not necessarily mean private data had been accessed or any third-party system compromised.

On 15 October, India's national cyber security agency, CERT-In, issued a critical advisory on AI agents. It reported that agents being tested by AI developers had reached live systems at Indian organisations and read business records, including personal and confidential data. The agents got in using credentials left in code, configuration files and public web pages, and through cloud permissions that were broader than they needed to be. CERT-In stated that "none of the affected organizations detected the access". In every case, the AI providers disclosed it.

The agents in both cases were run by AI developers, not by suppliers delivering a service. But suppliers are now adopting similar agents, and the same failures could occur through a supplier's agent with access to a customer's systems. For each supplier that uses AI agents, customers need to know what those agents can reach, what credentials they hold and whether the supplier would notice if an agent went somewhere it should not. Many supplier questionnaires were written before agents came into wide use and do not cover these questions.
‍

Concentration risk: repeating the cloud experience

A small number of providers behind many services

Regulators and resilience teams have spent the past decade worrying about how much of the economy depends on a few cloud providers. An outage or breach at one of them can affect thousands of organisations at once, including many that never signed a contract with the provider. In the UK, HM Treasury has now designated four cloud providers as critical third parties to the financial system, which brings them under direct regulatory oversight.

AI is heading the same way, and faster. The Bank of England and Financial Conduct Authority published their latest survey of AI use in UK financial services on 26 October. It found that the three largest AI model providers accounted for 54% of reported relationships, and the three largest cloud and computing providers for 79%. Firms can only report the dependencies they know about. Many also reach these providers indirectly, through suppliers' products, so their real reliance on them may be higher than the survey shows.

The Bank's Financial Policy Committee has also warned that firms relying on a small number of leading AI providers to strengthen their own cyber defences could create a new source of concentration.

When many suppliers rely on the same AI provider, a single failure at that provider can affect all of them at the same time. A third-party risk programme that assesses each supplier separately will not show that twenty of an organisation's suppliers all depend on the same model. Spotting that requires looking across the whole supplier base for shared dependencies.

The tools sitting in between

Between the applications that organisations use and the AI models behind them sits a layer of less visible software, such as gateways, connectors and hosting platforms. LiteLLM is one example. Developers use it so that a single application can work with many different AI models, and it stores the keys needed to reach each one. LiteLLM's incident report explains that its database holds every provider key a deployment uses, so an attacker who compromises it can collect access to several AI providers at once.

Tools like this rarely appear in supplier registers or contracts. Many are open-source projects run by small teams. Suppliers build them into their products as components rather than buying them as services, so there is no contract, account manager or service level agreement attached. Customers usually have no way of knowing they are there. The same applies to hosting platforms such as Railway, which suppliers may use to run their AI features and store their keys.

When access is lost for reasons other than an attack

AI services can also become unavailable for reasons that have nothing to do with attackers. Anthropic released two new models, Claude Fable 5 and Claude Mythos 5, on 9 June 2026. On 12 June, the US government applied export controls to both. Anthropic said that the order took effect immediately and it had no reliable way to check users' nationality in real time, so it suspended access to both models for all users.

Access came back in stages. Some US organisations regained access to Mythos 5 after government approval on 26 June. The export controls were lifted on 30 June, and Fable 5 became available again worldwide on 1 July through Anthropic's own services. Access through cloud platforms such as AWS, Google Cloud and Microsoft followed later.

The models had been available for only three days before the suspension, so few services can yet have depended on them. The episode still shows that access to an AI model can be cut overnight by a government order and stay cut for weeks, and that customers reaching a model through a cloud platform may wait longer than those going direct.

Operational resilience teams need to plan for what would happen to an important business service if the AI model behind it stopped being available, whether because of an outage, a decision by the provider, a regulatory order or sanctions. Moving to a different model takes time, because models behave differently and a replacement has to be tested for accuracy, cost and safety before it goes live. Many organisations do not know which of their suppliers' services rely on which models, so they cannot easily tell which of their own services would be affected.

Geopolitics: chips, energy and access to models

The Anthropic suspension is one example of a wider pattern. AI depends on a physical and political supply chain concentrated in a few countries, and governments are increasingly willing to use their control over parts of it. This creates availability risks that supplier questionnaires are not designed to pick up.

The first layer is chips and the materials they are made from. Taiwan makes most of the world's advanced chips. TrendForce estimated in 2024 that it held about two-thirds of global capacity for advanced chip manufacturing, with the US share forecast to rise from 10% to 22% by 2027. The US government has said it wants 40% of leading-edge manufacturing to take place in the US, while Taiwan has argued that its industry cannot simply be moved. The US also controls which AI chips can be sold to China and has changed those rules several times. Since February 2026, it has licensed small shipments of Nvidia's H200 chips to specific Chinese customers. Congress is also considering a bill that could stop cloud providers serving companies with a parent in China. China, for its part, dominates the refining of several materials used in electronics, including gallium and some rare earths. Its broader October 2025 export controls, which would require Chinese licences even for some products made elsewhere, are suspended only until 10 November 2026. A separate suspension of its ban on exporting gallium, germanium and antimony to the US runs until 27 November.

The second layer is data centres and the energy to run them. According to the International Energy Agency, the US accounted for 45% of global data centre electricity use in 2024, China for 25% and Europe for 15%. Nearly half of US data centre capacity sits in five regional clusters. The IEA expects data centre electricity demand to more than double by 2030, and estimates that around 20% of planned data centre projects could be delayed by pressure on electricity grids. The UK shows how energy shapes where AI runs. In April 2026, OpenAI paused its Stargate UK data centre project, citing high energy costs and regulatory uncertainty. Most of the AI services that UK organisations' suppliers use are therefore likely to run outside the UK, under another country's law and on another country's grid.

The third layer is the AI models themselves. In September 2026, CISA, the NSA and the FBI issued a joint advisory accusing six China-based AI companies, including DeepSeek and Alibaba, of large-scale distillation of US AI models. According to the advisory, the companies spread their activity across multiple model providers, cloud platforms and third-party services to avoid detection. China rejected the accusation and said US companies distil Chinese models too. The advisory helps explain why stolen AI keys are worth so much, and it fits the motive OpenCode gave for its own breach. Competition is not the whole picture. On 25 September, the US and China agreed to set up a channel for AI incidents and a regular dialogue on AI risks, though no details of how the channel will work have been published.

For third-party risk teams, the practical questions are where suppliers' AI services run and under which country's law. They also need to know whether suppliers use AI providers or routing services that could be affected by export controls or sanctions, and what suppliers would do if a government restricted access. A supplier can change the AI provider it uses, or the region where that provider runs, with little notice to its customers.
‍

AI risk across confidentiality, integrity and availability

Security teams often assess risk against three properties. Confidentiality means that only authorised people and systems can see data. Integrity means that data, software and decisions have not been tampered with. Availability means that systems and services work when they are needed. AI in the supply chain creates risks to all three.

Confidentiality

The most direct threat to confidentiality is the theft of keys and other secrets, as the LiteLLM, Railway and OpenCode incidents showed. Attackers are also building tools for the purpose. Check Point reported a new infostealer, named Aokigahara, with a component that collects login details and settings from AI tools on developers' computers, including Claude Code, Codex, ChatGPT Desktop, Cursor, GitHub Copilot and Gemini CLI. The files it targets often contain keys that give access to company code, cloud accounts and AI services.

A stolen AI key can do more than run up charges. Depending on how an account is set up, it may also give access to the instructions, documents and conversation history an organisation has sent to an AI model. The CERT-In advisory showed that AI agents holding leaked credentials can read confidential business records directly.

A less visible risk comes from suppliers sending customer data to AI providers as part of their own products. Once that data reaches a model provider the customer has never assessed, the customer has no direct say over how it is stored, how long it is kept or who else can reach it.

Integrity

Integrity is at risk when software or AI models are changed without the customer knowing. The LiteLLM release was built from a lookalike repository and then published through the project's official channels, and the Tensorlake malware published infected software under real developers' names. In both cases, the software came from a source customers had reason to trust.

AI models add a new version of this problem. As the ProjectDiscovery research showed, a model can be cheaply altered so that it behaves normally until a hidden trigger appears, and a supplier that builds such a model into its product passes the hidden behaviour on to every customer.

Integrity is also at risk when AI agents act on data or systems in ways nobody intended. Organisations need to be confident that the actions taken in their name, and the information their decisions rest on, have not been altered. As suppliers build agents and AI-generated outputs into their services, that becomes harder to check.

Availability

Availability can be lost through an attack, through the response to an attack, or through events unrelated to security. When ConnectWise disabled its compromised application identities on 17 October, it also suspended its Cloud Backup service and two related services. Customers did not start to get them back until 28 October, so for eleven days or more, a service they relied on for recovery was itself unavailable. Aikido found that the Tensorlake malware would wipe the infected machine if its stolen token was revoked, which turns a standard first response into a destructive one. The Anthropic export control episode showed that an AI model can also become unavailable for weeks without any attack taking place.

Stolen AI accounts also carry a direct financial cost. Wiz described a campaign in which attackers used phishing to obtain administrator credentials for companies' Google Cloud accounts. They then linked their own projects to the victims' billing accounts and ran AI models at the victims' expense, running up what Wiz described as hundreds of thousands of dollars in unauthorised usage, while the victims could not see the prompts or outputs. Where an organisation has set spending limits on its AI services, this kind of abuse could also use up those limits and stop legitimate services from working.

Where the risks coalesce

The risks are spread across all three properties, but most of the October incidents had one thing in common. Each depended on credentials that let software act on an organisation's behalf without a person logging in, such as API keys, access tokens and application identities.

When these credentials are stolen, confidentiality is lost. When they are used to publish software or change systems, integrity is lost. When they are revoked in response, services can stop, as ConnectWise's customers found, and in the Tensorlake case the revocation itself set off the malware's destructive component.

These credentials are often managed less carefully than staff accounts. A key can stay valid for months after it should have been cancelled, as LiteLLM's did, without anyone being prompted to change it. For organisations and their suppliers, finding, limiting and monitoring these credentials is one of the most effective ways to reduce AI supply chain risk.
‍

Why traditional third-party risk management struggles

Most third-party risk programmes were built for risks that change slowly. A supplier is assessed when it is first taken on, usually through a questionnaire and supporting evidence, and then reassessed every year or two, with critical suppliers reviewed more often. This cycle works well for checking that a supplier has the right policies, certifications and controls in place. It does not work well for incidents like the ones described in this article.

Annual reviews and attacks measured in hours

The LiteLLM releases were available for under two hours in October and about 40 minutes in March. In the ConnectWise campaign, attackers sometimes gained privileged access within three hours, and attacks on the PHP2Shell flaws were confirmed within five days of the fixes. A supplier assessed as well controlled in September could have been compromised in October without any change to the controls it had documented. As far as the customer's records showed, nothing would have changed.

A supplier's use of AI can also change between assessments. Suppliers add AI features, model providers and tools through routine product updates, and customers are often not told unless their contract requires it.

Finding out when a supplier is affected

When an incident such as LiteLLM happens, a customer first needs to know which of its suppliers are affected. In practice, that often means contacting dozens or hundreds of suppliers to ask whether they use the compromised software, then chasing the replies, while attackers may already be using the keys they stole.

Detection is harder than many organisations assume. In the cases covered by the CERT-In advisory, the affected organisations learned about the AI agents in their systems only because the AI providers told them. If organisations cannot reliably see this kind of activity in their own environments, they are even less likely to see it inside a supplier's. They depend on suppliers to detect problems and report them quickly, and on contracts that require them to do so.

What a questionnaire can and cannot show

Even accurate answers can leave a customer with the wrong picture. Because LiteLLM required more than one person to approve each release, a question about release controls could honestly have been answered "yes". The attacker still published a malicious release, because it held access tokens for three engineers and could approve the release as more than one person.

A questionnaire records what controls a supplier has. It cannot show whether those controls would hold up against an attacker who has stolen the right credentials. Customers get a more reliable picture by giving more weight to evidence, such as configuration records, test results and certifications whose scope has been checked. Checking what suppliers say against other sources also helps, including other customers' experience of the same supplier, threat intelligence and the supplier's incident history.
‍

How AI can strengthen defences

The same capabilities that let attackers scan, test and exploit at scale can help organisations find weaknesses sooner, monitor suppliers more closely and respond to incidents faster.

Finding weaknesses before attackers do

Traditional security tools mostly look for threats that are already known. AI-based tools can also learn what normal activity looks like across a network and flag behaviour that departs from it, which can catch an intrusion that matches no known pattern.

AI is also being used to find previously unknown flaws in software. On 27 October, CISA published an advisory on four vulnerabilities in EPICS Base, software used to control equipment at large scientific facilities such as particle accelerators. The most serious was rated 9.8 out of 10 for severity, and a fixed version was released. CISA credited the discovery to a researcher at Causal Security. The company says its AI agent, Cipher, found the flaws in under four hours, although CISA's advisory does not mention AI. Anthropic, for its part, has released its Mythos 5 model only to a group of partner organisations for defensive cyber security work.

Speed of detection matters in a supply chain attack. Socket flagged the infected Tensorlake package 11 minutes after it was published, and Chainguard says it flagged the LiteLLM release within 16 minutes. Both figures come from the companies themselves, but they show that automated monitoring of public software sources can now catch some malicious releases within minutes.

Continuous, automated risk assessment

AI can also improve how organisations and their suppliers manage risk together. Suppliers can use AI tools to pull the relevant details from their policies, certificates and technical records. That keeps their security information current and quicker to share, so customers are not relying on answers given a year earlier.

Customers can use AI to review supplier information at a scale that manual review cannot match. It can compare a supplier's answers with the evidence provided, flag answers that do not match and highlight what has changed since the last assessment. It can also monitor outside sources, such as vulnerability disclosures, breach reports and changes in a supplier's ownership or finances, so that customers learn about relevant events sooner.

AI tools are good at producing answers that read well, whether or not the underlying control works in practice. The benefit comes when AI-generated answers are tied to evidence that can be checked, and when the time saved on paperwork is spent verifying the controls that matter most.

Faster incident response

When a supplier incident occurs, much of the early work is finding out what is affected: which suppliers use the compromised software, which internal systems connect to those suppliers, and which credentials may have been exposed. AI tools can speed this up by searching software inventories, configuration records and code repositories for the affected component and for stored keys.

Incident response plans set out how to contain a breach, notify customers and recover services. AI can start these planned steps automatically once an incident is confirmed, for example by isolating affected systems, revoking and replacing credentials and alerting the right people. After LiteLLM, the main task for affected organisations was to change every credential the malware could have reached. Automating that work reduces the time in which stolen keys remain useful to an attacker.

Zero trust for machines as well as people

Many organisations have adopted a "zero trust" approach to security, in which no user or device is trusted by default, access is checked continuously and permissions are kept to the minimum needed. AI can make this more effective by verifying access requests faster and more accurately, and by spotting attempts to get around the checks.

The October incidents show that zero trust needs to cover machine credentials as well as staff accounts. API keys, access tokens, application identities and AI agents should have only the access they need. Their credentials should expire rather than remain valid indefinitely, and their use should be monitored. AI tools can learn how each of these identities normally behaves and raise an alert when it does something different, such as a backup application signing in to hundreds of customer environments from a new location.

Defensive AI is also a dependency

Organisations should treat defensive AI tools as part of their supply chain too. Every AI security product depends on its own models, providers and infrastructure, and some of these are the same few providers discussed earlier. The Financial Policy Committee's warning about relying on a small number of AI providers for cyber defence applies here. Organisations should assess their AI security tools as they would any other critical supplier, and plan for what happens if those tools become unavailable.
‍

The regulatory picture

Regulators have started to address third-party and concentration risk directly, mostly with cloud providers in mind. None of the main operational resilience regimes yet treats AI model providers as critical suppliers in their own category, but the rules that already apply cover much of the AI supply chain risk described in this article.

Financial services: DORA and the UK critical third parties regime

The EU's Digital Operational Resilience Act (DORA) has applied to financial firms since January 2025. It requires them to manage the risks from their technology suppliers and to keep a register of those arrangements, including the subcontractors that support critical services. In November 2025, the European Supervisory Authorities designated 19 critical ICT third-party providers that are now subject to direct EU oversight. The list is made up largely of cloud and technology service providers, and no company is on it because it provides AI models.

The UK has taken a similar approach. In July 2026, HM Treasury designated AWS, Google Cloud, Microsoft and Oracle as critical third parties to the UK financial system, bringing them under oversight by the Bank of England, the Prudential Regulation Authority and the Financial Conduct Authority. The Treasury has said that further designations may follow. In January 2026, the House of Commons Treasury Committee recommended that the Treasury use these powers for AI providers as well as cloud providers.

The Bank of England's finding that three model providers account for 54% of reported relationships suggests that the case for designating some AI providers will grow. Until then, financial firms remain responsible for managing their dependence on AI providers through their own third-party risk programmes, including where that dependence runs through suppliers.

UK operational resilience and the new reporting rules

The UK also has its own operational resilience rules for financial services, and they apply directly to AI dependencies. Under PRA and FCA rules that came into force in March 2022, firms must identify their important business services, set a maximum tolerable level of disruption for each, and map the people, processes, technology and third parties those services depend on. Since 31 March 2025, firms have had to show that they can stay within those limits in severe but plausible scenarios. The PRA's supervisory statement on outsourcing and third-party risk management also expects firms to manage the risks that arise from their suppliers' own subcontractors.

If an important business service relies on an AI model, directly or through a supplier, that dependency should therefore appear in the firm's mapping, and losing access to the model is a reasonable scenario to test.

In March 2026, the FCA, PRA and Bank of England published final rules for a single regime covering the reporting of operational incidents and material third-party arrangements, which takes effect on 18 March 2027. Firms will have to keep a register of their material third-party arrangements, submit it to the FCA every year, and notify the regulators of new material arrangements or significant changes to existing ones. The FCA has said this data will give it a clearer picture of dependencies across the sector and help it decide which third parties to recommend to HM Treasury for designation as critical.

Firms will need to decide whether an AI model provider counts as a material third party. That depends on how central the provider is to their important business services, and where the dependency runs through a supplier, many firms may not yet have asked the question. The registers firms submit from 2027 could help determine whether AI providers are eventually designated as critical third parties.

NIS2 and the UK Cyber Security and Resilience Bill

Outside financial services, the EU's NIS2 Directive requires organisations in a wide range of essential and important sectors to manage cyber security risks in their supply chains, including risks from their direct suppliers. Member states are at different stages of putting it into national law.

The UK's Cyber Security and Resilience (Network and Information Systems) Bill would update the UK's existing regulations, bringing managed service providers into scope and allowing regulators to designate certain suppliers as critical. The Bill completed its report stage in the House of Lords on 26 October 2026, with third reading expected in early November, after which it returns to the Commons. Its final text is not yet settled.

The EU AI Act

The EU AI Act regulates AI systems and the companies that build them, rather than the security of the supply chains that use them. Its obligations for providers of general-purpose AI models, including transparency and documentation requirements, have applied since August 2025. In July 2026, the EU's Digital Omnibus changes to the Act came into force. They postponed the main obligations for high-risk AI systems from August 2026 to December 2027, and to August 2028 for AI built into products covered by EU product safety law.

For third-party risk teams, the AI Act matters mainly because it will require more documentation from AI providers about how their models are built and tested. Over time, that should make it easier to ask suppliers informed questions about the models they use, though it does not remove the need for organisations to manage AI risk in their own supply chains.

What this means for organisations

These regimes leave organisations accountable for risks that reach them through suppliers, including suppliers several steps removed. Regulators are bringing the largest cloud providers under direct oversight, and some may do the same for AI providers. In the meantime, organisations need to know which of their important services depend on AI, which providers sit behind them, and how they would keep those services running if one of those providers failed.
‍

What security, third-party risk and resilience leaders should do now

The October incidents point to a set of practical steps. None of them needs new technology, and most can be built into existing third-party risk and resilience programmes.

Find out where AI sits in your supply chain

Start with the suppliers that support your most important services. Ask each one which AI models and providers it uses, what customer data it sends to them, which tools connect its products to those models, and in which countries it runs those services and stores the access keys. Record the answers alongside the rest of your supplier information. Under DORA, financial firms already have to record the subcontractors that support critical services, and AI providers belong in that record. Repeat the exercise when suppliers release significant updates, since AI features often arrive through routine changes.

Get control of machine credentials

List the API keys, access tokens and application identities that connect you to your suppliers, and the ones your suppliers hold for you. Each should have only the access it needs, should expire after a set period and should be monitored. Review which third-party applications have standing access to core systems such as Microsoft 365, which is the kind of access used in the ConnectWise campaign, and remove any that are no longer needed. Ask critical suppliers how they store the credentials they hold for you and how quickly they could revoke and replace them after a breach. LiteLLM's exposed key stayed valid for more than four months.

Update contracts

Contracts should require suppliers to tell you before they add AI features that process your data, start using a new AI model provider or bring in new subcontractors for AI services. They should also set short deadlines for reporting incidents, measured in hours rather than days.

Look for shared dependencies

Assessing suppliers one at a time will not show that many of them rely on the same AI provider, gateway or hosting platform. Look across the whole supplier base for these shared dependencies, because a single failure at any of them could affect many services at once. No organisation can see every level of its supply chain alone, but organisations that share what they know about common suppliers and their dependencies with peers can see much further.

Plan for losing an AI provider

For each important business service, establish whether it depends on an AI model, directly or through a supplier. Then work out what would happen if that model became unavailable through an outage, a provider's decision, a regulatory order, export controls or sanctions, whether an alternative model or a manual process could keep the service running, and how long a switch would take. Include this scenario in resilience testing.

Be ready to act within hours

When the next incident like LiteLLM happens, you will need to know within hours which of your suppliers are affected. That means having a pre-agreed way to ask suppliers and collect their answers, and being ready to revoke and replace exposed credentials quickly, using automation where possible.

Keep the response proportionate

Not every supplier needs the same level of scrutiny. Weigh the costs and benefits of each measure and concentrate effort on the suppliers and services where a failure would cause the most harm. A small number of important questions answered reliably is worth more than a large volume of information collected from every supplier.
‍

Conclusion

AI will keep changing both sides of cyber security. Attackers will use it to find and exploit weak points faster, and defenders will use it to detect threats, assess suppliers and respond to incidents more quickly.

AI is also changing what organisations depend on. A small number of AI providers, tools and platforms now sit beneath a large share of the services that organisations rely on, and most of those dependencies are several steps away from the organisations they affect. In October, attackers went after exactly that layer.

Organisations cannot manage risks they cannot see. Those best placed to cope with AI supply chain risk will be the ones that can see beyond their direct suppliers, know which AI services their important operations depend on, and act quickly when one of those dependencies fails.

‍

‍