Tokenized before it's ever sent
Every client identifier goes through a scrubber on the way out and a re-hydrator on the way back. The prompt that reaches the AI carries opaque tokens — [ORG_1], [HOST_1], [IP_1] — never the real thing. The token-to-value map never leaves the process, so only we can turn those placeholders back into your client's data.
Cloud identifiers
ARNs, AWS account and Azure subscription IDs, resource IDs like sg-* and vol-*, and bucket or tenant names — the strings an attacker could pivot on — are replaced with opaque tokens before any prompt leaves.
Hosts & public IPs
Hostnames and public IPv4 addresses are masked to tokens. Private and invalid IPs are deliberately left alone — they carry no exposure, so tokenizing them would only add noise the AI has to reason around.
People, orgs & domains
Client and organization names, domains, email addresses and personal names are swapped for stable tokens — so the model can reason about "the client" without ever learning who the client is.
PII safety net
US Social Security and phone-number patterns are caught as a catch-all for stray identifiers a caller didn't explicitly enumerate. Technical strings that aren't identifiers — a CVE ID like CVE-2021-44228 — are left untouched so findings still read correctly.
Stable within a prompt
The same value always maps to the same token inside one request, so the AI reasons about it consistently — [HOST_1] is the same host everywhere in the prompt. It just never learns the real name behind it.
Re-hydrated locally
When the response comes back, tokens are swapped for the real values on our side before anything is stored or shown. The map that could re-identify the data stays in-process and never touches the AI.