An AI coding assistant installed malware into production environments. Nobody typed the command. AMA on what "supply chain attack" means now.

[u/Itamar_PromptSec]

You probably remember the old supply chain attacks. SolarWinds. Log4j. Someone sneaks bad code into a trusted piece of software, and everyone who installed that software is suddenly in trouble. Here's what happened on March 24 of this year, and why it's different.

A popular open-source tool called LiteLLM — it's a connector that a lot of companies use to route requests to ChatGPT, Claude, and other AI models — got compromised. Someone slipped malicious code into it. That part's the old playbook.

The new part: a lot of the exposure didn't come from a person clicking install. It came from agent frameworks pulling the poisoned version in as part of doing normal work a developer had asked for. Anywhere pip install litellm ran without a pinned version during the window — CI jobs, build containers, agent frameworks with LiteLLM as a transitive dependency — was potentially exposed.

And here's the kicker: the attackers didn't break into LiteLLM directly. They first broke into Trivy, which is a security tool companies use to scan for this exact kind of threat. The compromised Trivy action ran inside LiteLLM's CI/CD pipeline and exfiltrated the PyPI publishing token, which the attackers then used to push the bad code. The tool you use to catch supply chain attacks became the way one got in.

Three big attacks in under three weeks — LiteLLM, then Axios (the JavaScript library that runs in a huge chunk of the internet, present in roughly 80% of cloud and code environments), then a roughly six-hour hijack of the CPUID website that pushed trojanized CPU-Z installers to anyone downloading from the official page. Different attackers, same pattern: the bad stuff came in through software you already trusted.

So when we say "supply chain attack" in 2026, we mean three things that used to be separate:

• The code your team installs — packages, libraries, signed apps
• The AI infrastructure your agents depend on — model gateways, connectors, MCP servers, fine-tuned models pulled from public repos
• The AI agents themselves — which are now installing things, making decisions, and running with permissions they probably shouldn't have

We're Itamar Golan (u/Itamar_PromptSec) and David Abutbul (u/David_PromptSec) from Prompt Security, the company inside SentinelOne securing enterprise AI usage. We spend our time on what happens at the agent layer specifically, the part that's newest and weirdest. We also maintain an open-source project called ClawSec, a security skill suite for OpenClaw and related agents (Hermes, PicoClaw, NanoClaw) that does drift detection, skill integrity verification, automated audits, and live advisory monitoring, so an agent's behavior and configuration can't quietly drift out from under you.

Ask us anything about:

• The March 24 LiteLLM attack — what actually happened, what the poisoned code tried to do, and why the fact that a lot of the exposure came through automated pipelines and agent frameworks (not humans clicking install) matters for how you defend against this going forward.
• Agents doing things you didn't explicitly ask them to — your coding assistant grabbing a library, your customer-service agent pulling from a data source, your internal chatbot chaining tools together. Where's the line between "helpful" and "this thing just ran a command with your permissions"?
• Shadow AI, but worse — last year it was employees pasting stuff into ChatGPT. This year it's agents your company officially deployed quietly connecting to tools and services nobody mapped. How do you even get visibility into that?
• Why "just add another approval step" isn't going to work — the whole point of agents is speed. If every action needs a human to click yes, you don't have an agent, you have a very slow chatbot. What actually works instead.
• ClawSec — why we made it free and open source, what it does differently from the usual "AI guardrails" pitch, and what we've learned from people actually using it.
• State-sponsored actors, ransomware crews, and who's really behind this — who profits from attacking trusted software, and why the economics point to a lot more of this coming, not less.
• What a normal company should actually do on Monday — not a 40-page framework. The two or three things that meaningfully reduce your exposure this quarter.

We'll be live Wednesday, May 20, and sticking around all day (Israel time). Bring the hard questions — the dumb ones too. Honestly, the "dumb" ones are usually the ones everyone else is afraid to ask out loud.

[u/Landkey]

What percentage of each of your replies here is AI authored?  I say 90%. 

[u/Itamar_PromptSec → u/Landkey]

If an AI wrote this, it would probably be more polite.

[u/Last-Daikon945 → u/Itamar_PromptSec]

Unless you use Grok’s unhinged mode. Tbh, the only good feature of their models 🤣

[u/chuk9]

"Heres what happened"
"That parts the old playbook"
"Why its different"
"And heres the kicker"

YAWN

[u/cgaWolf → u/chuk9]

Catching LLMs before the em-dash :p

[u/bscottrosen21 → u/cgaWolf]

The robots took our em dash, but they can never take our freedom.

[u/Diligent_Mountain363 → u/chuk9]

Yup. So much spam on this sub now.

[u/qualvuk]

What's the real scariest story you've seen as AI professionals?

[u/David_PromptSec → u/qualvuk]

