SentinelOne Prompt Security: The Verdict

3 hours ago

9 min read

Before anything else - read this bit

This whole series is testing that Iqra and I did ourselves, by hand, on our own tenant, on our own machines, with fake data.

That means two things.

We may have got something wrong. We may have tested only half of something, misread a setting, or drawn a conclusion from one path that does not hold on another. We have already corrected ourselves twice mid-series - once when Iqra was right and I was wrong about app-specific rules overriding the locked code-assistant rule, and once on file attachments, where my result contradicted hers and the honest answer turned out to be "it depends on the policy path".

If you find something wrong, or something missing, tell us. Reach out and we will correct the article and say what changed. Security is not one person's job, it is everyone's. We would far rather be corrected in public than leave a wrong finding sitting on the internet for someone to build a deployment on.

There is also a list of things we have not tested yet. The biggest is macOS - every test in this series ran on Windows, plus WSL. We have not run the agent or the extension on a Mac at all. Three console modules were locked in our tenant and never tested: Agentic AI, Homegrown Apps and Red Teaming. There are smaller gaps too, and they are listed near the end of this part rather than buried. As we test them, we will write them up and add them.

One more thing worth saying plainly, because it changes how you should read all eight parts. Prompt Security is not a SentinelOne product by origin. It was an Israeli startup, and SentinelOne announced it was acquiring it on 5 August 2025, in a deal reported at around $250 million in cash and stock. We have spoken to SentinelOne about this evaluation.

So this is a bought product being folded into a much larger platform, and the SentinelOne team is actively developing it - adding features, changing defaults, extending the application list. Several things we tested in October had already changed by the time we wrote them up. If you find a newer detail, or something we have missed, send it to us and we will add it. As new features ship, we will test them and keep adding.

Everything below is a verdict on what we saw between October and November 2026, in one tenant, on the Employees and AI Code Assistants modules.

What the seven parts actually proved

Compressed, because you have read them or you have not:

Part 1 - what it is. Two sensors: a browser extension and an endpoint agent. One console. Policies hold detectors; rules decide who and what they apply to.
Part 2 - the console. Rules beat policies, priority decides, and the combination that will not save gives you a red error explained only in a hover tooltip.
Part 3 - the extension. Solid on the sites it covers. Per-profile unless you force-install it. Does not run in private windows unless somebody ticks a box by hand.
Part 4 - the agent. A local mitmproxy with a tenant root CA, intercepting a fixed list of AI destinations. Covers desktop apps and CLI tools. Does not cover browsers - that is the extension's job.
Part 5 - the actions. Detect, Protect, Block and Don't Track. Protect genuinely redacts before the model sees it, with typed placeholders. The redaction is the best-built thing in the product.
Part 6 - the evasions. Spaces in a key defeat the pattern. A split key defeats it. A private window, an unlisted browser, a VPN extension, a shell without the proxy variable, WSL, or one line in a hosts file defeat the sensor entirely.
Part 7 - the logging. Full logs by default, which stores the raw secret in the console. One locked rule captured our own real client work in clear text.

Where it earns its licence fee

Credit where it is due. These are the things we tried to break and could not.

Redaction is genuinely good. Typed placeholders, the model gets a usable prompt, the app keeps working. [REDACTED_AWS_CREDENTIALS_1] is more useful to a model than a blanket block, and the user is not stopped from doing their job.
Pattern detection on standard formats is reliable. Card numbers were detected in every format we threw at them and correctly ignored when they failed the Luhn check. No false positives on clean prompts in any browser test.
The Natural Language Guardrail is better than we expected, and it is the single most valuable control in the product. It closed split secrets, plain-English passwords, the topic-ordering bypass and the missing jailbreak detector - four separate gaps that no detector setting could close.
Coverage of desktop and CLI AI tools is real, and it is the part most competing controls do not have. A CASB or a web proxy sees ChatGPT in a browser. It does not see Claude Code talking to an API from a developer's terminal.
The agent works as a backstop for browsers it was never installed into - Claude, ChatGPT and Gemini web were still caught with no extension present.
Block is unambiguous when you need it. A whole-domain ban with a clear message, logged. If the requirement is "staff must not use their personal ChatGPT for work", this does it properly.

That is a real product. It is not vapour, and the engineering underneath the detectors is sound.

What has to be true for it to work

This is the part a datasheet will not tell you. Prompt Security only delivers the above if all of these hold. Miss one and you have a dashboard that looks healthy over a gap.

The extension is force-installed by policy, and private browsing and guest mode are disabled by registry. A manual install is per-profile, removable in one click, and off in incognito. There is no policy setting for the incognito toggle - the only enforceable fix is removing private browsing entirely.
An identity provider is connected. Without it, agent events carry a Windows account name and extension events often carry nothing. User-scoped and group-scoped rules cannot match a user the console cannot name.
Local administrator rights are restricted. A local admin can stop the agent, remove the extension, or edit a hosts file. None of those raise an alert.
The log type is changed away from Full on day one, or your console becomes a searchable store of your own clients' secrets, exportable to CSV by any admin.
The locked code-assistant rule is dealt with before developers do real work. Detect plus log-all-interactions on AI code assistants means full capture of engineers' working context. That is how our own live client work ended up in the vendor's cloud.
You monitor endpoint connectivity to the vendor's hostname yourself. There is no device inventory, no sensor health view, and a sensor that cannot reach its server fails open silently - including with Fail Close set.
Your users' AI tools are on the supported list. Everything off the list gets prompt inspection only, or nothing. You cannot add an application yourself.
Your developers are not working in WSL, a VM or a container, or you accept that those paths are uninspected.

