SentinelOne Prompt Security: The Browser Extension
Most people still use AI in a browser tab. ChatGPT, Claude, Gemini, the Copilot sidebar, the "Help me write" button in Gmail - it all lives in the browser. So the extension is the half of Prompt Security that will see most of the action, and it is where I started.
The short version:
installing it by hand is fine for a demo and useless as a control. Pushing it by policy fixes most of that, but even then private windows stay open unless you add browser policies the vendor package does not set for you. The rest of this part is how I got there.
Installing it by hand
The console lists 17 browsers you can install it into manually, from Chrome and Edge down to Arc, Island and Dia. I started with Edge, from the Edge Add-ons store. Version 7.1.62, Manifest V3, under a megabyte.
Manual Installation:
Using Policy:
The Deployment page: 17 browsers, each with its own store link, and the keys underneath
Two small things worth knowing before you go further.
The Edge ID is not the Chrome ID. The console's Google Workspace page gives you the Chrome Web Store ID (iidnan****cecmgpcaf**************. The Edge store copy is a different ID (pbb******ofiifphflkh************). If you force-install in Edge, use the Edge ID - or the Chrome ID together with the Chrome store update URL. Mix them up and nothing installs.
The Google Workspace instructions hand you the Chrome Web Store ID - which is not the ID Edge uses
It asks for a lot - which is normal for DLP, but say so. Host access to every site, tabs, scripting, downloads, and your signed-in email address. It has to read the page to do its job. Your users should still hear that from you before they see it in a permission prompt.
What the extension asks for: every site you visit, tabs, scripting, downloads - and your e-mail address
It does nothing until someone configures it
After install there is no setup screen. The icon is not even pinned to the toolbar. You have to open the extension popup yourself and enter two things: the API domain and the extension key from the console.
The whole configuration screen: an API domain, a key, two log buttons and the e-mail it thinks you are
Until then it protects nothing - but it already talks home. The extension log showed a heartbeat going out about two minutes after install, before I had entered any key.
Small trap that cost me some time: there are three different keys in this product. A management API key (starts with psk_) for the REST API, an extension key, and a separate agent key. The extension and agent keys both look like plain UUIDs.
Put the wrong one in the wrong place and you get a 401 with no hint as to why.
Who it thinks you are
Identity is not one thing. Where the user is signed in to the AI site itself, that login address is what the console shows - so a personal ChatGPT account puts a personal email address into your tenant, on a work laptop, and that event will not match any rule you wrote for the person's company address.
Where there is no such login, it falls back to the company email or the Windows username, and that fallback is what the MDM attribution setting fills in.
A hand-installed extension may report no address at all, in which case rules written for named users silently never match and everything lands on the Default rule instead.
The practical upshot: get attribution set before you write user-specific rules, and if you are a provider looking at a client's console, remember whose email addresses you are looking at - and blank them out of any screenshot you share.
The first test surprised me
I pasted my fake AWS key into ChatGPT and got "Access Denied: Paste content is blocked by your administrator". Fine - except my user was meant to be on a Detect-only rule. Then I pasted the word "hello" and got the same block.
Any paste into ChatGPT, fake key or the word "hello", came back as Access Denied
The cause was the default rule. Under its Advanced settings it had "Block content paste" and "Block file upload" switched on. Nothing on the main rule screen tells you that - the Advanced column only shows a small "Data protection 2" badge, which is where I should have looked (Part 2 has the full tour of that screen). And the blocked pastes never showed up in the Activity Monitor at all - so the SOC would have no record that anyone tried.
The rule list: the default rule at priority 4 is Detect, but its Advanced column carries the paste and upload blocks
When I typed the key instead of pasting it, I got the behaviour I expected for Detect mode: a pop-up warning, an event in the console (Secrets / AWS credentials, rule 4, Default Employees policy, app "ChatGPT (Personal)", inspection took 12 ms) - and the full key went to ChatGPT anyway. Detect warns. It does not stop anything. More on that in Next Article
Typed, not pasted: a warning pop-up, an event in the console - and the key still goes through
Files take a different path
The prompt box is only half of it. People drag documents into a chat as readily as they paste text, and a file goes through the extension differently.
Two switches under a rule's Advanced settings decide what happens to it.
Block file upload stops the file leaving at all.
In Protect mode the upload is stopped with a violation pop-up and the event is logged.
Inspect file upload to AI apps decides whether the extension reads what is inside the file. It is set per rule, and on the Default rule it is off.
*(Important) That second switch (Inspect file upload ) is the one to watch, because the difference is total.
With it on, a text file carrying a test card number was uploaded to ChatGPT, inspected, and raised a violation. With it off, the same upload landing on the Default rule was not inspected at all: the console logged the file name and "File inspect: false", no violation, the whole conversation readable - and the AI read the card number back in its reply.
Same tenant, same file, same product. A different rule.
And the Default rule is where personal accounts and anyone you forgot to write a rule for end up.
With inspection on, it goes further than reading plain text:
Redaction works inside files. With Secrets set to Hash, the secrets inside an uploaded text file were hashed before the file reached the AI, rather than the upload being blocked outright.
It reads text inside images. A screenshot of an API key, a screenshot of card and ID data, and the same image embedded inside a Word document were all blocked. Clean images and a clean Word file went through untouched.
Downloads are a third switch. With "Block file download" on, a CSV the AI generated was blocked with a pop-up. An image the AI generated was not.
Two limits are worth knowing before you promise anyone file coverage:
File inspection and reply logging happen only in the browser extension, and only for a fixed list of apps - ChatGPT, Microsoft Copilot, Gemini, Claude, Perplexity, Mistral, Grok, DeepSeek, Jira Rovo, Google AI Mode, Meta AI and NotebookLM on the vendor's October 2026 list. Any other AI site gets prompt checks only, including sites you add yourself as custom apps.
The block message doesn't match the block. A blocked text file gets a proper "Your File Was Blocked" pop-up listing how many violations were found. A blocked image or Word file gets a generic "File upload blocked" message that reuses the blocked-site text and suggests the user go and use ChatGPT instead - while they are sitting on ChatGPT.
I had this wrong at first. I uploaded a file under a rule with inspection off, saw nothing in the console, and wrote "the extension doesn't scan uploaded files" down as a product gap.
My colleague ran the same tests with the switch on and got the opposite result. The capability is there. It is off until someone turns it on, rule by rule - which is a documentation problem rather than a detection one, and the kind of thing that quietly survives a proof of concept.
Taking it off again
Removing a manually installed extension is one click on the Remove button. Any user can do it, and the console raises no alert. The "Clear Logs" button in the popup only clears the local log; the event already in the console stays.
Three easy ways around a manual install
With the extension installed and working in one Edge profile, I tried the obvious things a user might do - on purpose or just by accident.
Use another browser. Brave had no extension. The fake key went straight to ChatGPT. Nothing in the console.
Use another profile. A manual install only lives in the profile you installed it in. A second profile in the same browser has no extension and is not watched at all.
Open a private window. In Edge, "Allow in InPrivate" is off by default, so InPrivate is unwatched until the user turns it on. Firefox asks at install time, so it depends on what the user ticked.
A colleague running a parallel evaluation found one more: Guest mode. The extension does not run there either.
None of this is a clever bypass. It is just how browser extensions work. But it means a manual install is a demo, not a control.
Force-installing it by policy
In a real company you would push the extension with Intune, GPO or similar. I did the same thing by writing the policy keys into the registry myself, so I could see each step.
Step 1 - force-install only. I added the extension to Edge's ExtensionInstallForcelist. Edge installed it, showed "managed by your organization" and took away the Remove button. Locked down, nice.
Then I pasted the fake key and it went straight through. A force-installed copy is a fresh copy, and a fresh copy has no API domain and no key.
***Forcing the install without pushing the settings gives you an extension the user can't remove that also does nothing.
Step 2 - push the settings too. The extension reads its config from a second policy location (...\Edge\3rdparty\extensions\<id>\policy): apiDomain and apiKey. With both set, it worked straight away - pop-up on the key, paste blocked, nothing typed by the user.
A brand-new Edge profile: the extension is already there, already configured, and already blocking
It also fixed the profile gap. I created a second Edge profile and the extension was already there, configured, without anyone touching it.
A colleague confirmed a normal user can't switch off, remove or inspect a force-installed copy, even with Developer mode on.
A few things to be aware of:
The key sits in plain text under HKLM\SOFTWARE\Policies. Any local user can read it.
One key per machine. A device belongs to one tenant. Fine for most companies, worth knowing if you are a provider.
Private windows are still open. With force-install and pushed config, an InPrivate window still let the key through unchecked. More on fixing that below.
Cleanup was clean. When I removed the policy values, Edge uninstalled the extension by itself.
What's in the vendor's MDM package
The console offers a ready-made Windows package for Intune ("Multi Browsers"). I downloaded it and read it before running anything. It is two PowerShell scripts: one to install, one to change settings later (for example to rotate the key).
The ready-made "Multi Browsers" package for Intune, next to the per-browser instructions
What it does well:
It force-installs and pushes the config in one go, so you don't hit the "locked but useless" problem.
It merges into existing browser extension policies instead of overwriting them.
It covers Chrome, Edge, Brave, Vivaldi, Chromium and a list of newer Chromium browsers (Whale, Comet, Dia, Atlas and others), plus Firefox.
It writes policy keys for every browser on its list, installed or not - so a browser someone installs next month picks it up automatically.
What I would change before using it:
The API key is typed in plain text at the top of both scripts. Treat the package itself as a secret. Don't email it around or leave it on a shared drive.
Opera isn't covered, and neither is any portable browser.
The user name it reports is the Windows username, not an email, unless you fill in the hook in the script yourself.
Nothing for private windows. Not one line.
No uninstall script came with the Intune package. Removing it means undoing every browser's policy by hand. A colleague who tested the separate removal script found it deletes the whole Firefox policy file rather than just its own entry, and uses the wrong path for Naver Whale, so the key stays in the registry there.
Closing the private-window gap
This is the bit I most wanted to get right, because "just open an incognito window" is the first thing anyone will try.
There are two ways to close it:
force the extension on in private windows, or switch private windows off. Not every browser lets you do the first.
Browser | Force the extension into private windows | Or switch private windows off | Tested? |
Edge | Yes - MandatoryExtensionsForInPrivateNavigation (Edge 139+) | InPrivateModeAvailability = 1 | Yes |
Firefox | Yes - ExtensionSettings with "private_browsing": true (Firefox 136+ / ESR 128.8+) | PrivateBrowsingModeAvailability = 1 | Yes |
Chrome | No on Windows - the matching policy is ChromeOS only for now | IncognitoModeAvailability = 1 | Docs only |
Brave, Vivaldi, Chromium | No | IncognitoModeAvailability = 1 under each browser's own policy key | Docs only |
Comet, Whale, Dia, Atlas, GenSpark, Sigma | Nothing documented | Unclear | No |
The two I tested behave differently, and it is worth knowing how.
Firefox actually forces the extension on. With private_browsing set, the toggle in about:addons is replaced with a locked "Requires access to private windows", and my fake key typed in a private window showed up in the console.
Edge doesn't force it on. It refuses to open an InPrivate window until the user allows the extension there. With the toggle off, InPrivate was blocked with an "organization" message. Toggle on, it opened and the key was logged. Toggle off again, blocked again.
Either way, there's no unwatched InPrivate. One catch: the new policy didn't apply until I reloaded policies and killed Edge's background process. (Microsoft also notes this policy doesn't apply to profiles signed in with a personal Microsoft account.)
For Chrome on Windows there is no way to force it into incognito today, so the only option is to switch incognito off. For Guest mode, switch that off too (BrowserGuestModeEnabled = 0 in Edge and Chrome).
When it can't reach home
One more finding from my colleague, and it's an important one. When the laptop can't reach the Prompt Security service, the extension lets everything through - and logs nothing. There is a "Fail Close" setting, and it was tested: prompts still went through, with no block and no record afterwards. The switch lives in Sensor Settings, under General Settings, and it ships on Fail Open.
Extension settings: Fail open/close set to Fail Open out of the box, next to the employee-bypass and non-work-profile options
(Important) So anyone who can break that connection - a hosts-file entry, a firewall rule, a flaky network - has an unwatched AI session, and you'll never see it in the console.
What I would actually deploy
If I were rolling this out to a client tomorrow:
Never rely on manual installs. Force-install by MDM and push the settings in the same step.
Add the private-window policies yourself - Edge and Firefox can force it, Chrome and the rest need incognito switched off. Switch off Guest mode too.
Deal with the browsers it doesn't cover. Opera, portable browsers and anything not on the list should be blocked by application control, or the extension is a speed bump.
Treat the install package as a secret, and write your own uninstall script before you need it.
Set the user name to the work email so alerts point to a person, not a Windows login.
Check the default rule's Advanced settings. That's where paste and upload blocking hide - and blocked pastes aren't logged.
**Watch connectivity to *.prompt.security** from your EDR or SIEM, because if it drops, the extension fails open without a word.
If you take one thing from this part: the extension is only as good as the policy that pushes it. A manual install shows you what the product can do. A proper MDM rollout with private-window policies is what actually covers your users.
- written from hands-on testing, By Iqra Shafi, Dean
------------------------------------------Cyberengage---------------------------------------------------
Comments