Guardrails in Production: PII Masking and Keyword Blocking

What actually leaves your application when you call an LLM

Every message you send to a chat completion — the user's raw text, any document content you inject, conversation history — travels to the provider's infrastructure. If a customer pastes their phone number, an Aadhaar number, or a credit card number into a support chat, that value goes to the LLM provider unless something intercepts it first. Most teams don't think about this until a compliance review asks.

Guardrails run server-side, before a request reaches the provider, so client applications don't need to implement this logic themselves.

PII masking

When enabled, PII masking scans request content and replaces sensitive values with placeholders before the request leaves for the LLM provider:

| Category | Example | Replaced with | |----------|---------|-----------------| | Email addresses | [email protected] | [EMAIL] | | Phone numbers | +91-9876543210 | [PHONE] | | Aadhaar numbers | 1234 5678 9012 | [AADHAAR] | | PAN numbers | ABCDE1234F | [PAN] | | Credit card numbers | 4111 1111 1111 1111 | [CREDIT_CARD] | | Bank account numbers | 9–18 digit sequences | [BANK_ACCOUNT] | | Passport numbers | Standard formats | [PASSPORT] |

The LLM never sees the real value — it responds to the placeholder as if it were the actual data, and the substitution is transparent to your application. A user typing "my Aadhaar is 1234 5678 9012, can you help me draft a KYC form" gets a coherent response without the real Aadhaar number ever reaching the provider.

Blocked keywords

You can configure a list of prohibited terms. Any request containing one is rejected immediately with a 400, before it reaches the LLM:

{
  "error": {
    "message": "Request blocked: contains prohibited content",
    "type": "invalid_request_error",
    "code": 400
  }
}

Matching is case-insensitive and checks all message roles (system, user, assistant), which matters if you're building a chatbot where conversation history is replayed on every turn — a blocked term from an earlier message would trigger the block again if included in later context.

Response healing

Structured JSON output occasionally comes back malformed — a truncated closing brace, a stray "Sure! Here's the JSON:" preamble the model added despite instructions not to. Response healing repairs these automatically:

response = client.chat.completions.create(
    model="openai/gpt-4o-mini",
    messages=[
        {"role": "system", "content": "Return a JSON object with name and age."},
        {"role": "user", "content": "John Doe, 30 years old"},
    ],
    response_format={"type": "json_object"},
)
import json
data = json.loads(response.choices[0].message.content)  # healed transparently if needed

Healing has limits — it fixes minor formatting issues, not a severely truncated response caused by too low a max_tokens for the schema you asked for. Set max_tokens generously for structured-output requests.

Data retention as a guardrail

For applications handling sensitive support conversations, configuring metadata_only retention means request and response content is never stored at all — only metadata (model, token counts, cost, timestamp) persists for billing and analytics. This is a stronger guarantee than masking alone: even masked content isn't retained.

Frequently Asked Questions

Does enabling guardrails change my request format?

No — PII masking and blocked keywords are server-side configuration, not client-side parameters. Response healing is automatic whenever you request JSON output.

How do I enable PII masking for my account?

It's configured server-side per account — contact support or check your account settings to enable it. No client-side code changes are required once it's on.

Will PII masking break a request that legitimately needs to process a phone number, e.g., a CRM lookup tool?

Masking is designed to be transparent to the model's ability to respond coherently, but if your application specifically needs the LLM to process a real number (not just acknowledge it), evaluate whether that logic belongs in your application code instead of the LLM call.

Does response healing work on streaming responses?

Healing operates on the complete response, so it applies most reliably to non-streaming JSON-mode requests. For streaming use cases, validate and repair the assembled JSON on the client side after the stream completes.

Get started

• Read the guardrails docs for the full configuration reference.
• Create a free account and check your profile settings for retention policy options.
• Related: Prompt Injection: The Security Threat Every AI Developer Must Know.