SentinelOne Prompt Security: The Endpoint Agent
Complete series:
https://www.cyberengage.org/courses-1/sentinelone-prompt-security
The browser extension in Previous part only sees browser tabs.
Everything else people use AI for — the Claude and ChatGPT desktop apps, Copilot inside VS Code, Claude Code and other command-line assistants talking straight to a model API — is the agent’s job.
The short version: the agent is a man-in-the-middle proxy on the laptop, and when it is in the path it works well. The interesting part is how often it is not in the path. A new terminal window, a Linux subsystem, a stopped service, an attached file — each of those was a hole, and none of them showed up in the console as a gap.
What’s actually in the package
The console gives you a zip per platform. I read it before running it.
The agent download page: Mac Apple silicon, Mac Intel or Windows, an Intune or SCCM package, an upstream proxy option, and the agent key underneath
Inside the Windows one: an MSI signed by SentinelOne, a tenant root CA certificate, and an install.cmd wrapper. The wrapper writes your agent key into a plain text file in C:\Windows\Temp, then runs the MSI silently and picks the key back up from there. It works, but the key sits on disk in clear in the meantime, in a directory every local account can read.
Two more things worth knowing before deployment day:
- Only Intune and SCCM packages are offered. If your MDM is something else, you are scripting it yourself.
- A colleague hit Smart App Control blocking an unsigned file inside the agent. The symptom is worth recognising: no agent process, the local proxy port never opens, and a code-integrity event repeating every thirty seconds or so. It only started working once Smart App Control was switched off. On a locked-down Windows build, test the package against your real app-control policy before you push it.
How it intercepts your traffic
This is the part I would want to understand before letting it near a fleet, and the console is honest about it once you know where to look.
Proxy configuration: a PAC file for desktop AI apps, environment variables for CLI coding assistants — and agent versions pushed from the console
There are two mechanisms, and the console names them plainly:
- A system PAC file, for desktop AI applications.
- Proxy environment variables, for command-line coding assistants.
Both switches are tenant-wide. There is no per-group or per-device version of them, so a client with an unusual network, or one department that cannot take a PAC file, is an all-or-nothing decision for the whole tenant.
There is an upstream proxy option in the package for environments that already route through one, which helps, but it is chosen at download time rather than managed per machine. For anyone thinking about running this across several clients from one console, this is one of the settings to ask about early.
Underneath, the agent runs a local mitmproxy listening on 127.0.0.1:3636, with a WinDivert driver to pull traffic into it transparently, and it uses that tenant root CA to re-sign the TLS it opens. So every prompt your people send to an AI service is decrypted on their laptop by software you installed. That is not a criticism — it is the only way to read a CLI tool’s HTTPS traffic — but it is a sentence that belongs in your rollout note, and in some countries in a works-council conversation, rather than being discovered later.
Reading the agent’s own configuration, one line stood out: upstream certificate verification is switched off. It validates nothing on the far side of its own connection, which is a strange default for a product whose entire job is to sit in the middle of other people’s TLS. I would want an answer from the vendor on that before a fleet rollout.
What it changed on my laptop
I snapshotted the machine before and after, which I would recommend to anyone evaluating this. The install set a machine-level proxy environment variable, a PAC URL, a certificate bundle variable for Node-based tools, installed the root CA into both the machine and the user store, added a service and a driver, created a Credential Manager entry, and edited two editor and assistant configuration files to point at the local proxy.
It also decides its own version. I installed the build I had downloaded and the agent promptly downgraded itself to the version the console was pinned to; it came back up to the newer one only after I pushed the update from the console and restarted the service.
Agent versions live in the console, not in your package.
Who the console thinks you are
On the agent, identity is set at install time. The wrapper looks for a username file containing a USER_EMAIL value, and if it is not there, the console shows a Windows account name instead of a person.
That is not cosmetic. I spent a while writing a rule scoped to one e-mail address and watching it do nothing at all. The rule was fine; the events simply did not carry an address to match on, so they fell through to the default rule.
If you plan to write per-user or per-team rules, set attribution at install time or your rules are decoration.
The locked rule nobody mentions
Here is the trap that matters most on the agent side, and it took me two sessions to see it.
A rule for “All applications” never touches code assistants:
Not Claude Code, not Copilot in VS Code, not a CLI tool talking to a model API. They are governed by a separate locked rule for AI code assistants, which you cannot delete or re-target — you can only change its mode and its advanced settings.
Out of the box that locked rule is set to Detect (btw you can change to Protect), with the Developers policy, and with log all interactions switched on.
Put those two facts together and the result is uncomfortable.
Everything a developer sends through a coding assistant is inspected in watch-only mode, so nothing is stopped — and the full prompt text of every one of those requests is stored in the console.
I only noticed because I exported the activity log.
One afternoon of ordinary work had been captured in full: internal resource identifiers, customer e-mail addresses that happened to be in a file I was working on, and a temporary cloud session token that was in the shell environment.
All in clear text, in a console every tenant administrator can read. Nothing was blocked, because Detect blocks nothing — it had all simply been written down.
The user, meanwhile, sees nothing. The violations pop-up was switched on in our tenant and never once appeared for an agent event — the browser extension pops up, the agent stays silent. So in Detect, on the agent, nobody is warned and nobody is stopped; the prompt is simply filed.
If you deploy the agent, deal with that rule on day one. Either turn its logging down to violations only, or accept that you have built a searchable archive of your developers’ work, and treat the console as a system holding client data.
Agent settings: notification frequency, header validation, request timeout, custom inspection URLs — and Agent Hardening, which is macOS only
What actually worked
With an app-specific rule in Protect mode pointing at the Developers policy, the agent did its job properly:
- Claude desktop app: a fake AWS key was replaced with a placeholder before it left the laptop, in both the chat and the code side of the app, and the app carried on answering normally.
- Block mode: a clean, unambiguous refusal — “Forbidden: Blocked by Prompt Security” — for the whole application rather than per prompt.
- Don’t Track: exactly what it says. Nothing inspected, nothing logged.
- OpenCode talking to a model on AWS Bedrock was covered and logged, which surprised me more than it should have.
Redaction is genuinely the useful mode here.
The assistant still works, the developer still gets an answer, and the secret never leaves. That is a better outcome than a block for almost everyone.
Nor did it feel slow. Nobody noticed a lag in the desktop apps, in Copilot inside the editor, or on the command line with everything routed through a local proxy — and a man-in-the-middle on every AI request is exactly where you would expect to feel one.
We didn’t time it formally; the vendor’s claim is tens of milliseconds.
What it broke
Then I pointed Protect at a CLI tool talking to AWS Bedrock, and it stopped working with a signature error.
Get Dean’s stories in your inbox
Join Medium for free to get updates from this writer.
The cause is structural rather than a bug: the request is signed before it leaves the tool, and the agent then modifies the body to redact the secret. The signature no longer matches the body, so the cloud provider rejects the whole request. With the Employees policy attached it was worse — ordinary prompts broke too, because the policy’s IT data types redact things like resource identifiers that appear in perfectly normal context. With the Developers policy, only prompts that genuinely contained a secret broke.
So for a signed API like that one, Detect is the only mode that doesn’t break the tool, which is an unhappy trade: visibility or function, pick one. I go into this properly in upcoming parts , because it changes how you choose a mode.
A related one from my colleague: with a code assistant in Protect and the action set to Block, secrets are stopped, but the assistant’s session crashes instead of showing a block message. The user sees a broken tool, not a policy.
Files: the agent’s blind spot
This is the single biggest difference between the two halves of the product, and it is worth being blunt about.
Attached files are not inspected by the agent. In testing, text, image and Word files carrying secrets were attached in the Claude desktop chat and in the Copilot desktop app, and every one went through — with no violation, and nothing logged at all. The same secrets pasted as text into the same app were caught and blocked.
There is one exception: the code side of the Claude desktop app did block the same file, under the Developers policy.
This is by design. The vendor’s documentation puts file inspection in the browser extension, which Browser extension part covers — including the per-rule switch that decides whether files get read at all, and the fact that it reads text inside images.
The practical consequence: if a desktop AI app can accept attachments, that is an unwatched channel on a machine that has your DLP agent installed. Prefer the browser version of those apps, or block the desktop ones, or accept the gap knowingly.
It only changes its mind every ten minutes
The agent caches one decision per destination. When I changed a rule in the console, the agent carried on applying the old one until its next check-in — roughly ten to fourteen minutes — or until I restarted the service.
That matters in two ways. During an incident, “I’ve changed the rule” does not mean “it is enforced”. And during testing, it is the easiest way in the world to convince yourself a setting does not work when it simply has not arrived yet. Restart the service before you conclude anything.
Getting around it
I tested this as a nuisance user would, and the results were sobering.
- Open a new terminal. The proxy variables are set at machine level, but a shell that does not pick them up sends traffic straight out. I hit this three times by accident before I started doing it on purpose — a fresh window, the assistant working normally, and nothing in the console at all.
- Unset the proxy variable. One command, no admin rights needed, and the agent never sees the request.
- Read the key. The agent’s key is readable by a normal local account.
- Stop the service. A normal user cannot, which is good. A local administrator can, nothing restarts it, and the console shows no alert. After an admin stop, the PAC-based desktop apps failed open and carried on talking to the AI unwatched, while the CLI tools failed closed and simply broke — two opposite behaviours from one stopped service.
- The reason is sitting in the PAC file itself: it hands back the local proxy *and* DIRECT as a fallback, so when the proxy isn’t there the browser-style clients just go straight out. The command-line tools have no such fallback, so they error instead.
- Edit its configuration files. This one it handles: the files it writes are repaired within seconds.
A colleague found the same pattern from the other direction — when the agent is not listening, the proxy setting falls back to a direct connection, so the traffic flows and nothing is recorded. That needs a retest, but it matches everything I saw.
Two console-side facts make all of this worse than it needs to be:
- Agent Hardening exists, but it is macOS only There is no equivalent tamper protection setting for Windows. The one adjacent control, a header validation option described as hardening the agent, was also switched off by default, as was the identity platform option — that one greyed out entirely.
- There is no device inventory. Not in the console, and not in the documented API. There is no screen that says “these 200 laptops have a healthy agent and these 6 do not”. An agent that was stopped, uninstalled or never installed looks exactly like a user who did not use AI today.
If you deploy this, your own EDR has to answer the question the product cannot: is the service running, and is it still the version you expect?
WSL walks straight past it
The one I keep coming back to, because it is invisible and it is common.
Windows Subsystem for Linux is a separate network namespace. The agent sets a PAC-style variable inside WSL but not the proxy environment variables, so a tool running there — Claude Code, for example — connects directly to the model API and is never inspected.
Not blocked, not redacted, not logged.
I confirmed it the lazy way and then the thorough way: it was unmonitored after install, and still unmonitored after a full shutdown and reboot, with the Windows side of the agent coming back perfectly healthy. The Windows half survives reboots. The Linux half is not there to begin with.
Every developer I know does their real work in WSL.
If that is true of your estate, the agent covers your desktop chat apps and misses the environment where the secrets actually live.
There is a vendor procedure for closing it, and it is worth knowing before you promise anyone a date: the document has a broken link, one step overwrites the variable the previous step just set, and it never mentions that the certificate bundle variable has to be set on the Windows side first. A colleague walked through it line by line and reached the same conclusion I did. Until I have it working end to end on a real machine,
I would treat WSL — and Docker, and any other subsystem — as out of scope, and say so out loud rather than let someone assume coverage.
What it watches, and what it doesn’t
The agent works from a built-in list of AI applications and addresses. The list is broader than the documentation suggests — pulling it from the API showed entries the docs never mention, including newer terminals and AI browsers, and the raw model APIs themselves: OpenAI, Azure OpenAI, Bedrock and Vertex. That last group is the valuable part, because it is what catches a script or an assistant talking straight to a model endpoint rather than through a branded app.
The agent’s own discovery also populated the app inventory by itself, desktop apps and cloud model APIs included.
The limits are the other side of the same design:
- You cannot add a new application. “Custom Inspection URLs” lets you add your own addresses for an application the agent already supports — a self-hosted GitLab, an internal AI gateway — but it cannot teach it an app that is not on the list. Missing applications have to be requested from the vendor.
- Local models were not on the list. Ollama and LM Studio style local LLMs were not covered when we checked. A model running on the laptop never touches the network the agent is watching.
- Some patterns reach beyond AI. A colleague found the agent’s address patterns also catching things that are not AI traffic at all, such as page saves in a note-taking app and bot traffic from a chat client. Worth knowing before someone asks why their non-AI tool appears in an AI monitoring console.
- Home-made tooling is a coin toss. Anything a team has wrapped themselves — a script that calls a model API, an internal CLI, a scheduled job — is covered only if it inherits the proxy settings *and* its destination is on the list. Neither of us tested that properly, and it is the first thing I would check at a client with its own tooling.
And the inverse of Part of Browser extension: without the extension, the agent still blocks and logs some web AI by itself, but only for the sites on that built-in list. In testing it stopped the three big ones and let a fourth through. The two halves cover for each other, and neither is complete alone.
Taking it off again
The requirement I set at the start of this whole evaluation was that anything we install has to come off cleanly, so I snapshotted the machine, uninstalled, and diffed.
The uninstall was clean. The proxy variables, the PAC URL, the certificate bundle variable, the root CA in both stores, the service, the driver, the program folders, the Credential Manager entry and the editor configuration lines were all gone. What stayed behind was trivial: a small log file under the user profile, and one assistant configuration file left as an empty object rather than restored to its original content.
That is a better result than a lot of endpoint software manages. Credit where it is due.
What I would actually deploy
If I were rolling the agent out to a client tomorrow:
- Fix the locked code-assistant rule first. Decide its logging deliberately. “Log all interactions” on a Detect rule is an archive of your developers’ prompts, in clear, readable by every console admin.
- Set user attribution at install time, or per-user and per-team rules will silently never match.
- Use Detect for signed API traffic — redaction breaks the signature — and Protect where the app can take a modified body, like the desktop chat apps.
- Treat desktop file attachments as uncovered. Prefer browser versions of AI apps, or block the desktop ones.
- Assume WSL and any other subsystem are uncovered until you have proven otherwise on a real machine.
- Monitor the agent from your EDR: service running, version as expected, local proxy port listening. The console will not tell you, and there is no device inventory to check.
- Restrict local admin. A local admin can stop the agent, and desktop apps then fail open with no alert anywhere.
- Test the package against your app-control policy before deployment day, and treat the installer as a secret because the key is written in clear during install.
One open avenue I have not tested and would want to before writing the agent off for desktop files: the vendor offers provider-side integrations that inspect prompts at the AI service rather than on the laptop. Whether those cover desktop applications or attachments is an open question, and it is the first one I would put to them.
The honest summary:
in the path, the agent is good — redaction on a desktop assistant is the most useful thing this product does. Out of the path, it is silent, and the product gives you no way to tell the difference. That is the gap to close with your own tooling, and the question to put to the vendor.
- written from hands-on testing, By Iqra Shafi, Dean
Iqra : https://www.linkedin.com/in/iqrabintishafi/
Dean: https://www.linkedin.com/in/akash-patel-097610202/
— — — — — — — — — — — — — — — — — — — — — Cyberengage — — — — — — — — — — — — — — — — — — — — — — — — — -
