The data lifecycle
Inspected locally
Every paste, prompt, or upload to a covered AI vendor is inspected on the
employee’s own device. The agent extracts text (including from PDF, DOCX,
XLSX, and plain-text files) and runs on-device secret and PII detection —
entropy plus known-prefix matching — before anything is sent.
A verdict is produced
The agent gets a verdict from the remote
/guard engine (8-second timeout,
fails open). Secrets are blocked and PII is
redacted on the device, so raw sensitive values are never transmitted.With the on-device pre-filter enabled (below), most clearly-benign
prompts are resolved locally and never reach the engine at all — no
round trip, nothing transmitted.On-device pre-filter (minimize what leaves)
A small classifier runs entirely on the device as a first pass. It scores each prompt and, combined with the always-on secret/PII floor, decides whether the engine even needs to see it:- Clearly benign → resolved locally. No engine call, no egress. (In testing, this covers the large majority of everyday traffic.)
- Uncertain or attack-like → escalated to the authoritative engine, exactly as before.
PGSHADOW_LOCAL_CLASSIFIER):
| Mode | What leaves the device | Coverage |
|---|---|---|
off (default) | Every inspected prompt goes to the engine | Full |
hybrid | Only uncertain/attack-like prompts | Full (engine still sees everything that matters) |
local | Nothing — the engine is never called | Reduced: novel semantic attacks the local model can’t see aren’t caught |
local mode is the maximum-privacy tier: prompt content never leaves the
machine under any circumstances. hybrid is the recommended balance — it keeps
the engine’s full detection for anything ambiguous while cutting egress and cost
for the benign majority. The model is a tiny, auditable linear classifier
embedded in the agent; a missing or corrupt model simply disables the pre-filter
(the agent behaves exactly as off).
Where the data lives
Events are written to a local SQLite event log on the device, with PII redaction applied. This log is the system of record for activity on that machine. What reaches the cloud depends on your deployment mode:| Mode | What leaves the device / network |
|---|---|
| Cloud (default) | Events are forwarded to the PromptGuard cloud dashboard. |
| Hybrid | Scanning runs on your servers; only verdicts/metadata flow to the cloud dashboard. With FORWARD_MODE=metadata, no prompt content ever leaves your network. |
| Air-gapped | Nothing leaves — a local dashboard reads the local event log; transfer between sites is via signed bundles only. |
Content inspection is local in every mode. The deployment mode controls what
happens to the verdict and metadata afterward — not whether your raw content
is shipped off the device for scanning.
Retention
- Local event log: retained on the device until the agent is uninstalled
(
pgshadow uninstalldeletes it;--keep-dataretains it). - Cloud dashboard: events follow your plan’s log-retention window — see the pricing page (24 hours / 7 days / 30 days / custom).
- Air-gapped: retention is whatever your local instance is configured for; nothing is held in our cloud.
Subject rights (GDPR / CCPA)
PromptGuard supports data-subject rights for the activity it records:- Access / export — export the events attributable to a given device or employee.
- Deletion — delete a subject’s recorded events.
pgshadow uninstall.
For cloud and hybrid deployments, export and deletion are available through the
platform’s GDPR endpoints (Enterprise) — see
Audit Logs and
Compliance. For a specific request or a DPA, contact
support@promptguard.co.
Audit trail
Verdicts across every surface (desktop · browser · sdk · proxy) roll up
into one audit trail in the dashboard, attributable per device in a fleet. For
tamper-evident, hash-chained audit logs see
Audit Logs.
Next steps
Deployment modes
Cloud, hybrid, or air-gapped — controls what leaves your network.
Known limitations
What’s out of scope, including image OCR.