1. PII redaction LLM use case in one rule
The hard part ofpii redaction llm plumbing is usually the plumbing.
PII Shield removes it. The preset is a single pii rule:
- Type: PII detection (
pii) - Action: Mask — replace each match with a typed tag
- Entities:
email,phone,ssn,credit_card,ip
/v1/chat/completions exactly as before.
Input-stage masking is the live path. PII Shield masks the
request before it leaves the gateway, so the upstream model never
sees the original value. Live masking of model output and streamed
responses is on the roadmap; frame PII Shield as scrubbing what you send,
not what comes back. To gate model responses today, an output block
rule is enforced both ways — see
Output-stage rules and
Streaming coverage.
2. Apply the preset in the console
Every step here is a console action on the hosted gateway under your own session. Creating and editing guardrails requires Developer+ in the workspace. Only the final/v1/* call uses an sk-orca-... relay
key.
Open the template
In the console, open Guardrails, click the New guardrail
split-button, and pick PII Shield from the PII template
category. It seeds a single masking
pii rule.Name and save
Give it a name (≤ 64 chars), e.g.
pii-shield, and save. A preset is
a seed, not a lock — edit the entity list or action freely afterward.Test it
Open the Test tab, paste a sample at the
input stage, and run
the policy locally — no upstream call, no quota (see
§4).Attach a key
Edit an API key and pick
pii-shield from the Guardrail
dropdown (sets guardrail_id on the key), or mark it the workspace
default. See Attach to a key
and Account default.3. What gets masked, and to what
On a mask action each match is replaced with a typed tag — an email becomes[EMAIL], an SSN becomes [SSN]. The built-in detector set is
closed and shared by the engine, the sandbox, and the rule builder:
Built-in entities
Built-in entities
email, phone, credit_card, ssn, ip, iban,
mac_address, jwt, aws_access_key, api_key_openai,
bitcoin_address.Regional identifiers
Regional identifiers
jp_mynumber (Japan My Number → [JP_MYNUMBER]), kr_rrn (Korea
RRN → [KR_RRN]), and cn_resident_id (China resident ID →
[CN_RESIDENT_ID]). Enable the ones that match your jurisdiction.Your own custom entities
Your own custom entities
Layer a regex detector on top of the built-ins — an
employee_id,
an internal account number — with an optional luhn checksum and a
custom replacement. Up to 25 per rule. See
Custom PII entities and
Masking formats.4. Test before you attach
Prove the rule does what you expect before any key points at it. Open the Test tab inside the editor, paste a sample, pick theinput stage,
and run:
5. Send a request
Using a key bound topii-shield, call OrcaRouter exactly as before — no
new headers, no SDK change:
[EMAIL] before forwarding — the upstream
model receives Reply to [EMAIL] please and never sees the address.
6. See what fired
Every rule that fires records a match — rule type, action, stage, and a detail string — surfaced in the workspace Matches feed. The matched substring itself (the actual email address) is recorded only when Log raw content is on, which is off by default — the privacy-conservative posture that keeps redacted PII out of your own telemetry too.For a redaction control, leaving Log raw content off is usually the
point: you get to see that an
email was masked and how often, without
re-capturing the value you just scrubbed. Turn it on per guardrail only
when you need the substring for triage; the setting is non-retroactive.
See Matches feed and
Logging & privacy.7. Where to go next
Custom PII entities
Add your own regex detectors with optional Luhn checks, up to 25 per
rule.
Masking formats
Control the typed tag each entity renders to.
Block secrets
Catch API keys and credentials with the Secrets Blocker preset.
Tune false positives
Mark false positives and tighten detectors from the Matches feed.
