Skip to main content
Fleet enrollment is how an admin deploys Shadow AI across many employees at once. Instead of handing out a shared API key, each device redeems a one-time token for its own least-privilege credential — so you can attribute activity per employee and revoke any single device instantly, without touching the rest.

​
Two ways in, and they attribute differently

The member signs in

The person opens Connect this device in the app, approves it in their own browser session, and the device binds to their membership of your organization. The dashboard shows their account, not a label. Any member can do this for their own machine — they do not need to be an admin, and no admin has to mint anything.

An admin mints a token

For bulk rollout and MDM, where nobody is at the keyboard to click anything. The device gets the same scan-only credential and the same protection, but it binds to no account — the dashboard marks it unverified and shows only the free-text label the enrollment supplied.
Both are supported and neither is going away. If you need to know who a device belongs to — for per-seat accounting, or to answer “whose laptop is this?” — use the sign-in flow. Devices enrolled before this existed keep working and show as unverified; there is no need to re-enroll them, and re-enrolling is the only way to convert one.Joining an organization always requires an invitation. There is no email-domain auto-join: sharing a mail domain with your organization does not put someone in it, so a contractor or an acquired-company account cannot enroll into your fleet by signing up with a work address.

​
Roll it out

1

Create an enrollment token

In the dashboard, go to Fleet → Enrollment Tokens and create one. You can limit it by platform and set a max number of uses or an expiry. The token is shown once — copy it then.
2

Each device redeems it

Employees run one command (or your MDM runs it for them):
The device receives a scan-only credential bound to your organization’s fleet — no shared secret, no per-employee account needed.
3

Activity rolls up to you

Every verdict is tagged with the device and surface (desktop / browser). Admins see the whole fleet’s AI activity in one place; employees never see each other’s data.
4

Revoke any device in one click

Fleet → Devices → Revoke. That device’s credential is deactivated immediately and its next request is rejected — the rest of the fleet is unaffected.

​
Why per-device credentials

Least privilege

Device credentials can only scan — even if one leaked, it can’t reach management or proxy endpoints.

Attribution, honestly labelled

A device the member signed in to enroll names their account. One enrolled from an admin token carries a free-text label instead, and the dashboard says unverified rather than presenting a guess as an identity.

Scoped visibility

Fleet activity is visible to your org’s admins only, never through a shared key.
The device credential is an ordinary PromptGuard API key presented as X-API-Key, marked scan-only. What it may reach is generated from the two mount prefixes the guard router is served under (/api/v1 and /api/v1/proxy, the second because the Python SDK defaults its base URL there), so the same handler is reachable by both names:
  • /api/v1/guard and /api/v1/proxy/guard
  • /api/v1/agent/managed-policy and /api/v1/proxy/agent/managed-policy — exact match only. /agent as a family stays closed; this one read-only policy poll is the exception
  • /api/v1/enroll, and the /api/v1/exceptions, /api/v1/policies and /api/v1/tool-requests subtrees, so a device can file and poll its own requests
  • /api/v1/fleet/devices, /api/v1/fleet/devices/self and /api/v1/fleet/identity — the org’s device inventory, self-revocation, and the one row describing the caller itself. /api/v1/fleet/usage is not on the list: it breaks activity down per person, which is management reporting rather than something an agent needs
A trailing slash cannot change the outcome: paths are compared with it stripped, so /api/v1/guard/ now 404s for everyone rather than 403-ing only scan-only keys. Anything not on that list fails closed with 403 scope_denied.

​
Org-managed updates

On the fleet plan (shadow_fleet_management — Scale gateway tier or Shadow standalone), admins control how the agents on enrolled devices update:
  • Force the update mode — e.g. require Automatic so every device stays current, regardless of what the user picks locally.
  • Pin the release channel — keep the fleet on stable, or move a test group to the beta channel.
  • Set a minimum version — devices below the floor are forced to update. Until they do, they keep protecting with their current policy (a stale agent never disarms), but coverage-reducing controls are locked.
On a managed device, the corresponding controls in the app’s Settings show “Managed by your organization” and can’t be changed by the user. Everything else about the app behaves the same.

​
Managed configuration (MDM)

Some settings belong to the organization rather than to the person at the keyboard. The agent reads those from the operating system’s own management channel — the one your MDM already uses — before it talks to anyone: The key names are identical in all three: Two things follow from where those values live:
  • Managed configuration wins, and it locks. Precedence is managed → a command-line flag → an environment variable → the user’s own ~/.promptguard/config.json → the default. Every key you supply is locked: the app shows it as set by your organization and the person on the device can’t change it. A managed engine_url locks the dashboard the device enrolls against along with it.
  • A bad value is reported, never guessed at. A source that exists but can’t be read or parsed contributes nothing and is shown as a problem in the app. An unknown key name, a blank value or the wrong type is ignored and reported the same way. A value of the right type that doesn’t parse — triage_setting: "hybird" — still wins its key and resolves to that key’s safe default rather than falling through to a lower source.
If you pushed an MDM artifact before this release, push a fresh one. The artifacts the dashboard generated used older key names (base_url, enrollment_token) and, on Windows, a PromptGuard\Shadow subkey — none of which the agent reads, so those pushes configured nothing. Artifacts downloaded now carry the keys in the table above. The stale keys stay on the device, ignored but locked, until the profile or policy that set them is replaced.

​
Device liveness

The device table shows Last seen — the last time that device’s agent checked in with PromptGuard. The agent checks in on its own schedule (roughly every six hours, and once at launch) whether or not anyone on that machine is using AI, so this tracks whether the agent is still running, not how busy the person is. Two readings worth telling apart:
  • never — the device redeemed its enrollment token but has never checked in since. Usually the agent was never actually installed, or it is installed and not running. Enrolling is not the same as being protected.
  • A stale timestamp — the agent checked in and then stopped. Expect the machine to be off, offline, or to have had the agent quit or uninstalled.
Revoking a device disables its credential, so a revoked device stops checking in and its Last seen freezes at the moment it last reached us.

​
For automation

If you’re scripting enrollment or building tooling, these are the endpoints behind the dashboard: See the API Reference for full request and response schemas.

​
Next steps

Choose where your data runs

Keep the engine in our cloud, on your own infrastructure, or fully air-gapped.