r/SentinelOneXDR

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.

I am trying to retrieve files from devices and set the same password i have always set but for the the last week or so when opening the Zip it says the password is wrong. To make sure i am not fat fingering anything i have tried copy and pasting the password into the portal when retrieving the file and when opening the zip.

Is anyone else seeing this?

Hello,

I am managing SOne through my company and some servers are under OpenAnolis os. However we would like to upgrade the SentinelOne agent but we are worried about the compatibility and I do not find anything within SOne documentation.

Any information about that ?

Thank you

No matter what happens, Connectwise sets the status of an incident to true positive and moves on. This is has happened hundreds of times and every time they have been wrong. We have tried talking to them, but it's pointless. You can never track down anyone that the ability to do anything.

#1 Is this the experience of everyone buying through connectwise?

#2 If you use someone else, who actually cares, please share their name. *for any msps, vendors, resellers, please do not self-promote.

Hi all - does anyone know the proper process for getting our signed files reviewed/whitelisted by SentinelOne?

We are a software vendor and our executables are code-signed by our company, but SentinelOne keeps detecting them as malicious. This is creating a lot of friction for our customers. With other security products, similar false positives in the past eventually corrected themselves, but with SentinelOne the issue has persisted for quite a while.

Right now, every MSP/IT department we work with has to create exceptions manually, usually based on our publisher name. That works, but it is not ideal and it creates unnecessary support overhead for everyone.

We are happy to contact SentinelOne directly and provide hashes, signed installers, company details, certificates, or anything else they need to review and fix the detections properly.

Has anyone gone through this process before? Is there a vendor submission portal or a recommended way to escalate recurring false positives?

Hi everyone, I'm reviewing a "Critical - Ransomware" alert ("VSS Shadow Copies Deletion Attempt detected") and I have a question about the timestamps and mitigation logic.

Here is the timeline from the report:

• 06:28:24 - vssadmin.exe executes delete shadows /for=C: /oldest
• 06:30:28 - diskshadow.exe is executed (presumably a fallback)
• 06:31:06 - SentinelOne executes "Kill" (11/11 processes) and "Quarantine". Mitigation status is "Success / Mitigated".

The dilemma: There is a 3-minute gap between the first execution and the final Kill action.

Does the SentinelOne agent intercept and block the deletion command at the kernel level in real-time (06:28), or is there a risk the shadow copies were actually purged before the Kill at 06:31?

SentinelOne, in the alert, consistently uses the word "attempted", which implies the deletion failed... but is Sentinel just being optimistic, or can I trust that "attempted" means the backups are 100% safe despite the delayed Kill?

I went through everything and found a way to bypass that detection feel free to DM me if you are also facing the same issue.

please help im trying freya is raganrock online private server but the sentiel one is blocking me

I got an alert around 4:00 AM this morning about an active threat on one of our endpoints which S1 killed successfully. After investigation, the threat turned out to be a false positive, so I marked it as such (False Positive/Benign in Singularity). I also added the hashes to our exclusion list because it's a software auto-updater we need to run on our endpoints.

Since then, I've gotten 40 notifications about the process being successfully killed. The auto-updater process S1 flagged has now successfully run on this endpoint, so I'm not sure what's happening here. Is it still actively trying to kill the process when it runs even though I've marked it false/benign/resolved/excluded or is this just a weird glitch? In the alert details, the Mitigation tab shows "KILL 40/40 SUCCESS, 40 out of 40 actions completed successfully in under 46491479ms"

EDIT: Logged in this morning to many more alerts, and now seeing "KILL 94/94 SUCCESS, 94 out of 94 actions completed successfully in under 109910112 ms" so it's still going.

Hi guys. Just got employed by a company that uses SentinelOne and YunShu. Just now, I can't play Valorant with my friends because of Riot Vanguard issues, and the only thing installed recently is both.

Is there a way around this? Or is the only way to contact the IT department to exclude Valorant and Riot Vanguard paths?

PS: No, this is not a work desktop/laptop that the company provided. It's a personal desktop.

This just started today, but we have endpoints now that are showing up as base64 characters, they don't even decode to the same of the endpoint either. Just wondering if anyone else is experiencing this in their visibility queries?