Keys and settings: how they reach each device

You create one sensor key in the Prism DLP console. Your device management tool carries it to every device inside managed settings, each sensor reads it from there, and nobody types anything on a device. There is no private key or certificate to make, sign or install.

This page explains how that works and how to check each part. The click-by-click steps live in the rollout guides: start here, the browser extension, the extension through Jamf Pro and the Mac agent through Jamf Pro.

What each device is given

Four settings, the same names for the browser extension and the Mac agent:

The key is what ties a device to your organisation. When a sensor sends something, Prism works out which organisation it belongs to from the key and nothing else, so a device holding your key reports into your console. That’s also why a key is something you make and keep yourself. You may see a key on Set up that you didn’t create, made when your organisation was set up for you. If you don’t have a copy of it, create your own and revoke that one once you’ve rolled yours out.

From the console to the device

1. You create the key on Set up. Under Sensor keys, type a label (for example “Sales laptops”), choose Sensor key: browsers and Macs and click Create key. You need the Owner or Admin role.

2. Prism shows it once. It appears under Key created with the note “Copy it now: Prism keeps only a hash, so it can’t be shown again.” Prism stores the start of the key (the column Key starts) and a SHA-256 hash of the whole key. When a sensor connects, Prism hashes the key it sends and looks for a matching key that hasn’t been revoked. If you lose a key, create another.

3. The Set up downloads have it written in until you leave the console. The console keeps the new key in the open page only, and builds each file in your browser with your API URL and key filled in. Leave or reload the console and the files have SENSOR_KEY where the key goes, for you to replace by hand. The files:

   Download on Set up	File	For
   Chrome: install	com.google.Chrome.plist	Jamf: force-installs the extension in Chrome (no key in it)
   Chrome: Prism settings	com.google.Chrome.extensions.oblejifclpmcamglacjnhmfmdccpbnmk.plist	Jamf: the extension’s settings in Chrome
   Edge: install	com.microsoft.Edge.plist	Jamf: force-installs the extension in Edge (no key in it)
   Edge: Prism settings	com.microsoft.Edge.extensions.oblejifclpmcamglacjnhmfmdccpbnmk.plist	Jamf: the extension’s settings in Edge
   Chrome: registry file	prism-dlp-chrome.reg	Windows: force-install and settings for Chrome
   Agent settings (.plist)	com.stabilise.prism.agent.plist	Jamf: the Mac agent’s settings
   Permissions profile (.mobileconfig)	Prism DLP agent permissions.mobileconfig	Jamf: the Mac agent’s permissions (no key in it)

   For Google Admin there’s no file. Set up shows the JSON for Policy for extensions with apiUrl and apiKey filled in, ready to copy.

4. You upload them to your device management tool. Jamf Pro takes the .plist files under Application & Custom Settings. Google Admin takes the JSON. On Windows, deploy the registry file with Group Policy Preferences or your management tool.

5. Each device receives them as managed settings. Chrome and Edge treat them as policy for the Prism extension; macOS holds them as managed preferences for the agent. People can’t change or remove what your organisation sets.

Where each sensor reads them

The extension looks in three places, in this order. A value set by policy comes first, then anything typed on the extension’s settings page, and for the email only, the address of the signed-in Chrome profile. Fields set by policy show read-only on the settings page. The extension does nothing until it has an API URL, a key starting pk_ and an email.

The agent reads the same four names from its preference domain. A value from your profile takes precedence over one set on the Mac with defaults write, and the person can’t change it. It needs an https API URL, a key starting pk_ and an email before it does anything, and it checks in with Prism every 15 minutes.

On Windows, Prism runs as the browser extension in Chrome today.

$EMAIL and $FULLNAME

The Jamf settings files hold $EMAIL and $FULLNAME in place of a real address and name. Jamf replaces them on each Mac with the email and full name of the user assigned to that Mac, so one file serves every Mac.

If a Mac has no assigned user, Jamf leaves $EMAIL as it is. Both sensors treat a variable nobody filled in as empty (the same goes for %NAME% and {{name}} styles from other tools). After that:

