The March 2026 compromise of the LiteLLM framework demonstrated how a weakness in an external dependency can affect organisations that did not develop the component themselves. According to the official LiteLLM security update, versions 1.82.7 and 1.82.8 were published to PyPI without authorisation. The packages contained credential-stealing code designed to harvest environment variables, cloud credentials, SSH keys, Kubernetes tokens and database passwords.
The incident illustrates the wider risk facing organisations adopting artificial intelligence. AI services depend on models, datasets, libraries, APIs, plugins, cloud infrastructure and deployment pipelines. A weakness in any component can affect confidentiality, integrity or availability. Protection therefore requires visibility across the AI lifecycle, evidence about provenance, controls for data and identity and a tested response process.
An AI supply chain includes the components and services used to build, adapt, deploy and operate an AI system. These may include training datasets, pre-trained models, fine-tuning adapters, software libraries, model repositories, APIs, container images, cloud platforms and agent tools.
Exposure depends on architecture. A business training a proprietary model on its own infrastructure faces different risks from one consuming a third-party model through an API. The first may exercise more control over data and deployment. The second may depend more heavily on supplier security, availability and change management.
Concentration risk also matters because many organisations rely on a small number of model providers, cloud platforms and open-source frameworks. A compromise or outage affecting a widely used dependency can therefore have consequences beyond one customer.
AI workloads depend on processors, cloud clusters, storage and orchestration platforms. Data can be manipulated before, during or after training, potentially introducing unwanted behaviour, hidden triggers or distorted results. Traditional software risks also remain present. Vulnerable libraries, insecure registries, weak CI/CD controls and misconfigured model-serving APIs can expose model files, secrets or connected systems.
AI supply chain attacks can target the technical components surrounding a model as well as the model itself. The OWASP guidance on LLM supply chain security identifies risks involving vulnerable packages, outdated models, weak provenance, compromised repositories, poisoned datasets and malicious fine-tuning adapters.
Model poisoning manipulates training data, fine-tuning assets or model files so that a system behaves differently under particular conditions. Possible outcomes include biased responses, hidden triggers, unsafe recommendations or information disclosure.
Unexpected output does not prove poisoning. Models may vary because of ambiguous prompts, incomplete context, configuration changes or weaknesses in the surrounding application. Testing should therefore use repeatable prompts, approved use cases and defined safety boundaries. Material changes should trigger review.
Open-source repositories and package registries provide valuable components but also create dependency risk. A malicious package, compromised account or altered model file can enter a build process before teams identify the change.
Organisations should use approved repositories, review maintainers and release histories, record versions and hashes and restrict the permissions available to build and deployment processes. These controls do not remove risk, but they make unexpected changes easier to identify and investigate.
Indirect prompt injection occurs when untrusted content influences an AI system through retrieval, browsing, documents or connected tools. The content may attempt to alter instructions, disclose information or trigger an unauthorised action.
This is both an application security and supply chain concern because the instruction may come from an external source that the organisation does not control. Access boundaries, content filtering, output validation and human approval become particularly important when AI can access sensitive data or perform actions.
Organisations can reduce AI supply chain risk by verifying component provenance, maintaining an accurate AI inventory, applying least-privilege access and testing models against approved use cases. Strong governance, supplier assurance and tested recovery plans help turn these controls into a practical path towards resilient AI adoption.
Record each model, version, supplier, dataset, adapter, package, plugin, API and deployment environment. Include the business owner, technical owner, approved purpose, data classification, permissions, licensing considerations and dependent services.
An AI bill of materials can structure this information, although it may not reveal every upstream dependency, training-data issue or behavioural risk. OWASP describes AI-BOM and ML-SBOM practices as an emerging area rather than a complete assurance mechanism. Treat the inventory as an operational record supporting change management and incident response.
Use trusted suppliers and approved repositories. Retain release information, hashes, signatures and change records where available. Review supplier security, privacy terms, maintenance commitments and notification processes before deployment and periodically afterwards.
Evaluate third-party models against their intended business use rather than relying only on public benchmarks. Higher-risk use cases may require red-team testing, adversarial evaluation and retesting after material changes.
Limit access to training data, model stores, credentials, deployment pipelines and connected systems. Separate development, testing and production environments. Require human approval before AI performs sensitive, high-impact or irreversible actions. Review access when the model, integration or business purpose changes.
Create playbooks for disabling an integration, revoking credentials, replacing a model, rebuilding an environment and preserving evidence. The LiteLLM incident shows why response should extend beyond the affected package. LiteLLM advised affected users to rotate secrets, investigate hosts and review local environments, CI/CD pipelines, Docker builds and deployment logs.
CyberOne’s Cyber Incident Response service supports investigation, triage, containment, remediation and recovery.
ISO/IEC 42001 specifies requirements for establishing, implementing, maintaining and continually improving an artificial intelligence management system. It supports structured governance but focuses on management processes rather than the technical details of individual AI applications. It should therefore complement, not replace, technical security controls.
The UK Cyber Security and Resilience Bill is not a general AI-provider regulation. Government material says the proposed scope includes defined essential, digital and managed services, alongside powers to designate critical suppliers. Several measures would take effect only after the Bill becomes an Act or through subsequent secondary legislation.
Organisations should assess their services and role in customers’ supply chains rather than assuming that every AI provider is covered. They should also monitor the Bill’s passage and the secondary regulations that will determine the detailed obligations.
Microsoft Sentinel can ingest telemetry through supported and custom connectors. This can help teams investigate authentication events, API activity and access patterns when relevant logs exist. Sentinel does not independently validate model weights or prove model integrity. Its value depends on telemetry, detection logic, baselines and operational response.
Microsoft Purview provides data security and compliance controls for supported generative AI applications, including classification, data loss prevention, auditing and data lifecycle capabilities. Coverage varies by supported application and configuration.
CyberOne’s AssureAI readiness review assesses AI usage, identity, data security, device management, governance, monitoring and attack-surface exposure, producing a prioritised roadmap. Wider cyber maturity can be addressed through AssureMAP, while MXDR as a Service provides continuous monitoring, investigation and response within Microsoft environments.
AI supply chain security is a continuing governance and operational responsibility. Models, packages, datasets, suppliers and integrations change, so assurance must change with them.
The practical priorities are clear: maintain an accurate inventory, verify provenance, restrict access, test important use cases, monitor available signals and rehearse recovery. These controls help organisations understand where AI risk sits and respond effectively when a dependency is compromised.
CyberOne helps organisations connect these priorities with Microsoft security investments, cyber maturity objectives and operational requirements. An AI-focused assessment provides a structured starting point for identifying gaps and prioritising controls that support secure growth.
Reach out to a CyberOne expert for a 30-minute assessment.