In just a short few months, we have witnessed several artificial intelligence technology events that deserve the overused “unprecedented” descriptor: a highly complex supply chain attack by TeamPCP, Anthropic PBC’s Claude Code source leak, and the debut of Anthropic’s Claude Mythos, a tool said to be so powerful that its use was immediately restricted to selected enterprises.

As security professionals, we’re staring into a future where AI-related attacks will come from every angle very quickly, and AI defenses simply aren’t ready. It’s the software supply chain that is the real pay dirt for an attacker.

Dangerous convergence

The recent TeamPCP attacks highlight a dangerous convergence of traditional software supply chain threats and the rapidly expanding AI ecosystem. The attackers, exhibiting considerable offensive sophistication, successfully compromised widely trusted security and continuous integration/continuous development tools, including the Trivy open-source security scanner and Checkmarx application security platform. they they targeted LiteLLM, an open-source Python library and proxy server that provides a unified interface for calling over 100 large language models.

The malicious LiteLLM versions (1.82.7 and 1.82.8) were embedded with a highly obfuscated, multistage credential stealer and dropper designed to execute a brutal attack with maximum damage and impact. The blast radius was particularly potent, owing to the nature of common development workflows, in which developers, cloud infrastructure and CI/CD systems often share access to sensitive credentials. The compromise of a single tool, such as LiteLLM, enabled the attackers to move laterally across Kubernetes clusters and exfiltrate data to attacker-controlled domains.

Software supply chain attacks are not new; the SolarWinds incident occurred more than five years ago. However, the TeamPCP breach reimagines the concept entirely. It is the first time we have witnessed a successful weaponization of security and developer infrastructure that requires elevated access privileges. This not only granted the attackers unimpeded access to production secrets but also the ability to launch extortion and ransomware attacks against compromised companies.

Middleware as critical infrastructure

TeamPCP’s breach is a perfect example of what chief information security offficers and security leaders are contending with as part of the new AI attack surface, and organizations must treat AI “middleware” as critical infrastructure when planning defensive strategies. Abstraction layers sit directly in the data flow, routinely processing highly sensitive environment variables and application programming interface keys. Any impactful AI governance frameworks should classify AI middleware as high-risk components and apply stringent monitoring to the secrets they employ and sensitive repositories to which they often have unfettered access.

AI governance policies should mandate that any infrastructure supporting LLM interactions be continuously monitored for unauthorized outbound connections and data exfiltration. Also secure developer workflows should be enforced against cascading supply-chain compromises.

We must also modernize our risk management practices to ensure that developers have the expertise to securely configure, review and monitor tool output and changes. For example, we should correct processes such as dependency pinning to prevent malicious automated update execution, modernize secrets management and apply least-privilege treatment of access keys to throttle pipeline execution to an organizationally approved list of actions.

This attack also highlights just how crucial it is to prioritize visibility into and control over Model Context Protocol agents. The damage from this attack was particularly devastating, in no small part because undocumented MCP plugins were used and could be compromised for nefarious purposes. We simply cannot be this lax when implementing technology with such autonomous power and internal connectivity.

Risk management for AI

The speed of this attack, which saw thousands of potential compromises in just a few hours, proves that reactive security is no longer viable. By locking down dependency pipelines and strictly governing the secrets that fuel AI applications, we can reduce the blast radius of these sophisticated supply chain threats.

Developers can be empowered to share responsibility for AI security by:

• Continuously upskilling and training on the latest AI security issues. Traditional software development is fast becoming a thing of the past, but the real-world skills required for a developer to be truly great will remain. Enterprise security leaders must ensure that their training is continuous, supporting a solid foundation in security and development best practices. These practical skills, coupled with irreplaceable insight into business objectives and critical thinking, are the main ingredients needed for successful code review.
• Using AI governance tools. How do you know which developers committed what code, including the tool they used to do so? The new era of AI coding demands a comprehensive control plane governing AI tools, the commits they are involved in, and the security skills of those building and augmenting features.
• Conforming to organizational rulesets and guidelines. Is your organization’s security program up to date enough to provide guidelines on AI use? How about AI-specific rulesets for the tools in use? These are quick wins that can at least enforce minimum secure coding standards.

If you’re waiting for legislation to guide your organization’s AI governance path, it may be that an AI-assisted breach finds you first. Don’t get caught unprepared.

Matias Madou is co-founder and chief technology officer of Secure Code Warrior Ltd. He wrote this article for SiliconANGLE.

Image: SiliconANGLE/Ideogram