Deployment Modes

​

Hybrid — scan on your servers, review in the cloud

DEPLOYMENT_MODE=data_plane
CONTROL_PLANE_URL=https://api.promptguard.co
INSTANCE_TOKEN=<your per-instance token>
FORWARD_MODE=metadata     # the default — only counts/decision/threat, never prompt text

​

Air-gapped — everything inside your network

• The engine, via our Helm chart — including a default-deny egress NetworkPolicy overlay that blocks outbound traffic at the network layer, so “no data leaves” is enforced by Kubernetes, not by trust. GeoIP, release lookups and hosted ML inference are off in code, but the application can still attempt a few outbound calls when configured for them; the NetworkPolicy is what stops them, which is why your CNI must enforce it.
• The dashboard — deployed by the same Helm chart (or our Docker Compose bundle), along with the database migrations and scheduled jobs.
• An offline license — an Ed25519-signed, time-limited license file validated locally; no license server or phone-home required.
• Detection — the deterministic detectors (regex + heuristic rules) and the prompt-injection classifier run in-process, the classifier on model weights you fetch yourself with your own Hugging Face account (PromptGuard does not ship them; see Third-Party Models). The chart’s optional judge service is bring your own GPU model server, not validated by PromptGuard; point the engine at a model server you run, or accept the reduced coverage — each scan lists the checks that could not run.
• SSO against your own IdP — the dashboard authenticates directly via OIDC against your identity provider.

​

Pointing desktop agents at your engine

pgshadow login --base-url https://promptguard.internal.example/api/v1

• Your engine is shown no prompt content by default. A device pointed at an engine PromptGuard doesn’t run defaults to the metadata_only disclosure: no prompt text, attachment text, image or audio reaches it, only {category, count} device findings. Set disclosure to masked if you want your engine to see the (masked) prompt and the full detection that depends on it — see What the engine is shown.
• You can take update traffic off PromptGuard. updater_enabled off stops every update check; update_url points the updater at your own mirror of our signed releases and is then the only source, with no GitHub fallback. Artifacts are still verified against the key compiled into the app, so mirroring is not re-signing. Block those hosts at egress either way. Details in Updates.
• PROMPTGUARD_BASE_URL is not the same thing. As an environment variable it redirects only scans, and it never locks; the app’s update checks and enrollment follow the managed or signed-in URL, which without either is PromptGuard’s cloud. Push engine_url through your device management (Enrolling a Hybrid fleet) and nobody has to run anything: the value is locked, and enrollment goes to that engine too.
• Hybrid enrollment needs a managed enrollment token. “Connect this device” opens a dashboard sign-in page, and a Hybrid engine serves no dashboard, so browser enrollment against it does not work. Enroll Hybrid devices with a token instead — see Enrolling a Hybrid fleet.
• You can require that nothing goes unchecked. Set on_engine_unreachable to hold and a prompt your engine couldn’t be asked about is not forwarded to the AI tool at all — see If the engine cannot be reached.

​

Enrolling a Hybrid fleet

1. Put two keys in the agent’s managed configuration — that section has the key schema and the per-OS locations:

   Key	Value
   engine_url	Your engine, including /api/v1 — e.g. https://promptguard.internal.example/api/v1
   enrolment_token	An enrollment token your engine accepts

2. Install the desktop app. On first launch it sees the token, sends it to <engine_url>/enroll, and saves the device credential. It opens no browser and no dashboard page, and nobody has to click anything. Then it turns protection on the same way “Connect this device” does.

• The token has to exist on the engine that redeems it. A Hybrid engine checks tokens against its own database. A token minted in the promptguard.co dashboard lives in PromptGuard’s cloud database, so a Hybrid engine rejects it as Invalid or expired enrollment token (HTTP 403). A Hybrid engine doesn’t expose token minting itself (the fleet routes are part of the dashboard). Contact support@promptguard.co to provision tokens for a Hybrid rollout.
• The dashboard can write the keys for you. Download MDM profile on the Shadow AI page mints an enrollment token and renders a macOS .mobileconfig with the keys above already filled in, plus on_engine_unreachable set from your organization’s fail-closed setting. For the Windows .reg or the Linux managed.json, call POST /dashboard/fleet/enforcement-artifact with {"platform": "windows"} or {"platform": "linux"}. Earlier releases wrote key names the agent did not read (base_url, enrollment_token) and, on Windows, a PromptGuard\Shadow subkey it never opened; if you pushed one of those, push a freshly downloaded artifact over it. Either way you can still write the keys yourself — a key the agent does not recognize is listed as an unknown key in Settings, under the settings your organization manages.
• A refused token isn’t retried in a loop. The app tells the person to contact their IT administrator and waits for someone to press Try connecting again.

​

Which one is right for you