SentinelOne Prompt Security: Detect, Protect, Block
Previous two parts were about getting the two sensors into place and finding out where they stop watching.
This part is the question everyone actually asks in the first meeting: when it does see the secret, does it stop it?
The short answer is yes, and better than I expected - redaction on a working AI assistant is the most genuinely useful thing this product does. The longer answer is that "does it stop the leak" is two settings, not one, they live on two different screens, and almost every surprise I hit came from the gap between them.
Two separate choices
A rule decides who, which applications, which platform, and the mode. A policy decides what gets detected and what happens to it. A rule in Protect mode with no useful policy attached protects nothing; a policy with every detector set to Block does nothing at all if the rule that selects it is in Detect.
One rule: who it covers, which apps, web and desktop, the mode - and the Advanced column where the data protection, logging and user education switches live
The four modes:
Mode | What it does | What the user sees | What the console gets |
Detect | Inspects, logs, changes nothing | Optionally a pop-up, then a normal answer | A violation, and the prompt text |
Protect | Applies the policy's action to the prompt | Redacted, hashed or blocked, per detector | A violation and the action taken |
Block | Denies the application outright, no content scan | A block page, or a refusal in place of the reply | The blocked attempt |
Don't Track | Nothing. No inspection, no logging | Nothing | Nothing at all |
Rules run top-down and first match wins, which I covered in Second article of this series. What matters here is that the mode is the outer switch, and the policy's actions only exist inside Protect.
The clearest way to see what that means is to change nothing except the mode. I pointed one rule at one application - a command-line assistant talking to a model on AWS Bedrock - and ran the same two prompts through it five times:
Same rule, same app | Prompt containing a secret | Clean prompt | What the user saw | What the console got |
Protect + Employees policy | Fails | Fails | An AWS signature error | A violation |
Protect + Developers policy | Fails | Works | An AWS signature error | A violation |
Detect | Goes through, secret included | Works | A normal answer | A violation, and the whole prompt |
Don't Track | Goes through, secret included | Works | A normal answer | Nothing at all |
Block | Stopped | Stopped | Forbidden: Blocked by Prompt Security | A blocked event |
That table is most of this article in one picture. Two of the five settings protect nothing, one of them protects everything by breaking the tool, and the two in the middle differ only by which policy is attached - with the wrong one, prompts that contain no secret at all stop working.
Detect does not protect
The name is honest. People still mishear it.
In Detect, the policy's action is read and then ignored. I had a policy with Secrets set to Redact, sent a test SSN through a Detect rule, and watched it arrive at the AI in full and get stored in the console in full. Nothing was redacted, because redaction is a Protect behaviour. The violation was recorded perfectly. The data still left.
My colleague took it one step further and asked the AI to repeat a card number back after sending it through a Detect rule, and it did, because the model received the real number and the reply is not inspected either. Detect gives you an alert about data that has already gone, plus a copy of it in the portal.
That is not useless. It is the right mode for the first two weeks of a deployment, when you want to know what people actually do before you start breaking things, and - as previous part covered - it is the only mode that does not break a signed API call. But if someone in a rollout meeting says the tool is "in detection mode, so we're covered", that is the sentence to stop.
One thing Detect does do:
the violations pop-up still fires if the rule has it switched on. My colleague's test showed "2 violations" for a card and CVV on screen while the prompt sailed through underneath. The user gets told off; the data goes anyway. Useful as education, misleading as assurance - and on the endpoint agent the pop-up never appeared at all, so agent-side Detect is completely silent.
What Protect can actually do to a prompt
Protect is where the policy's per-detector actions come alive, and there are more of them than the marketing summary suggests.
The Secrets action list: Redact All, Redact Partial, Hash or Block - and the detector count next to it
Secrets: Redact all, Redact partial, Hash, or Block. No dummy data option here.
Sensitive Data: Block, Redact, or Generate dummy data - which swaps the value for a realistic fake one. It is offered in the console; neither of us got round to testing it, so I will not claim it works.
Regex: Block or Redact, with your own replacement text.
Hidden names: an exact-match list of your own terms - a project codename, a client name - replaced with [REDACTED_CUSTOM1].
Allowed names: the reverse, and worth reading twice. Values on this list are ignored even if an earlier protection detected them. It is an allow-list that overrules your detectors, so it needs the same change control as a firewall exception.
Topics, Harmful Content and Natural Language Guardrails: allow or block, with a monitored-only option for topics. More on these below.
Redaction uses numbered, typed placeholders rather than a row of asterisks. A card and its CVV come out as [REDACTED_CREDIT_CARD_1] and [REDACTED_CVV_CVC_1]; an AWS key through the Developers policy came out as [REDACTED_AWS_CREDENTIALS_1]; a custom regex match becomes [REDACTED] unless you set your own text. That numbering is a better design decision than it looks. The model can still see that two different cards were removed, so the answer it gives is still about the task.
The Developers policy: Secrets only, Redact All, all 238 detectors on - and the scope chip reading "Prompts"
It works end to end.
The strongest single test was my colleague's:
a prompt carrying ten different national identifiers went through a Protect rule with Sensitive Data set to Redact, the user got a pop-up reading "Your Prompt Was Redacted - 10 Violations found", and the AI's own reply echoed ten placeholders back. Another run with European identifiers redacted all ten with the correct type labels. Hashing behaved the same way, including on secrets inside an uploaded text file, which the browser extension opened and inspected.
The vendor's documentation says Redact partial keeps the first two and last two characters. In testing it did exactly that, and the AI's reply showed the same partially masked value.
Redaction is the setting I would default to
If I had one recommendation out of this whole evaluation, it is that redaction, not blocking, is the mode that survives contact with real users.
A block stops the leak and creates a support ticket.
The developer who just got a broken session is now the person arguing that the tool should be switched off, and in my experience they usually win that argument eventually. Redaction stops the leak and the person still gets their answer.
They often do not even notice. The secret never reaches the AI provider, the work carries on, and nobody is incentivised to find a way around it - which, given how many ways around it previous parts turned up, matters more than it sounds.
So the rest of this section is not an argument against redaction. It is the list of places where I would not trust it blind.
Where redaction let me down
Regex redaction only replaces the capture group. This is the one that would quietly embarrass you in front of a client.
A perfectly normal pattern like \b(WS|SRV|DC)-[A-Z]{2,4}-\d{2,4}\b turned SRV-NYC-014 into redacted-NYC-014.
The prefix was removed and the hostname was sent. The same thing happened to ticket IDs, where INC-20931 lost the INC and kept the number, and to internal domains, where vpn.corp lost the corp and kept the vpn. A pattern with no group in it, like ACME-\d{6}, replaced the whole match correctly.
So: write your patterns with non-capturing groups (?:...), or wrap the whole thing, and test every one of them after you save it.
Related: the console rejected an inline case-insensitive flag (?i) as an invalid pattern, so case has to be handled with explicit character classes.
Some values are only partly matched. A South Korean card number in the vendor's own example format was matched from the fifth digit onwards, leaving the first block of four sitting in the prompt in clear. Partial coverage of a value is arguably worse than none, because the console reports it as redacted.
The labels are frequently wrong. A US passport number and a US driver's licence were both redacted - and both tagged as a Vietnamese passport. A US bank account number came back as a Vietnamese driver's licence, and a US medical record number was caught only by coincidence, because it happened to match the pattern for a Japanese social insurance number.
The reason is loose patterns competing for the same shapes - a letter followed by seven or eight digits fits a Vietnamese passport as neatly as a US one, and twelve digits fits a Vietnamese ID. The protection worked. The compliance report built on top of those labels would be fiction, and so would the per-framework counts a client gets shown in a quarterly review.
The IT data types over-redact developer work. Switch them on and every URL, every UUID and every base64 string in a prompt gets replaced - in one test a plain https://www.google.com/ was redacted, trailing comma included. For an engineering team that turns the AI into a tool that cannot see the thing they are asking about. This is the same mechanism that broke clean prompts in the Bedrock test in previous part. Scope the IT types to non-engineering groups, or leave them off.
And a lot of what you want to stop has no detector at all. The catalogue is patterns and identifiers, so anything that is not pattern-shaped walks through:
Names, postal addresses, dates of birth and free-text medical information. In the ten-identifier test above, ten numbers were redacted and the name, street address and date of birth in the same sentence went through untouched, along with a written diagnosis. "John Smith, 12 Elm Street, born April 1985, type 2 diabetes" is exactly the sentence a client expects a PII tool to catch.
The vendor's documentation does claim names and locations are detected; our test says otherwise, and that is a question I would put in writing before a healthcare or HR client signs anything.
US healthcare identifiers. The PHI framework carries eight non-US identifiers and no US ones - no medical record number, no NPI, no health plan member ID. For a US healthcare client, the built-in PHI coverage is close to nothing.
Whole countries. There are no Pakistani types at all and no generic national-ID fallback, so a CNIC was sent in clear in the same prompt where ten other national IDs were redacted. Worth checking the catalogue against wherever your client's staff and customers actually are.
Source code. There is no code detector for employee traffic. The leak everybody cites when they buy one of these products is source code pasted into a chatbot, and that specific thing is not what this catches.
Passwords written as English. password is Hellowtyb was neither redacted nor logged. A more complex one in a fuller sentence was caught by the Generic Password detector, so it appears to key off complexity and key-value shape. Plain-prose credentials are unreliable.
The workaround for every line above is the same, and my colleague proved it out:
A regex or a natural-language guardrail per data type you care about. Both worked, including for identifiers the catalogue has no concept of. Budget time for it - this is configuration work at onboarding, not a switch.
The three protections that judge instead of matching
Secrets, Sensitive Data and Regex all come down to patterns. The other three ask a model what the prompt means, and they behave differently enough to be worth their own section.
Topics can be blocked or monitored-only, and the thing to understand is that they classify what the user is *asking about*, not what is in the prompt. A topic set up for company financial data did not stop a prompt full of quarterly revenue and margin figures, because the question itself was not a finance question. Topics work well when the name is short and concrete - "investment advice" blocked direct, indirect and crypto-flavoured questions cleanly while leaving general finance knowledge alone - and badly when it is vague. Use them to stop a kind of conversation, not to protect a kind of data.
Harmful Content has eight categories and three strictness levels, and the level matters more than the categories. A request to write a phishing e-mail was blocked at More Restrictive and at Balanced, and allowed at Less Restrictive. More Restrictive also blocked ordinary business language - "the competitor is killing us on price" was refused. Balanced was the only setting I would put in front of users. One annoyance for the SOC: the violation is logged as a binary safe/unsafe verdict rather than the category that fired, so the console tells you something was blocked but not what kind of thing it was.
Natural Language Guardrails are the most capable control in the policy, and the one that quietly fills the gaps in everything above. You write the rule in plain English, up to 5,000 characters, and the console turns it into an enforced guardrail. This matters because there is no jailbreak or prompt-injection detector and no source-code detector for employee traffic - a guardrail is the stand-in for both. One combined guardrail my colleague wrote blocked personal details, client-confidential incident details, patient health information, a password written in a sentence and jailbreak attempts, while still allowing the near-identical training questions ("explain how prompt injection attacks work") that a security team actually asks. The cost is one combined guardrail per policy, and every violation logs as "Content violates company policy" with no indication which of your own rules fired. Write them numbered, and keep your own key.
One more thing that is easy to miss, and visible in the policy screenshot above: none of these three apply to code assistants by default. The Developers policy ships with Regex and Secrets only. Topics, Harmful Content, Sensitive Data and guardrails have to be switched on there separately, and if you configured them on the Employees policy and assumed developer traffic was covered, it is not.
The strictest action wins, quietly
This one cost an afternoon.
Several data types exist in both the Secrets list and the Sensitive Data list - card numbers, SSNs, IBANs, e-mail addresses, IP addresses, AWS ARNs. When both detectors fire on the same value, the strictest action wins.
So a policy with Sensitive Data set to Redact and Secrets set to Block, used on a prompt full of card numbers, does not redact anything. The whole prompt is blocked, the console records the action as Blocked, and the carefully configured redaction never runs.
Four values produced six findings across the two detectors, and the hardest of them decided the outcome.
If you want "redact PII, block secrets", you have to check that none of the PII types you care about are also sitting in the Secrets list with Block on them. There is no warning in the console that two detectors are fighting over the same value.
Redaction protects the AI provider, not your console
Worth being precise about, because it is the finding with the biggest compliance consequence.
When Redact partial, Redact all or Hash modifies a secret before it reaches the AI, the Activity Monitor stores the original. The AI vendor never saw the key. The console did, in clear, for the whole retention period, readable by every administrator with portal access. The event is tagged as modified, the prompt field holds the real thing.
There is a setting that fixes it, and it works - that is a upcoming conversation along with retention, SIEM forwarding and what a blocked prompt leaves behind.
For now: if you demo this to a client with redaction switched on and tell them the secret is gone, be sure you know which copy you mean.
When Protect breaks the thing it is protecting
Four failure shapes, all worth knowing before a rollout.
Signed API requests. Covered in Previous part and the reason that section pointed here: the request is signed before it leaves the tool, Protect edits the body to redact the secret, and the signature no longer matches. The cloud provider rejects the whole call with a signature error. For a signed API, Detect is the only mode that leaves the tool working. Visibility or function, pick one.
The wrong policy on the wrong traffic. Pointing the Employees policy at developer traffic broke prompts that contained no secret at all, because the IT data types were redacting ARNs and identifiers out of ordinary context. With the Developers policy attached, only prompts that genuinely carried a secret failed.
Block on a code assistant. My colleague tested Protect with Block on an AI coding assistant and the blocked request did not produce a policy message - the assistant's session crashed. From the developer's seat that is not "your company stopped this", it is "this tool is broken". Redact rather than Block for code assistants, unless you enjoy that ticket.
Noise from the application's own context. Inspection happens on the whole request, not just the words the person typed, and a desktop assistant's request carries its system prompt, its tool definitions and whatever files it has open - in one capture, well over two hundred thousand characters. Anything in there that looks like a detectable value raises a violation on a prompt the user considers clean, and a second alert often follows from the app's own title-generation call. Before anyone tunes detectors in anger, check whether the finding came from the human or from the tool.
Block means four different things
Block is the mode people assume is simplest. In practice the user experience depends entirely on where the block happens.
A whole application blocked by rule is the clean one. A proper block page in the browser, and on the command line a flat Forbidden: Blocked by Prompt Security. One rule naming a single AI site denied it in both Chrome and Edge and logged the attempt, and it ignores the attached policy entirely - the app is simply shut, whatever the detectors say. It is the mode I would use for an AI tool a client has decided is not allowed.
A prompt blocked on content replaces the AI's answer with a message you can write yourself, the default being "Blocked due to policy violations". It is the strongest part of the product on the detection side: secrets inside code snippets, a .env file with five different secrets in it, cloud and AI provider keys, and personal data like SSNs, cards, IBANs and e-mail addresses were all stopped with a pop-up listing the violations and an event in the console. The custom text, logo and policy link are all configurable - Part 2 covered those screens.
A file or image blocked falls back to a generic message that reuses the blocked-site text and does not say what was found in the file. The user has no idea what to fix.
A code assistant blocked crashes, as above.
And one genuinely odd detail: in a browser test, the block dialog listed the violation by showing the full secret back on screen. The product stopped the key from reaching the AI and then displayed it, in clear, in a pop-up - on a screen that might be shared, projected or recorded. It is a low-severity finding and an easy fix, but it is the sort of thing a sharp-eyed client will spot in a demo.
There is no "warn me and let me through"
A violating prompt is allowed, modified, or stopped. There is no option for the middle ground that most DLP products have grown into: warn the user, ask them to type a business justification, let them proceed, and log the override.
The only warning that exists is the first-visit page for a monitored AI site, and the violations pop-up, which is informational. A per-site employee bypass setting does exist in the console - we enabled it and no bypass option ever appeared for the user, which I covered in Previous part and is still an open question with the vendor.
That matters for rollout sequencing. Without a soft-enforcement step, the path from Detect to Protect is a cliff, and the day you step off it is the day your support queue finds out.
Don't Track, and how a mode change actually lands
Don't Track deserves its own warning line. It is not a lighter mode - it is off. No inspection, no logging, no event, nothing in the console to show that an application is unmonitored. It is the right answer for an approved internal tool you have deliberately decided not to watch, and it is also the quietest way for someone with console access to create a blind spot. Audit it.
It has one legitimate use that is easy to miss, though. An app-specific Don't Track rule overrides the locked code-assistant rule, which is otherwise the only way to stop that rule archiving the full text of every developer prompt. So the same setting is both the privacy fix for the problem in Previous part and the cleanest way for an insider to go dark. Whichever you are using it for, it belongs on a list someone reviews.
And whichever mode you choose, it is not live when you click Save.
The browser extension picked up changes in roughly five minutes in our testing, and a guardrail change took about ten. The endpoint agent caches one decision per destination for ten to fourteen minutes, so it keeps enforcing the old rule until the next check-in or a service restart. That cache is per host rather than per feature, so the chat and code sides of one desktop assistant can share a single decision, and whichever one you use first after a restart may settle it for both. During an incident, "I've changed the rule" is not the same as "it is enforced". During testing, it is the single easiest way to convince yourself a setting does not work when it has simply not arrived yet.
What I would actually configure
Start in Detect, but say out loud that it protects nothing. Two weeks of visibility, then move.
Default to Redact, not Block, for everything except applications you have decided to ban outright. It is the only setting that stops the leak without creating pressure to remove the tool.
Use Detect for signed API traffic. Redaction breaks the signature, and a broken build pipeline is a worse outcome than a logged secret.
Never put Block on a code assistant unless you have warned the developers that the session will die rather than explain itself.
Check the Secrets and Sensitive Data lists for overlap before promising anyone that PII will be redacted. The strictest action wins and nothing warns you.
Write every regex without capture groups, and test each one by sending the value and reading what the model actually received.
Scope the IT data types away from engineers, or accept that URLs, UUIDs and base64 will be stripped out of their prompts.
Cover names, addresses, dates of birth, source code, US health identifiers and anything country-specific with a guardrail or a regex. The built-in catalogue is identifiers, and everything written as prose walks through it.
Switch the protections on in the Developers policy too. It ships with Secrets and Regex only, so anything you configured for employees does not reach code assistants.
Leave Harmful Content on Balanced, and treat the Allowed-names list as a change-controlled exception - it overrules every detector above it.
Treat AI responses as uninspected, and say so in the design document rather than letting someone assume both directions are covered.
- written from hands-on testing, By Iqra Shafi, Dean
------------------------------------------Cyberengage---------------------------------------------------
Comments