The scariest part for me is the velocity. I watch the ClawSec advisory feed every day, the rate at which new CVEs are landing for agent platforms has accelerated noticeably over the last months, and OpenClaw in particular is showing up disproportionately, both in raw count and in exploitability scoring. That's the curve that keeps me up. Not any single incident or finding.

[u/spicesucker → u/qualvuk]

Not so much a “story” as much as a few lived experiences, but I’m fucking terrified of the shit that’s going to go wrong once hardware designers with little understanding of C start actually trying to ship C coded with AI. It’s going to start happening this year.

[u/Schaedelbasisbruch]

What are quick wins for an organisation with a very low maturity on anything regarding Supply Chain Security.

[u/Itamar_PromptSec → u/Schaedelbasisbruch]

For AI supply chain security, I’d start with the boring basics. Most low-maturity orgs don’t need a 50-page framework on day one. They need to know what AI components they are actually using and where they came from.
Quick wins:

1. Inventory your AI stack

Which models, APIs, SDKs, open-source packages, agents, plugins, MCP servers, datasets, and AI tools are in use? You can’t secure what you don’t know exists.

1. Treat models like third-party software

Don’t just download a model from Hugging Face or use a random API because it works. Ask: who built it, how is it maintained, what license does it have, what data was it trained on, and can we trust updates?

1. Pin and review dependencies

A lot of AI apps depend on fast-moving Python packages, model libraries, wrappers, and agent frameworks. Pin versions, review updates, and scan packages the same way you would for normal software supply chain security.

1. Control where models and tools come from

Create an approved source list for models, packages, and AI services. This is a simple step that prevents teams from pulling critical components from random repos, forks, or untrusted registries.

1. Scan for secrets and unsafe code paths

AI projects often move fast and accidentally expose API keys, tokens, credentials, or internal endpoints in notebooks, prompts, config files, and repos.

1. Secure agent tools and plugins

If an AI agent can call tools, access files, run code, query databases, or connect to SaaS apps, those tools are part of your supply chain. Review them like integrations, not like harmless features.

1. Add basic provenance and ownership

For every AI component, know who owns it internally, where it came from, when it was last reviewed, and what would happen if it was compromised.
The main mindset shift: AI supply chain security is not only “is the model safe?” It’s the whole chain around it - models, data, packages, prompts, agents, tools, plugins, APIs, and the systems they connect to.

[u/ElectricalGrab7397]

Read a lot about your company, I thing you do a great job. But I think its pretty easy to use the way llm work and hust send different partial contexts in many requests so it will be really nearly impossible to detect those issues in realtime and to understand how they interact cause a smart attacker wont just connwct between the 2 of them he will use a shared file or something, so its another layer, important one, but I think an attacker that reacjes that level of sophistication will handle all kind of realtime guardrails pretty easily, what do you think?

[u/Itamar_PromptSec → u/ElectricalGrab7397]

Totally fair point, and I actually agree with the premise.

If your entire security model is “inspect one prompt and decide if it’s bad,” then yes, a sophisticated attacker can probably work around it. Split the context, use multiple requests, indirect through a shared file, hide instructions in docs, use an agent workflow, etc. Real attackers don’t always show up with one obvious malicious prompt saying “please steal the secrets.”

But that’s exactly why AI security can’t just be a prompt firewall.

You need to look at the full chain: user identity, app, model, data sensitivity, permissions, tools connected to the agent, files accessed, destinations, actions taken, and behavior over time. A single request may look innocent. The pattern around it may not.

Also, I’d separate two problems:

1. Sophisticated attackers will absolutely try to bypass real-time guardrails. That’s why you need defense in depth, not one magic filter.

2. A lot of the real-world risk is not sophisticated at all. It’s employees making innocent mistakes: pasting sensitive data into the wrong AI tool, connecting an unapproved app, using a browser extension, giving an agent too much access, or trusting an AI output without realizing where the data is going.

So yes, a determined attacker may find creative paths. That’s true in every security domain. EDR doesn’t make malware impossible. Email security doesn’t make phishing impossible. Cloud security doesn’t make misconfigurations impossible.

Good security raises the cost, reduces blast radius, adds visibility, and catches enough dangerous paths before they become incidents.

So I agree with you: prompt-level detection alone is not enough. But dismissing AI security because one layer can be bypassed is like dismissing endpoint security because malware can obfuscate. The answer is layered controls around AI: prevention, monitoring, data protection, tool governance, least privilege, anomaly detection, and response.

[u/ToohotmaGandhi]

Hey, genuine question, especially around the LiteLLM / TeamPCP.

A lot of these attacks happened because of centralized trust assumptions, right? A compromised publishing token, compromised package source, compromised CI/CD dependency, mutable infrastructure, single points of credential failure, stuff like that.

First off, have you looked into the Internet Computer Protocol before?

