Skip to main content
You want a paper trail of where sensitive data shows up in your AI traffic, but you are not ready to start rejecting requests. The Compliance Logger preset is exactly that: a guardrail that watches and records PII occurrences and changes nothing. Attach it to a key and every flagged term lands in the Matches feed while the request flows upstream byte-for-byte unchanged. This is a focused landing for the observe-only use case. For the full engine — every rule type, action, and route — see the Guardrails reference.

​
1. The observe only guardrail in one preset

The Compliance Logger (observe-only) lives in the Compliance category of the guardrail template picker. It is a single pii rule with action flag — the action that records a match and leaves the traffic alone. There is no block, no mask, no model call, and no SDK change: the policy lives in the gateway, and your app keeps calling /v1/chat/completions exactly as before.

Flag, never enforce

Action is flag — it annotates a match and lets the request and response through untouched. Nothing is blocked, nothing is masked.

Both stages

Stage both — the rule scans the request and the model’s response, so you see PII on the way in and the way out.

Zero quota overhead

Built-in PII detection is deterministic string matching — no upstream judge call, no extra tokens, nothing serialized behind a model.
Flag = observe-only. A flag action records a match and does not change traffic. It is the right tool for measuring a policy before you enforce it, or for keeping a compliance log without altering behavior. See Actions for the full block / mask / flag trade-off.

​
2. The Compliance Logger preset, exactly as shipped

Open the New guardrail split-button in the console Guardrails view and pick the Compliance template category. The Compliance Logger (observe-only) seed is a single pii rule:
FieldValue
Typepii
Stageboth (request + response)
Actionflag (observe-only)
Entitiesemail, phone, ssn, credit_card, ip
Every match on any of those entities is recorded; nothing is blocked or modified. The preset is a seed, not a lock — edit the entity set, rename it, or layer more rules before you attach a key.
Flagging runs live on requests — the rule fires on real traffic the moment a key is attached, so the Matches feed fills from your actual calls, not a separate sampling job.

​
3. Apply the preset in the console

Every step here is a console action 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 Compliance Logger (observe-only) from the Compliance template category.
2

Name and save

Give the guardrail a name (≤ 64 chars), like compliance-logger, optionally trim or extend the entity list, and save. Leave the action on flag — that is what keeps it observe-only.
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 §5).
4

Attach a key

Edit an API key and pick compliance-logger from the Guardrail dropdown (sets guardrail_id on the key), or mark it the workspace default. See Attach to a key and Account default.

​
4. One concrete example

A guardrail named compliance-logger (the preset, unchanged) is attached to a key. Call the gateway 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 about her SSN 123-45-6789"}
    ]
  }'
The request goes through unchanged — the upstream model sees the exact same text, the response is unmodified, and you get a normal completion. Behind it, the pii rule flags email and ssn, and each match lands in the workspace Matches feed. The caller never sees a difference; you get the audit trail.
Observe-only means no enforcement. The Compliance Logger does not block leaks or redact data — it records them. When you are ready to act, switch the action to block or mask, or pair it with an enforcing preset like the PII Shield or Block secrets.

​
5. Test before you attach

Prove the rule flags what you expect before any key points at it. Open the Test tab inside the editor, paste a sample, pick a stage, and run: 
Reply to jane@acme.com about her SSN 123-45-6789
The sandbox evaluates the current policy locally and returns the verdict — for a flag rule, you see which entities matched, with nothing sent upstream and nothing metered. For a sweep against a corpus of phrasings, the Eval harness lives one tab over.

​
6. See what fired

This is the whole point of an observe-only preset: the Matches feed. Every flagged occurrence records a match — rule type, action, stage, and a detail string — surfaced at GET /api/guardrail/match (Member). The matched substring itself (the actual email, the SSN) is recorded only when Log raw content is on, which is off by default.
For a compliance log, leaving Log raw content off is usually the point: you learn that an SSN appeared and how often, without copying regulated data back into your own telemetry. Turn it on per guardrail only when you need the substring for triage; the setting is non-retroactive. See Matches feed and Logging & privacy.
Filter the feed by stage to see where PII enters your traffic — input prompts versus model output — and by rule type to isolate the pii rule. The matched entity (email, ssn, …) is carried in each match’s detail string. That signal is what tells you whether you are ready to flip the action from flag to block or mask. Every edit to the guardrail writes a versioned history row in the same transaction — diff any two versions and revert from the History view. See Versioning.

​
7. From observe-only to enforcing

The Compliance Logger is designed to be the first stage of a rollout:
Attach the flag-only preset and let the Matches feed fill with real traffic. No request is ever blocked, so there is zero risk to production while you measure.
Use the feed and tune false positives to confirm the entity set matches your data and isn’t noisy.
Flip the action to mask (redact PII before the model) or block, or swap in an enforcing preset. Use per-entity entity_actions to mask some entities while blocking the high-severity ones in a single rule.
Need a regulated-framework log rather than a hand-rolled one? The Compliance Logger is one of the presets that compliance packs materialize. See the Compliance section for framework-driven readiness and signed reports.

​
8. Where to go next

Actions: block / mask / flag

The full action model — when to observe, when to redact, when to reject.

PII Shield

The enforcing counterpart — mask PII on the request instead of just logging it.

Matches feed

Browse, group, filter, and export every flagged occurrence.

Logging & privacy

The Log-raw-content toggle and what is recorded by default.
An observe-only guardrail gates nothing on its own — it is a measurement surface. For the broader picture of how guardrails and the firewall split the work, see Guardrails vs firewall. For the complete engine — stages, advanced rules, and routes — read the Guardrails reference.