The AI Gateway is an inline broker. It never sits to the side collecting logs after the fact — every request flows through it, so it can act on the data before a model ever sees it, and check the answer before your users do. That position on the wire is what makes it an inline redaction layer for every AI call instead of a report you read afterwards.
The request lifecycle
Your app sends a request
An app, assistant, or automation sends a prompt (and optionally documents or context) to the Gateway instead of directly to a model — via the SDK, REST API, or proxy.
Detect
Purpose-built classifiers and pattern detectors scan the request for sensitive entities — PII, PHI, cardholder data, secrets — and for content your policy forbids (for example, a password-reset email). Detection combines deterministic patterns with ML models so it catches what a regular expression alone would miss.
Redact & enforce policy
Each detected entity is handled by type — redacted, masked, or blocked — according to the active policy. Original values are held on your side as reversible tokens so they can be restored later if the workflow needs them. If a request violates a hard rule, it's stopped here.
Forward to the model
Only the sanitized prompt is sent to the selected model — GPT, Claude, Azure OpenAI, or a private model. The model sees safe input, never your raw data.
Inspect the response
The model's reply passes back through the Gateway, which checks it for leaked sensitive data or policy violations and re-links any reversible tokens the workflow is allowed to see.
Return and log
The checked response is returned to your app, and the whole exchange — what was sent, what was redacted, which model answered — is written to the audit log.
Detect, redact, block
The Gateway does one of three things with every sensitive item it finds:
| Action | What happens | Typical use |
|---|---|---|
| Redact | The value is removed and replaced with a typed placeholder. | Names, addresses, SSNs, health details. |
| Mask | Only part is shown (e.g. last 4 digits). | Card numbers, phone numbers, emails. |
| Block | The whole request is refused and never sent. | Secrets, API keys, password-reset emails. |
Reversible tokenization
Redacting Jordan Rivera to [NAME_1] would normally make the model's answer
useless for that customer. The Gateway instead swaps sensitive values for
reversible tokens, keeps the mapping on your side, and re-inserts the real values
into the response when — and only when — the workflow is authorized to see them. The
model works with placeholders; your users see the finished, correct result.
Deployment shapes
The same engine runs in whichever shape fits your stack:
- SDK — call
gateway.sanitize()inside your own code before you call a model. - Reverse proxy — point an existing app or assistant's model endpoint at the Gateway; no code change.
- Managed proxy — intSignal runs a multi-tenant proxy for integrators serving many clients.
Tip
Because the Gateway is model-agnostic, you can A/B or fail over between GPT and Claude without touching your redaction rules — policy lives in the Gateway, not in the model call. See Models & agents.
Where it runs
The Gateway can run in intSignal's cloud or on-premises / in your own VPC when data residency requires it. In either case it authenticates with your identity provider (SSO via Microsoft Entra ID) and writes its audit trail where you can reach it, including export to a SIEM.