Category: AI Security

Two compromised versions of LiteLLM sat on PyPI for roughly 40 minutes on the morning of March 24, 2026. That window was enough to capture secrets from around 434,000 CI/CD pipeline runs across nearly 2,500 organizations, including AWS, Samsung, Cisco, Salesforce, Siemens, and Deloitte. In August, researchers at CloudSEK and Hudson Rock confirmed they had obtained the raw exfiltrated data: a 153GB archive containing 433,909 files of environment variables, cloud keys, Kubernetes secrets, and API tokens harvested live from running pipelines, as covered by Help Net Security’s reporting on the credential archive. If LiteLLM runs anywhere in your stack, or you touch any AI proxy infrastructure at all, you need answers to three things: whether you were exposed, what to rotate first, and whether the rotation you did back in March actually held. That last one matters more than it sounds, because “we rotated everything” has already burned at least one very large company. How the Breach Happened The attack didn’t start with LiteLLM. On March 19, 2026, a threat group called TeamPCP compromised the build pipeline of Trivy, a vulnerability scanner half the industry runs, and pushed a poisoned release. LiteLLM’s own CI pipeline ran Trivy, so the poisoned scanner had legitimate read access to the project’s runner environment. The attackers used that to steal LiteLLM’s PyPI publishing tokens and ship two malicious releases of their own: versions 1.82.7 and 1.82.8. KICS and the Telnyx Python SDK got hit in the same campaign. The payload design is the part worth studying. The malicious package dropped a .pth startup hook into site-packages, so the code ran the moment any Python interpreter started on the machine, whether or not anything imported LiteLLM. From there it harvested environment variables, read local credential files like .aws/credentials and .kube/config, tried to move laterally across Kubernetes clusters, and installed a systemd backdoor dressed up as a generic telemetry service. InfoQ’s coverage of the PyPI compromise put downloads of the compromised release above 40,000. For scale, LiteLLM normally gets downloaded around 3 million times a day. The exfiltration had a nasty fallback, too. According to CloudSEK, stolen data was encrypted and sent to a typosquatted domain, and when that failed, the malware created a public repository inside the victim’s own GitHub account and uploaded the loot as a release asset. Some companies were publishing their own secrets to the open internet and had no idea. Worth Knowing: The malicious code only existed in the PyPI artifacts. The GitHub source repository stayed clean the whole time, so a developer reviewing the code on GitHub saw nothing wrong. Source review isn’t artifact verification. If you don’t check that what the registry serves matches the upstream source, this class of attack is invisible to you. How to Check If You Were Exposed Three checks, from quickest to most involved. 1. Confirm whether the compromised versions ever ran The malicious versions went live on PyPI at 10:39 UTC on March 24, 2026 and got quarantined about 40 minutes later. The project’s advice: treat any install from that day before 16:00 UTC as suspect. Search your lockfiles, pip caches, SBOMs, and container image histories for 1.82.7 and 1.82.8. And check your internal artifact mirrors. An Artifactory or Nexus proxy that cached the bad release in March can keep serving it internally long after PyPI pulled it. Keep the .pth mechanism in mind when you scope this. The question isn’t “which applications import LiteLLM,” it’s “which machines had the package installed at all,” because every Python process on an infected machine triggered the payload. 2. Hunt for persistence Rotation is pointless if the attacker still has a foothold. Check developer machines, CI runners, and containers for unauthorized .pth files in site-packages and for suspicious systemd units, especially anything posing as a system telemetry service. And review activity from March 24 onward, not just the 40-minute window. Persistence is there so the access outlives the infection. Pro Tip: Don’t limit the persistence hunt to live machines. Base container images rebuilt in late March may have baked the payload into every image derived from them since. Scan your image registry for the affected LiteLLM versions and for unexpected .pth files, then trace which running workloads came from flagged images. 3. Check whether your secrets are in the dump Hudson Rock has published a domain lookup tool and is running ethical disclosures for affected organizations, and CloudSEK maintains a high-confidence victim list. Use them, but know their limits. Attribution in this dataset is genuinely hard. One dump with a siriusxm.com committer email actually traced, through its self-hosted GitLab endpoints, to AdsWizz, a SiriusXM subsidiary. And a large share of the dumps are generic pipeline configurations with no identifying domain, email, or server name at all. Absence from a victim list is not evidence of absence. If your pipelines ran the compromised versions, assume exposure no matter what a lookup tool tells you. What to Rotate, in What Order The guidance from both research teams is blunt: treat every secret the LiteLLM environment could reach as compromised. That covers secrets on disk, in memory, injected into CI jobs, and anything retrievable through instance metadata services. Work down by blast radius: Priority Credential type Why it comes first 1 Cloud IAM keys (AWS, GCP, Azure) Direct control of infrastructure, data stores, and billing. This is where attackers monetize fastest. 2 GitHub and GitLab PATs, package publishing tokens These let an attacker poison your releases and turn your company into the next link in the supply chain. 3 Kubernetes service account tokens and kubeconfigs Lateral movement across clusters was built into the payload, not a theoretical risk. 4 Database passwords and third-party API keys Dumped in plain text in the archive, often with no attribution, so nobody will warn you they leaked. 5 AI provider API keys Billing abuse, quota theft, and access to whatever data flows through your LLM routing layer. One word matters more than the rest of this article: revoke, don’t just rotate. That

