Every claim here is traceable to code.
Security posture, data retention, sub-processors, and incident response. Forward-looking items say so. Nothing on this page is aspirational copy.
Processed in Canada. Not stored.
Your text travels over TLS to the detection API (Fly.io, Toronto), is scored by Microsoft Azure OpenAI in a Canadian region, and the block/allow decision comes back. On that path the prompt is not written to any database. What we do keep, and for how long, is the table below, and each row is enforced in code or config.
| Data class | What it is | Kept for |
|---|---|---|
| Prompt text in flight | The text being scored | Not persisted. Scored, then discarded. |
| Session entity codes | Entity category codes for cross-message detection ("an email was seen"), never values (DB constraint + CI test) | 24 hours |
| Redaction maps | Original values mapped to tokens, only when you use tokenize/restore | 30 days, plus on-demand DSAR deletion |
| Incident captures | Raw prompt text, only if your team opts in. Encrypted (server-side key or client-side zero-knowledge). | Content cleared at 90 days, row at 365 |
| Audit metadata | Entity-type codes, platform, was-blocked. Never raw PII. | 365 days |
| Usage metering | Per-key request counts for billing. No prompt content. | Retained for billing |
| Operational logs | No prompt or reply text, only lengths, hashes, counts | Provider log window |
| Backups | Rolling database snapshots | 5-day rolling window |
Erasure on request: a data-subject erasure hard-deletes audit and incident rows and cascades to the detection API to delete redaction maps immediately rather than waiting out the 30-day TTL. If any step fails, the erasure is reported as failed, never as complete.
How it is built.
The decision is server-side
The browser extension is a thin client that cannot override or weaken a block decision. Detection, scoring, and policy all run in the API.
Prompts are not persisted
On the detection path, text is sent to the detector, scored, and discarded. It is not written to a database. Session memory stores entity category codes only, enforced by a database constraint and a CI test.
Nothing sensitive in logs
No prompt or reply text is ever logged. Unreadable detector replies are logged as a length and a hash prefix, never content. Retention sweeps and erasures log counts only.
Encrypted in transit and at rest
TLS everywhere, including the database connection. Provider disk encryption at rest on Fly.io and Azure. Opt-in incident content gets application-layer encryption on top (server-side key, or client-side zero-knowledge where we never hold the key). Application-layer encryption of redaction maps is in progress and stated as roadmap, not claimed as shipped.
Fail-safe by design
An unreadable detector reply fails closed (blocks). An upstream outage returns HTTP 503 within seconds instead of hanging or silently allowing.
Access is one person, disclosed
PII Shield is operated by a single person with MFA on every production account (GitHub, Fly, Azure, Clerk, Stripe), secrets held only in provider secret stores, and no customer PII touched in operations outside the audited DSAR path. We disclose the bus factor rather than hide it; wind-down terms are in the incident-response doc.
Who else touches data.
We notify customers before adding a sub-processor that touches their data. The AI sub-processor sees prompt text to score it; nobody stores it on the detection path, and per Microsoft's Azure OpenAI terms prompts are not used to train foundation models.
Microsoft Azure OpenAI
Canadian regionAI detection engine. Prompt text in transit for the scoring call; not retained by us.
DPA / termsFly.io
Toronto (yyz); US entity under DPA + SCCsApplication + database hosting. Data at rest (Postgres) and the runtime.
DPA / termsStripe
US / globalBilling / payments. Billing contact and payment data (Stripe-held), not prompt data.
DPA / termsThe 72-hour commitment.
On confirming a personal-data breach that affects customer data, we notify affected customers without undue delay and within 72 hours of confirmation, with the nature of the breach, the data classes involved, the likely consequences, and the mitigation taken.
This aligns with PIPEDA breach-of-security-safeguards obligations and the GDPR Article 33 standard. Because prompts are not stored and session data is metadata-only, the blast radius of most incident classes is structurally limited, and investigations use metadata (counts, hashes, timestamps), not your content.
The honest SOC 2 answer.
No, and at this price we will not pretend to. Here is our security overview, sub-processor list, data-flow, and DPA. SOC 2 is on the roadmap once revenue supports the audit cost. If SOC 2 is a hard requirement today, we are not your vendor yet.
A completed CAIQ-Lite self-assessment (the industry-standard middle ground) and a pre-answered security questionnaire are available on request, alongside the full trust pack and our DPA.
Want the full pack?
Security overview, retention tables, sub-processor DPAs, incident-response plan, CAIQ-Lite, and the DPA template. We send it as-is, no NDA required.
Request the trust pack