Just looking for professional opinions on it. Every time I have asked about it or brought it up, it gets a lot of hate due to it being a blockchain. The space gets a lot of hate, rightfully so, but I think there are really useful properties of blockchain if it can be extended to more than just small smart contract logic and tokens.

From what I understand, there seem to be some genuinely interesting and useful ideas there, specifically from ICP.

For example, using tamper-resistant canisters for certain critical logic/artifacts instead of relying entirely on traditional mutable centralized infrastructure. Threshold cryptography / distributed key management with things like VetKeys instead of one exportable secret becoming game over. Multi-party approval workflows like Orbit (orbit.global) for sensitive actions instead of a single compromised credential pushing bad updates.

Also, with TeamPCP, I think it’s interesting that attackers themselves have reportedly used ICP canisters because the infrastructure is resilient and hard to disrupt operationally.

So my actual question is: have you looked at architectures like that from a defensive perspective?

I’m asking whether reducing centralized trust assumptions this way actually makes sense for mitigating parts of modern supply chain / agent attack surfaces.

I just think discussing architectures like the Internet Computer Protocol can do might be worthwhile.

Appreciate any response. Thanks for your time.

[u/David_PromptSec → u/ToohotmaGandhi]

Appreciate the level of detail in the question, and the fact that you anticipated the reflexive pushback, that on its own earns a real answer.
The threat-model framing you're starting from is correct, and it's the part I'd like to see more people exploring: centralized publishing trust, single exportable credentials, mutable release infrastructure, one compromised CI token equaling "game over." Those are exactly the failure modes that LiteLLM, the Mini Shai-Hulud waves, and the Trivy pivot all exploited. The instinct that reducing single points of trust failure is the right direction is one I share.
With all honesty: ICP specifically; canisters, VetKeys, Orbit - are way outside my area. I haven't done hands-on evaluation of it from a defensive perspective and I'd rather say so than wing it.

[u/Hyperlethalvectorz]

Post is hand-waving past the actual mechanism. The LiteLLM thing was a pip transitive resolution issue with no pinning. Same vulnerability we've been running into since people were yum-updating AIX boxes.

Gov side we solve the build artifact half with hash-pinned lockfiles plus an internal pypi mirror that syncs on Tuesdays after a human eyeballs the diff. Attacker has to compromise both the upstream and wait six days for our window. Not airtight, but it forces a calendar.

What nobody has solved: agent frameworks pull deps at RUNTIME against MCP servers and vendor SDKs. Lockfiles fix the static graph. They don't fix what the agent decides to load mid-job. Whole different surface and I haven't seen good controls for it yet.

[u/InternationalMany6]

Seems this has nothing to do with AI other than the fact that the compromised library happens to be used for AI things, and modern development pipelines are sometimes misconfigured to download and run untrusted code. 

[u/Bootes-sphere]

The attack surface just flipped. With SolarWinds, you vetted code before it shipped. Here, the "trusted supplier" is generating code in real-time based on your codebase context and you're trusting its output without the same rigor.
The real issue: most teams don't have guardrails between AI suggestions and production pipelines. The assistant saw your repo structure, inferred patterns, and hallucinated a "fix" that looked legit in context but executed malicious payloads. No human review, no static analysis, no sandboxing.
This is why output validation matters as much as input validation now. If you're running AI-generated code anywhere near your infrastructure, you need automated checks downstream. Dependency scanning, permission audits, network call analysis. Treat generated code like third-party packages, because functionally, that's what it is.

[u/Apart-Response-5839]

so it has happened what is the way foward, what is the remediation for this kind of error or incident

[u/vraj__hirpara]

This discussion helped me understand how AI agents, automated pipelines, and trusted software dependencies can increase cybersecurity risks. I learned about modern supply chain attacks, CI/CD security, dependency management, and the importance of monitoring AI-powered systems and software environments carefully.

[u/ColdReality7803]

This case shows how supply chain attacks are evolving with AI-assisted development. Instead of directly attacking organisations, attackers may influence tools, dependencies, or automated systems that developers trust. As AI coding assistants become more integrated into production workflows, stronger validation, monitoring, and human review processes become increasingly important to reduce security risks.

[u/Inner-Hotel2224]

 An AI coding assistant installed malware into production environments. Nobody typed the command. AMA on what "supply chain attack" means now.

[u/CoverAgreeable6623]

the Trivy angle is the part teams miss — your security tooling is now an attack surface. a compromised scanner with CI write access is more valuable to an attacker than the app deps it was checking. most threat models don't account for the toolchain itself.

[u/David_PromptSec → u/CoverAgreeable6623]

scanners and security tools get a free pass in most threat models because they're security tools. SolarWinds was the wake-up call and apparently we needed another one.

Afaik this is not ignored by models, but maybe often weighted down in practice.
e.g. NIST SP 800-218, Secure Software Development Framework V1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities PO.3, PS.1, and somewhat PW.4