Gateway Overview

The FastPII AI Gateway is an AI gateway proxy that sits between your application and your LLM providers. Every request can be inspected before it reaches the model, which lets you detect and protect PII in real time, enforce workspace policies, and record a complete audit trail for compliance and operations.

Use the Gateway when you want one control point for prompt and response traffic across OpenAI, Anthropic, Azure OpenAI, Ollama, and other providers configured in your FastPII workspace.

What the Gateway does

At a high level, the Gateway receives traffic from your application, evaluates it against FastPII detection and policy rules, applies the configured action, then forwards the allowed content to the provider.

Key features

• Real-time PII detection in LLM traffic
• Policy-based enforcement with ALLOW, WARN, MASK, BLOCK, ESCALATE, LOG, and QUARANTINE
• Multi-provider support through workspace-managed LLM provider configs
• Audit logging for every protected request
• Risk scoring and risk-level reporting
• Streaming support for low-latency chat and completion workflows

Architecture

Application
    |
    v
FastPII Gateway
    |-- Detect PII
    |-- Evaluate policies
    |-- Apply protection action
    |-- Write audit event
    v
LLM Provider

In practice, the Gateway becomes the trust boundary between your application and third-party model providers.

Authentication model

FastPII uses two auth patterns, depending on what you are calling:

For the Gateway docs in this section, assume Service Token authentication. Gateway endpoints do not use API key auth.

Example header:

X-Service-Token: your-gateway-service-token

Core endpoints

How a request flows through the Gateway

1. Your application sends a prompt to the Gateway.
2. The Gateway identifies the workspace and loads the gateway config.
3. FastPII scans the content for entity types such as email, phone number, address, or national IDs.
4. Matching policies are evaluated in priority order.
5. The Gateway applies the selected action, such as MASK or BLOCK.
6. Allowed traffic is forwarded to the selected provider and model.
7. The Gateway writes an audit event with the action taken, risk level, provider, latency, and detected entity types.

Quick request flow example

Suppose your application submits this prompt:

Summarize this support ticket for john.doe@example.com and call back +420 777 123 456.

With a masking policy in place, the Gateway can transform it before forwarding it to the provider:

Summarize this support ticket for ******************** and call back ***************.

The resulting audit event can record data like:

{
  "request_id": "req_01J9X6R6Q3Q9P7E8N6YQ3A7K2M",
  "workspace_id": "ws_prod_eu",
  "provider": "openai",
  "model": "gpt-4o-mini",
  "action": "MASK",
  "entity_types": ["EMAIL", "PHONE"],
  "risk_level": "MEDIUM"
}

Typical rollout path

Most teams start with this sequence:

1. Add one or more LLM providers.
2. Configure the workspace gateway.
3. Create a default masking or warning policy.
4. Test policy behavior with sample prompts.
5. Review audit and dashboard data before expanding coverage.

Continue with Gateway Setup to configure your workspace, then use Policies to define enforcement rules and Audit to review events and metrics.