Secure AI Agent Vendor

An AI agent that can read your inbox, query your CRM, and dig through internal documents has more standing access than most of your employees. It handles sensitive data, acts on its own, and often passes that data through sub-processors you’ll never see. Certifications are the quickest way to tell which vendors have let an outsider check their work, and which ones just put the word “secure” on a landing page. No single certificate proves an AI agent is safe. But the right mix of security attestations, privacy certifications, and AI governance standards tells you the vendor has real controls, that an independent auditor has tested them, and that someone is on the hook when the agent misbehaves. This guide covers which certifications to ask for, how to verify them, and which claims should make you walk away. The Core Certifications Every Secure AI Agent Vendor Should Hold SOC 2 Type II SOC 2 Type II is the baseline for any SaaS or AI vendor that handles customer data. A licensed CPA firm audits the vendor against the AICPA’s Trust Services Criteria (Security, Availability, Processing Integrity, Confidentiality, and Privacy) and reports on whether its controls actually worked over a review period, usually 3 to 12 months. A Type I report only confirms the controls existed on one particular day. For an AI agent vendor, insist on Type II. Anything less tells you nothing about how the company runs day-to-day. ISO/IEC 27001 ISO/IEC 27001 certifies that the vendor runs a formal information security management system (ISMS): documented risk assessments, defined controls, internal audits, and management review, all verified by an accredited certification body. It’s the most widely recognized security certification outside the US and often a hard procurement requirement in Europe, the UK, and the Gulf. A vendor with international customers should hold it alongside SOC 2, not instead of it. ISO/IEC 27701 (Privacy Information Management) ISO/IEC 27701 extends ISO 27001 with a privacy information management system (PIMS). It maps closely to GDPR concepts like controller and processor obligations, consent, and data subject rights. Almost every AI agent processes personal data at scale, and ISO 27701 is a decent signal that the vendor has built privacy into how it operates instead of delegating it to a policy PDF. ISO/IEC 42001 (AI Management Systems) ISO/IEC 42001 is the first certifiable international standard for AI governance. According to the International Organization for Standardization, it sets out requirements for building and maintaining an AI management system (AIMS): AI risk management, AI system impact assessments, lifecycle management, and oversight of third-party suppliers. For an AI agent vendor, this is the one that covers what SOC 2 and ISO 27001 don’t: how the vendor governs model behavior, training data, and the wider impact of autonomous systems. Worth Knowing: ISO 42001 certificates only started appearing in volume in 2024, and the accreditation ecosystem is still catching up. Check that the certificate came from a certification body accredited for ISO 42001 specifically (under ANAB or UKAS, for example), not just one accredited for ISO 27001. HIPAA (for Healthcare AI Agents) If the agent touches protected health information (PHI), the vendor has to comply with the HIPAA Privacy and Security Rules and sign a Business Associate Agreement (BAA). There’s no official HIPAA certification, so vendors prove compliance through third-party assessments, a SOC 2 with HIPAA mapping, or HITRUST CSF certification. A vendor that won’t sign a BAA has disqualified itself for healthcare work. PCI DSS (for Payment-Handling AI Agents) AI agents that process, store, or transmit cardholder data (think agents automating billing, refunds, or checkout) fall under PCI DSS. Ask for the vendor’s Attestation of Compliance (AOC) and check whether a Qualified Security Assessor validated it or the vendor assessed itself. The current version is PCI DSS 4.x, so an AOC that still references 3.2.1 is out of date. FedRAMP (for Government-Facing AI Agents) FedRAMP authorization is mandatory for cloud services sold to US federal agencies. Authorizations come at Low, Moderate, and High impact levels, and every authorized service appears on the public FedRAMP Marketplace. If a vendor claims FedRAMP status and isn’t in the Marketplace, either the claim is false or the service is still “in process,” and those are very different things. State and local buyers should look for StateRAMP instead. Worth Knowing: ISO 42001 Certificates ISO 42001 certificates only started appearing in volume in 2024, and the accreditation ecosystem is still catching up. Check that the certificate came from a certification body accredited for ISO 42001 specifically (under ANAB or UKAS, for example), not just one accredited for ISO 27001. HIPAA (for Healthcare AI Agents) If the agent touches protected health information (PHI), the vendor has to comply with the HIPAA Privacy and Security Rules and sign a Business Associate Agreement (BAA). There’s no official HIPAA certification, so vendors prove compliance through third-party assessments, a SOC 2 with HIPAA mapping, or HITRUST CSF certification. A vendor that won’t sign a BAA has disqualified itself for healthcare work. PCI DSS (for Payment-Handling AI Agents) AI agents that process, store, or transmit cardholder data (think agents automating billing, refunds, or checkout) fall under PCI DSS. Ask for the vendor’s Attestation of Compliance (AOC) and check whether a Qualified Security Assessor validated it or the vendor assessed itself. The current version is PCI DSS 4.x, so an AOC that still references 3.2.1 is out of date. FedRAMP (for Government-Facing AI Agents) FedRAMP authorization is mandatory for cloud services sold to US federal agencies. Authorizations come at Low, Moderate, and High impact levels, and every authorized service appears on the public FedRAMP Marketplace. If a vendor claims FedRAMP status and isn’t in the Marketplace, either the claim is false or the service is still “in process,” and those are very different things. State and local buyers should look for StateRAMP instead. Regulatory Frameworks AI Agent Vendors Must Comply With Certifications are voluntary. Regulations aren’t. A credible AI agent vendor should be able to explain, in writing, how it meets

