SentinelOne Prompt Security: How the Console Fits Together
Before I get into the browser extension and the agent, I want to walk through the console itself. Almost every result later in this series - a key that got redacted, a key that sailed straight through, a pop-up that never showed - comes back to how four screens in the console work together. If you understand those four, the rest of the series makes sense.
If you don't, half of it looks random.
It took me a good few days of testing to get this picture straight, mostly because the console splits one decision across several places. So this part is the map I wish I'd had on day one.
The four tabs, and how they connect
Everything for employee AI use lives under one area with four tabs:
Security Rules - who, which AI app, which platform, and what mode (watch, protect, block or ignore). The rule also picks which policy to use.
Policies - what to look for in a prompt (secrets, personal data, your own patterns, topics) and what to do when it's found (redact or block).
Sensor Settings - how the two pieces on the laptop behave: the browser extension and the endpoint agent.
User Education - what the employee actually sees: warning pages, block messages, pop-ups.
The way I explain it to people:
the rule decides if and how
the policy decides what
the sensor does the work
the user education does the talking.
A prompt comes in, the first rule that matches decides the mode and hands it to a policy, the policy's detectors look at the text, and the sensor carries out the result.
That split matters because a policy on its own does nothing. You can set "Block" on every detector in a policy, and if the rule that points to it is in Detect mode, nothing gets blocked. I fell for exactly that early on - the policy said block, the dashboard said 0% blocked, and it took a while to see why.
Security Rules
Each rule is one row with the same columns:
Priority - rules are checked top-down and the first match wins. Nothing after it is looked at.
Users - all users, named users (by e-mail), or groups once an identity provider is connected.
Applications - one or more specific AI apps, a category, "All applications", or "AI code assistants". Several big apps come in two flavours, for example "ChatGPT (Personal)" and "ChatGPT (Enterprise)", so you can treat a personal account differently from the company one. The same goes for Claude, Gemini, Copilot and Perplexity.
Platform - web (the browser extension) and/or desktop apps (the agent), with a count of how many desktop apps the rule covers.
Mode - what happens (below), plus the policy it uses.
Advanced - three drop-downs: Data protection, Logging and User education.
At the bottom sit two rules you can't move or delete. The Default rule (All users / All applications / Detect / Default Employees Policy) catches everyone who didn't match anything above it.
Just above it is a second locked rule for AI code assistants (All users / Detect / Default Developers Policy). Their users and apps fields carry a lock icon, so you can change the mode and the advanced settings but not who or what they apply to.
The four modes
Mode | What it does |
Detect | Inspects the prompt, logs violations, can show a pop-up - but lets the prompt through untouched |
Protect | Inspects and applies the policy's action: redact the sensitive part, or block the prompt |
Block | Blocks the app outright, without reading the content |
Don't Track | No inspection, no logging, for that user and app |
Detect is visibility only. The AI gets the data and will happily repeat it back. If you want something to actually stop, you need Protect (or Block).
What hides under "Advanced"
This is the part of the rule screen I'd tell everyone to open, because the main row doesn't show it:
Data protection - block content paste, block file upload, inspect uploaded files, block file download.
Logging - log all interactions, or log only violations. Logging of AI replies is also set here, per rule.
User education - whether to show the violations pop-up and the warning page for this rule.
My very first test hit this.
Pasting anything into ChatGPT - even the word "hello" - was blocked. The default rule had "Block content paste" and "Block file upload" switched on under Advanced, and the main row gave no hint of it. Worse, the blocked pastes never showed up in the activity log at all, so an admin would have no record that anyone tried.
Rule traps I hit
"All applications" doesn't include code assistants. A rule for "All applications" never touched Claude Code, Copilot in VS Code or OpenCode. Code assistants need a rule that names them, or they fall to the locked code-assistant rule.
Code-assistant rules only take the Developers policy. Point a rule that includes a code assistant at any other policy and you get a red (!) next to the priority, with the reason only in a tooltip: "This rule uses a policy that might slow down responses. Since this rule affects AI code assistants, please use an AI code assistant policy."
Rules for named users only work if the sensor knows who the user is. A rule for one e-mail address silently never matched, because the manually installed extension wasn't reporting an e-mail. The prompt fell to the Default rule instead. On the agent, the user is set at install time (a USER_EMAIL value); without it, the console only sees a Windows account name.
Changes aren't instant on the agent. The agent caches its decision per AI site. A rule change only took effect after the next check-in, roughly 10 to 14 minutes, or after restarting the agent service.
Personal accounts fall to the Default rule unless you write a rule for the "(Personal)" version of the app. A colleague tested this: a Block rule on "ChatGPT (Personal)" stopped a personal account while the company one kept working.
Policies
A policy is the list of things to look for and what to do with them. You manage them from the policy drop-down at the top of the Policies tab, through a "Manage Policies" window.
There are two kinds:
Employees policies - for AI in the browser and desktop chat apps. You can add as many as you like, rename them, duplicate them and delete them.
AI code assistants - there is exactly one, the Default Developers Policy. It can't be renamed, deleted or duplicated, and any new policy you create is always the Employees type.
What a policy can contain
Each section has its own on/off switch and applies to prompts. (Replies from the AI aren't scanned for employee use - by design, that's only done in the other product modules.)
Sensitive Data. Personal and regulated data, grouped by compliance framework: PCI, PII, GDPR, CCPA, PHI, COPPA, PDPA and IT. In my tenant that was 127 data types in total. You choose Block or Redact, and there's a switch to replace the value with realistic dummy data instead of a placeholder.
Below that you can add your own data types, "hidden terms" that always get redacted (say, an internal project name), and "allowed terms" the detector should ignore.
Secrets. API keys, tokens and credentials - 238 detectors when I tested, from AWS and GitHub to Slack, GitLab and private keys. The action is a drop-down: redact (all or partial) or block. You can open the detector list and switch individual ones off.
One thing I didn't expect: a brand-new policy starts with only 203 of the 238 secret detectors on. Among the ones switched off were both AWS Bedrock API key types. If you create a new policy and assume it has the same coverage as the default, check that list first.
Regex. Your own patterns - customer IDs, ticket numbers, internal host names. Block or Redact, with your own replacement text. Two quirks from testing: there's no case-insensitive flag, and if your pattern has a bracketed group, only that group gets redacted and the rest of the match goes through. A pattern without brackets replaces the whole match.
Topics. Two lists: topics to block, and topics to just monitor. You type the topic in plain words ("investment advice", "hiring questions") and it's classified by AI. A colleague found it accurate, but the wording of the topic matters.
Harmful Content. Categories such as hateful, harassment, self-harm and public harm, with three levels. "More restrictive" blocked normal business talk in testing; "less restrictive" missed phishing. "Balanced" was the usable one.
Natural Language Guardrails. Up to 5,000 characters describing in plain English what to block and what to allow ("block patient details, allow general medical questions"). This turned out to be one of the strongest features.
In a Iqra´s tests, a single guardrail caught things the fixed detectors missed: names with dates of birth, patient diagnoses, passwords written into a sentence, keys split across two lines, and jailbreak attempts - while still allowing general questions on the same subjects.
Changes can take a few minutes to apply.
What the two default policies actually check
Out of the box, the Default Employees Policy had Sensitive Data and Secrets switched on.
The Default Developers Policy had only Secrets switched on. So by default, code assistants are checked for keys and tokens, but not for personal data, not for your own patterns, topics or guardrails. If you want a developer pasting a customer list into Claude Code to be caught, you have to switch those sections on in the Developers policy yourself.
A few behaviours worth knowing
Block beats Redact. If two sections fire on the same prompt, the stricter action wins.
Some data types live in two sections (card numbers, SSNs, IBANs, e-mail and IP addresses appear in both Secrets and Sensitive Data), so both can fire on one value.
The IT data types are noisy for developers. They redact every URL, UUID and base64 string.
Redaction and signed API calls don't mix. More on this in a later part, but in short: when the agent redacted a key inside a request to AWS Bedrock, Bedrock rejected the request, because the request was signed before Prompt Security changed it. For Bedrock, Detect was the only mode that didn't break the tool.
Building policies per team
This is where the product gets genuinely useful, and why I wanted this part before the others. One policy for the whole company is either too loose for the finance team or too noisy for the developers.
The idea is simple: create a policy per team, then put a rule for that team above the Default rule.
Here's how I'd lay out a typical company. Only the first three existed in our tenant; the others are suggestions built from what the policy sections can do.
Policy | Who | What it focuses on | Rule mode |
Default Employees | Everyone (Default rule) | Secrets + core personal data, redact | Protect |
Default Developers | Developers' code assistants | Secrets, plus your internal-ID regex; consider Sensitive Data | Protect (Detect for Bedrock) |
Finance | Finance team | Cards, CVV, IBAN, bank details, SSN - block; topic "investment advice" | Protect |
HR | HR team | Personal data, salaries (custom data type), guardrail for names + dates of birth | Protect |
Healthcare / clinical | Clinical or support staff | PHI section, regex for record numbers, guardrail for patient details | Protect |
Legal | Legal team | Guardrail for "client-confidential" matters, hidden terms for case names | Protect |
Contractors | External staff | Only approved apps; everything else | Block |
How to build one:
Policies → Manage Policies → Add Policy (or Duplicate an existing Employees policy to start from its settings).
Switch on the sections you need, set each action, and check the secret detector count - remember new policies start at 203 of 238.
Add a Security Rule above the Default rule: the team's users or group, the apps, the platform, Protect, and your new policy.
Open Advanced on that rule and decide on paste, upload, logging and pop-ups.
Test with fake data, and check the event in the activity log to confirm which rule and policy actually matched.
The limits you'll run into:
Code assistants get one policy for everybody. Because code-assistant rules only accept the Default Developers Policy, you can't give the finance team's developers a stricter coding policy than everyone else's. The only thing that can differ per team is the mode (Detect, Protect, Block, Don't Track).
Groups need an identity provider. Rules can target Entra ID, Okta or Google groups, but only once that's connected. Ours wasn't, so the only option was listing people by e-mail.
The sensor has to know the user. A rule for the finance team only works if the extension reports the person's work e-mail (pushed by MDM) and the agent was installed with their e-mail. Otherwise their prompts quietly fall to the Default rule.
Sensor Settings
This tab controls the two pieces on the laptop. It has two sub-tabs.
Extension settings
Files and Content (Legacy) - the old switches for blocking uploads, downloads and pasting. Since extension 7.1.46 these live in each Security Rule's Advanced settings instead.
Log responses in top AI apps - stores the AI's replies for around a dozen big apps (ChatGPT, Copilot, Gemini, Claude, Perplexity and others).
ChatGPT-specific settings - block chat training, memory, developer mode, workspace agents, connectors, voice mode, chat sharing and custom GPTs; force temporary chats; restrict ChatGPT Teams invites. A colleague tested these on a personal ChatGPT account and only "Block chat training" worked - it switched training back off within seconds. The rest may only apply to enterprise accounts.
Fail Open / Fail Close - what the extension should do when it can't reach Prompt Security. In testing, prompts went through unchecked and unlogged with either setting.
Employee bypass inspection - lets employees skip inspection per app. We had it disabled.
Bypass inspection for non-work browser profiles and Exclude URLs - both create blind spots if you fill them in.
Autocomplete handling - "Silent protection" blocks without logging.
User attribution via MDM variables - lets your MDM tell the extension who the user is. You want this on.
Browser extension on/off - one switch that turns the extension off across the whole tenant.
Agent settings
Violations notification frequency - log every violation, or summarise per hour, day, week or two weeks.
Add header validation to harden the agent - off by default.
Request timeout - 5 or 10 seconds.
Custom inspection URLs - add your own address for an app the agent already supports (for example a self-hosted GitLab or an internal AI gateway). It can't add a brand-new app; missing apps have to be requested from support.
Agent Hardening Mode - a password needed to disable or uninstall the agent. It's marked macOS only. On Windows there was no tamper setting at all, which matches what I saw when an admin stopped the agent (a later part covers that).
Notice what's missing: there's no fail-open or fail-close setting for the agent, and there is no list of devices anywhere - no view of which laptops have the agent, which version, or whether it's running.
User Education
This is the bit your users actually see, so it's worth five minutes of your time.
Domain warning page - shown the first time someone opens a monitored AI tool. Ours said "Use AI Tools with Care" with a short reminder not to submit confidential data. It shows again after the browser is closed and reopened.
Blocked domain message - when the extension blocks a disallowed AI site.
Blocked AI component message - when an AI feature inside an otherwise allowed site is blocked.
Message for blocked prompts - the text the AI app returns instead of an answer. Default: "Blocked due to policy violations".
Violations awareness pop-up - the main switch for pop-ups across all Detect and Protect rules.
Branding and policy link - your logo and a link to your AI policy, added to every message.
Three things to check:
Change the AI policy link. Ours pointed at a vendor blog post, which is what every block message would have linked users to.
These settings are one per account. You can't have different wording for different teams, or for different clients if you're a provider.
Pop-ups are a browser thing. With the pop-up switch on, I never saw one in desktop apps or command-line tools - they have nowhere to show it. Those users only see the block message, if the app shows it at all.
How I'd set it up
If I were starting a tenant from scratch tomorrow:
Start in Detect for everyone and watch the activity log for a week or two. You'll learn which apps people really use.
Open the Default rule's Advanced settings and decide paste, upload and logging on purpose, not by default.
Make the Default rule a strict baseline, because personal accounts and anyone you forgot end up there.
Switch on more than Secrets in the Developers policy if you care about personal data in code assistants.
Add team policies (Finance, HR, and so on) with their own rules above the Default rule, and check new policies' detector counts.
Use a Natural Language Guardrail for the things fixed detectors miss.
Get user attribution right - MDM for the extension, user e-mail for the agent, and an identity provider if you want group rules.
Write your own user education text and policy link before you switch anything to Protect.
If you take one thing from this part: the rule picks the mode and the policy, and the mode wins. A perfectly tuned policy behind a Detect rule protects nothing.
- written from hands-on testing, By Iqra Shafi, Dean
------------------------------------------Cyberengage---------------------------------------------------
Comments