• The extension uses the email of the signed-in Chrome profile. With no profile email either, it does nothing.
• The Mac agent has no fallback. It stays on Prism DLP is not configured until an email arrives.

The Google Admin JSON on Set up sets only apiUrl and apiKey, so on browsers managed that way the extension uses the Chrome profile’s email.

Where the email came from also matters for exceptions. A time-limited exception applies only to an email your organisation set, or, in the extension, the Chrome profile’s. An email someone types on the extension’s settings page is recorded but never qualifies.

How to see that it arrived

In Chrome or Edge

1. Open chrome://policy (or edge://policy) and click Reload policies. ExtensionSettings should show OK, and Prism’s apiUrl and apiKey should be listed.
2. Open chrome://extensions. Prism DLP should say “Installed by your administrator”.
3. Click the Prism icon in the toolbar to open its settings. Fields your organisation set are read-only, and the page says “Some settings are managed by your organisation and can’t be changed here:” followed by their names. Test connection sends an empty batch with the key, so nothing is recorded, and answers with one of:
   • “Connected. Prism accepted this key.”
   • “Prism rejected this key. Check it in the console under Set up.”
   • “Couldn’t reach Prism. Check the URL, and save first if you’ve just changed it.”

On a Mac

4. Click the Prism icon in the menu bar. The first line reads Prism DLP is on or Prism DLP is not configured. The second shows the last check-in, for example Checked in 09:41, or Prism didn’t accept this Mac’s key, or Couldn’t reach Prism; will retry.
5. Choose Prism DLP setup… for the same in a window: Connected to Prism, Not set up yet, or Prism didn’t accept this Mac’s key.

In the console

6. Under AI tools → Macs and PCs, each Mac appears within 15 minutes of its settings arriving, with the person, the agent version and Last seen.

What a sensor key can and can’t do

A sensor key opens the doors sensors use and no others. With it, a device can:

• send events and ask for a verdict on a paste, upload or message
• ask what the verdict would be without anything being recorded (the Mac agent asks this about the clipboard when an AI app comes to the front)
• add the reason a person gave for going ahead
• fetch the settings sensors need: the mode, which AI tools to watch, and the wording people see
• report AI tool use and the device’s check-in

It can’t read events, incidents, the audit log or anything else Prism has stored, change a setting, or sign in to the console. Each key is limited to 20 requests a second, with short bursts up to 40.

A read key (Read key: SIEMs and scripts under Sensor keys) is the other kind. It only reads events and the audit log through the Events API (integrations.md). The addresses sensors use refuse it, and the Events API refuses sensor keys. Of the two it’s the more sensitive, because it can read. Events hold detected values already replaced by placeholders, but treat a read key like any other secret your SIEM holds.

If a sensor key leaks, whoever has it could send made-up events and AI tool use into your console, see what your policy would do with any text they try, and read the mode, watched tools and wording your sensors get. They couldn’t see anyone’s events or incidents. Replace the key.

Replacing a key safely

1. On Set up, create a new sensor key.
2. Put it in your device management settings in place of the old one, or download fresh Set up files and upload them.
3. Wait for devices to pick it up. Check a few on chrome://policy and in the agent’s setup window, and allow time for machines that are switched off or away from the network.
4. Revoke the old key on Set up. The console asks “Revoke [label]? Browsers and Macs using it stop reporting within 30 seconds.” Prism remembers a checked key for up to 30 seconds, so a revoked key stops working within that time. It stays in the list, marked revoked with how long ago.

Revoke last. Revoking first cuts off every device until the new settings reach it, and a Mac whose key was refused only tries again every 5 minutes.

If it didn’t arrive

Start with troubleshooting.md. The entries that match this page:

• The extension shows $EMAIL instead of an email
• “Prism rejected this key”
• A settings change hasn’t reached browsers
• The Mac says “Prism DLP is not configured”
• The Mac says “Prism didn’t accept this Mac’s key”
• A Mac doesn’t appear under Macs and PCs

Updated 19 October 2026