When researchers found that Microsoft 365 Copilot could be tricked into leaking corporate data from a single email, the flaw got a clean public identifier: CVE-2025-32711, severity 9.3. When a bug hunter coaxed ChatGPT into producing valid Windows product keys by framing the request as a guessing game, it got nothing.  Both were prompt injections. Only one is trackable. That Vulnerability Tracking Gap in AI Security, and what it costs defenders, is the subject of this article. What Is a CVE and Why Does It Matter for Software Security? A CVE (Common Vulnerabilities and Exposures) is a unique public identifier for a specific software flaw. It gives the whole industry one name for one bug, so a researcher in Berlin and an analyst in Bahrain know they mean the same thing. The Role of MITRE’s CVE Program in Traditional Vulnerability Management The CVE program is run by the MITRE Corporation, a US nonprofit. Since 1999 it has assigned hundreds of thousands of IDs, each tied to a discrete, reproducible defect in a defined product and version. A CVE is the connective tissue of coordinated disclosure: a researcher reports the flaw, the vendor patches it, the ID is published, and defenders map it to their own assets. Without that shared label, the same bug ends up with three names and no clear owner. The National Vulnerability Database (NVD) and CVSS Scoring The National Vulnerability Database, maintained by NIST, enriches each CVE with a CVSS (Common Vulnerability Scoring System) score from 0 to 10. That lets teams triage: a 9.3 jumps the queue, a 4.0 waits. Why Prompt Injection Breaks the Traditional CVE Model The CVE model assumes a bug lives in code, sits in a version, and can be fixed. Prompt injection violates all three. Prompt Injection as a Class of Attack, Not a Discrete Bug Prompt injection smuggles instructions into the data an LLM reads, so the model follows the attacker rather than the user. OWASP ranks it as LLM01, the top entry in its 2025 Top 10 for LLM Applications. It is a property of how language models work, not one line of faulty code, so you cannot file a CVE against it. A SQL injection either works or it does not. A prompt injection might succeed nine times in ten, fail on the eleventh, then stop working after a silent model update, which makes the “reproducible” part of reporting genuinely hard. Model Versioning vs. Software Versioning Software has clean version numbers. A weight update to a hosted model can ship silently, with no version a researcher can cite. Two calls to “gpt-4o” a week apart may not behave the same way, and there is no changelog to point at. Why “Patching” an LLM Differs From Patching Code Patching code closes a specific hole. A developer rewrites the faulty line, ships the diff, and the exploit path is gone for good. That clean, binary, auditable loop is the entire premise on which the CVE system rests. “Patching” a model offers none of it. There is no single line to fix, because the behavior the attacker abused is the same behavior that makes the model useful: it reads text and follows instructions. A vendor’s only levers, retraining, hardening the system prompt, or wrapping the model in input and output guardrails, all lower the odds of a successful attack rather than removing the possibility. The fix reduces the success rate from 80 percent to 5 percent and marks it as remediated. The hole is narrower, not closed. The recent record shows how thin that margin is. EchoLeak got past Microsoft’s dedicated cross-prompt-injection classifier by hiding its exfiltration channel in reference-style Markdown that the filter did not recognize, and the AgentFlayer exploit slipped through OpenAI’s URL safety check by routing stolen data through trusted Azure Blob Storage links. Each guardrail worked against the obvious version of the attack and fell to a rephrasing. There is a tuning tax on top of that: crank the filters too tight and the model starts refusing legitimate work, so vendors settle for a balance point rather than elimination.  The practical takeaway is to treat “we’ve addressed this” as risk reduction, not closure. SOC 2, ISO 27001 and HIPAA done for you. Fixed fee, 100% audit pass rate. Audit-ready in 6 weeks. Not 6 months. Schedule A Free ASSESSMENT The Current State of AI Vulnerability Tracking Several frameworks exist. None is a true registry of individual, citable prompt injection vulnerabilities. OWASP LLM Top 10 and the LLM01 Classification The OWASP GenAI Security Project’s LLM01:2025 entry is the most cited reference point. It is a category, not a catalog: it does not enumerate specific incidents with IDs. MITRE ATLAS for Adversarial AI Threats MITRE ATLAS is an ATT&CK-style knowledge base of adversarial tactics against AI systems, documenting 16 tactics and more than 80 techniques with real-world case studies as of late 2025. It maps how attacks work, but is not a per-vulnerability ledger with scores. AVID (AI Vulnerability Database) and Its Limitations AVID, run by a nonprofit, is the closest thing to a dedicated AI vulnerability database, cataloging failure modes with reproducible evidence. But it leans on community submissions, skews toward bias and broader failure modes, and notes that the definition of an “AI vulnerability” is itself still a working one. Vendor-Specific Disclosures vs. Industry-Wide Registries Disclosure happens vendor by vendor. OpenAI patched the Windows-key jailbreak server-side; Microsoft fixed EchoLeak and issued a CVE. There is no common venue where these land side by side.   The Consequences of No Shared Threat Registry for Prompt Injection Fragmented Disclosure Across AI Vendors Each lab discloses on its own terms, on its own blog, if at all. A defender protecting a multi-model stack has to monitor a dozen channels and hope nothing slips by. Duplicate Discovery and Wasted Research Effort Researchers rediscover the same attack repeatedly. The guessing-game jailbreak, the “dead grandma” trick, and other framing attacks are variations on one theme nobody numbered. No Standardized Severity Scoring for