Integration
Guardrails & fact-checking in front of the OpenAI API
OpenAI gives builders real safety primitives – a free Moderation API, native structured outputs, and an open-source guardrails library that wraps the client with PII, jailbreak, and hallucination checks. All worth using. Their common trait: each is something you wire into each app, and moderation answers to OpenAI’s categories, not your policy. in/guard/out runs the same class of checks on the wire – one constructor argument, every app covered, your rules.
Side by side
| Capability | OpenAI platform tools | in/guard/out |
|---|---|---|
| Content moderation | Free Moderation API (omni-moderation, text + images) – called per app, OpenAI’s categories | In-line cascade on requests and responses – your policy, surgical censoring |
| Guardrails library | Open-source Python wrapper: PII (Presidio), jailbreak, hallucination checks – in-process, per app | Same class of checks operated as infrastructure: one policy, every app, any SDK |
| PII after detection | Detect and redact/block – not restored | Stable placeholders, restored on the response, taint-tracked through tool args |
| Structured output | Native schema adherence – first-party and solid | Uses the native support, adds validate-and-repair (or a clean 422) on top |
| Hallucination & grounding | Library check, configured per app | Deterministic grounding at zero extra tokens, then fact-check judge, RAG, web search |
| Tool-call enforcement | Library wraps function calls in-process | Tool policy, permission tiers, action grounding, taint – outside the process, plus checkpoints |
| Budgets | Org/project usage limits, monthly | Those still apply, plus per-run cost / step / tool budgets |
| Cross-provider policy | OpenAI surface only | Same checks whichever upstream serves – OpenAI today, anything tomorrow |
| Visibility | Usage dashboard: tokens and spend | Per-request stage timings, violations, and true cost including guard sub-calls |
One line changes, nothing else does
If your app uses an OpenAI SDK, the integration is one constructor argument: in/guard/out exposes the same /v1/chat/completions surface your code already calls, runs the guardrail pipeline on each request and response, and forwards upstream to OpenAI. Python, Node, Go, curl – anything that takes a base URL takes in/guard/out.
Nothing else changes: your models, your prompts, your parameters, and your response-parsing code all stay as they are. What you gain is the pipeline – PII screened before OpenAI sees it, answers grounded against their sources, structured output validated, tool calls checked against policy – plus per-request cost and violation visibility your provider dashboard cannot give you. OpenAI’s own primitives keep working underneath; the wire just stops depending on every app wiring them correctly.
Before and after
# before
client = OpenAI(api_key="sk-…")
# after – guardrails on every call
client = OpenAI(
base_url="https://api.inguardout.com/v1",
api_key="gr-…",
)Setting it up with in/guard/out
1. Create a key
Issue a gr- API key in the dashboard and configure which upstream it forwards to – your OpenAI account, with your models.
2. Swap the base URL
One line in the SDK constructor. Requests are OpenAI-shaped in, OpenAI-shaped out, plus X-Guardrails-* headers.
3. Pick your checks and mode
Core checks are on by default; agent checks and external grounding are opt-in. Start in FIX, enforce with PREVENT when the data says so.
4. Read the headers
Violations, cost, and run totals ride back on every response – your app can react programmatically, without polling a dashboard.
Frequently asked questions
Is in/guard/out API-compatible with OpenAI?
It exposes the OpenAI chat-completions surface: existing SDK code works with a base-URL and key change. Structured output requests use the native support and add validation and repair on top.
Do responses change shape?
No – standard OpenAI JSON, plus X-Guardrails-* response headers. In PREVENT mode a violating request returns a 422 with the findings in the body instead of a completion.
Can I use function calling / tools?
Yes – and that is where the agent guardrails engage: the tool_calls in responses are validated against your tool policy, tiers, grounding, and taint rules before your app acts on them.
What latency does it add?
The deterministic stages add milliseconds; judge and classifier stages cost a model call where enabled. Every stage is timed per request and shown in the dashboard – measured on your traffic.
Related
Keep your OpenAI SDK, change one line
Point your existing OpenAI client at the in/guard/out base URL and every request runs the guardrail pipeline. We are running a limited demo - sign up and we will get you in as soon as we can.