Skip to main content
You want to keep personal data out of the upstream model. A customer pastes an email address, a support transcript carries a card number, an agent prompt leaks an SSN — and none of it should reach OpenAI, Anthropic, or Google in the clear. PII Shield is the fastest way to fix that: a one-rule guardrail preset that detects sensitive entities in the request and masks each one to a typed tag before the gateway forwards the call. This is a focused landing for the PII-masking use case. For the full guardrail engine — every rule type, field, and route — see the Guardrails reference.

1. PII redaction LLM use case in one rule

The hard part of pii 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
Apply it once in the console, attach it to a key, and every call on that key is screened with no SDK change and no redeploy. The policy lives in the gateway, not your application — your app keeps calling /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.
1

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.
2

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.
3

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).
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:
email, phone, credit_card, ssn, ip, iban, mac_address, jwt, aws_access_key, api_key_openai, bitcoin_address.
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.
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.
One PII rule can apply different actions to different entities via entity_actions — mask email / phone / ip, but block on credit_card or ssn. No need for overlapping rules. See Actions.

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 the input stage, and run:
Reply to jane@acme.com please
The sandbox evaluates the current policy locally and returns the verdict plus the rendered text — nothing is sent upstream, nothing is metered:
Reply to [EMAIL] please
For an A/B grid against a corpus, the Eval harness lives one tab over.

5. Send a request

Using a key bound to pii-shield, call OrcaRouter exactly as before — no new headers, no SDK change:
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [
      {"role": "user", "content": "Reply to jane@acme.com please"}
    ]
  }'
The gateway masks the email to [EMAIL] before forwarding — the upstream model receives Reply to [EMAIL] please and never sees the address.
Swap an entity’s action to block (via per-entity override) and the very next request carrying that entity is rejected with HTTP 400 guardrail_blocked. A blocked request costs no quota (an input block fires before metering) and is marked skip-retry. See the guardrail_blocked error.

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.
PII Shield masks content. To govern an agent’s tool calls — deny destructive actions, redact tool-call arguments, require approval — use the Firewall. Start with Securing AI agents and the data-exfiltration threat, or read the Guardrails reference for the complete engine.