Eight preconditions. Most are deployment decisions, and every one of them is cheaper to make before rollout than after.

Where it does not earn it

Being fair about the limits is what makes the rest of the series worth reading.

It stops accidents very well. It does not stop a determined insider at all. Spaces in a key, a second browser profile, a VPN extension, a shell without the proxy variable, thirty seconds with a hosts file. None of that needs more than ordinary user rights.
Replies are not inspected. Detectors run on the way in only. "Break the pattern going in, let the model repair it coming out" worked every time we tried it.
The console does not tell you what it cannot see. No device list, no extension health, no alert when a sensor goes dark, no flag on an application set to Don't Track.
The defaults are the permissive ones. Full logs, 30-day retention, prompt text visible to every admin, a locked rule capturing everything.
There is no rules API. Policies are scriptable; who a rule applies to and what it does is console-only clicking, per tenant. No Terraform, no configuration as code, no way to audit rules programmatically.
For an MSSP there is no single pane of glass. Each client gets their own console instance. Per-client onboarding, per-client policy work, per-client monitoring.

What I would tell a client deciding

Three different answers, depending on who is asking.

If the question is "will this stop our staff pasting customer data into AI?" - yes, largely, provided you deploy it properly. That is the accident case, it is the majority of real incidents, and the product is good at it. Buy it.

If the question is "will this stop a developer exfiltrating source code through an AI tool?" - no. Not this product, not any product in this category. Do not let anyone sell you that. The evasions in Part 6 are not exotic; they are a space bar and a second browser.

If the question is "can we run this for our clients as a managed service?" - yes, with your eyes open. The per-client console model, the missing rules API and the absent device inventory are all staffing costs rather than blockers. Price them in. And settle the logging and data-residency questions with the client's compliance function before the first agent is installed, not after - because from the moment the agent installs, their live work is in the vendor's cloud.

The honest summary of the whole series: this is a good product with permissive defaults and an optimistic console. The detection engine is not the risk. The risk is the paths nobody drew on the diagram, and a dashboard that looks green while a sensor sits disconnected on somebody's laptop.

The rollout order I would actually use

If I were deploying this tomorrow, in this sequence:

Decide the logging posture first. Log type, retention, prompt-text visibility, and what happens to the locked code-assistant rule. This is the only step that is genuinely hard to undo.
Get the root certificate and decryption scope approved in writing, naming the fact that traffic is decrypted even where it is not logged.
Connect the identity provider. Everything about attribution and group rules depends on it.
Write the Natural Language Guardrail before tuning a single detector, with an explicit allow-list for the legitimate questions your staff ask. Allow ten minutes for changes to land.
Force-install the extension and disable private browsing and guest mode in the same change window.
Install the agent on a pilot group, not the whole fleet, and read the activity log after a week before going wider. We found our own live client data that way.
Start everything in Detect, look at what comes in, then move to Protect once the false-positive picture is real.
Set up your own monitoring of sensor connectivity, because the console will not do it for you.
Write down the uncovered paths - WSL, VMs, containers, unlisted browsers, VPN extensions, private windows if you could not disable them - in the design document, so they are accepted risk rather than a surprise during an incident.

What we have not tested

Named plainly, so you know the edges of this series.

macOS. Everything here is Windows plus WSL. Not one Mac test. Agent Hardening in the console is macOS-only and was disabled in our tenant, so we could not even read what it does.
The three locked modules: Agentic AI, Homegrown Apps and Red Teaming. The jailbreak and prompt-injection detectors live in those, not in the employee policy.
The "save only basic metadata" log type.
SIEM and S3 delivery with storage disabled - whether events arrive, and what happens when the destination is down.
Whether the "View conversation" click is written to the admin audit log. That single answer decides whether the prompt-visibility gate is a control or a speed bump.
Redacted versus Full on the agent path. One test suggested Redacted lost the violation record entirely. It is marked Open and needs a controlled retest.
Binary attachments - PDF, Word and images - on the developer policy path.
Homoglyphs and zero-width characters as an evasion.
An unlisted browser under agent-only coverage.
The ChatGPT governance controls on an enterprise workspace. We tested them on a personal account, where seven of eight did nothing.
Linux browsers, which the vendor's own documentation says are not supported at all.
The MSSP child-tenant model, which we could only read in the API reference because our tenant has no children.

Where this goes next

Prompt Security was a startup until August 2025. It is now part of a platform that has every reason to push it hard, and the development pace shows - policies, application lists and defaults changed under us during a four-week evaluation.

That cuts both ways. Gaps in this series may be closed by the time you read it, and controls we verified may behave differently after an update. Which is the real reason for the note at the top: treat this as a snapshot with the method shown, not as a permanent truth. The method is the part worth copying - test every channel yourself, with fake data, on your own tenant, and write down what you could not test.