How it works
One base URL. Every request guarded.
in/guard/out speaks the OpenAI API on the front and your providers on the back. Your app keeps its SDK, its models, and its prompts – the guardrail pipeline runs on what crosses the wire, in both directions.
One step to start
Change two lines
Swap the base URL to in/guard/out and provide your API key.
client = OpenAI(
− base_url="https://openrouter.ai/api/v1",
− api_key="sk-or-…",
+ base_url="https://api.inguardout.com/v1",
+ api_key="gr-…",
)You’re now live. Requests flow through the full guardrail pipeline. Fine-tune policies and settings in the dashboard whenever you’re ready.
The pipeline, both directions
PII screening
Names, emails, cards, IDs become reversible placeholders before anything leaves for the provider.
Injection defense
Deterministic patterns plus a dedicated injection classifier score the input; untrusted tool results get the same scan.
Input safety
Abusive or off-policy prompts are caught before they spend a single token upstream.
Budget & loop gate
On agent traffic: is this run still inside its cost, step, and tool budgets – and is it looping?
Grounding & fact-check
Arithmetic recomputed, figures matched to source, unsupported claims flagged by the judge.
Tool-call policy
Allow/deny, schema validation, risk tiers, action grounding, and taint checks on every proposed tool call.
Format & safety
Structured output validated and repaired; profanity and unsafe content censored or blocked.
PII restore
The very last stage swaps placeholders back to real values – inside your boundary, not the provider’s.
Every stage times itself, so the dashboard shows the exact overhead each check added to each request – the “guardrail tax” as a measured number, not a promise.
Two modes: observe first, then enforce
Repair what’s repairable, record the rest
Wrong arithmetic corrected in place, malformed JSON re-parsed, profanity censored – and every finding flagged in headers and the dashboard. The mode to start in: you see what would be caught before anything blocks.
Fail closed
A violating request or response doesn’t get through – your app receives a 422 with the reason and the findings. Set per key, per user, or per request, so one workflow can enforce while another still observes.
Three surfaces, one policy engine
The core vantage point – it sees everything the model sees: the full context, the declared tools, the chosen actions, and the sources those actions should be grounded in. Point any OpenAI SDK at it.
in/guard/out speaks MCP between the agent and its servers. It inspects tools/call before forwarding – a deny is an error the client can’t ignore – scans the returned result, and pins the tool manifest.
A Policy Decision Point for steps that don’t touch an LLM. Ask "may I proceed?" and get allow / deny / require-approval. Drop-in clients: an n8n node, a LangChain callback, a Python SDK.
A run that crosses all three – model calls, workflow checkpoints, MCP tool calls – lands in a single run graph with one session id, one budget, and one audit trail.
Works with your stack
OpenAI
The GPT series behind one base-URL swap – any OpenAI SDK, any language, zero new client code.
Claude (Anthropic)
Opus, Sonnet, and Haiku tiers – keep your Anthropic SDK; the full pipeline, tool inspection included, runs natively.
OpenRouter
Gemini, Gemma, Llama, DeepSeek, Qwen, Mistral, Kimi, GLM, Grok and hundreds more – one pipeline judging every model by the same standard.
Local models (LM Studio)
Point in/guard/out at a local OpenAI-compatible server and the same pipeline guards local model traffic.
n8n
Point AI nodes at in/guard/out; add the Checkpoint community node before consequential steps; import your workflow export as an enforced sequence policy.
LangChain
The base URL swap covers model calls; a callback handler consults the checkpoint API around tool execution.
MCP servers
Register a server and route the client through the gateway URL – tools/call inspection, result scanning, manifest pinning.
Anything that can POST JSON
The checkpoint API is a plain HTTP policy decision point – allow, deny, or require-approval for any step in any orchestrator.
Frequently asked questions
How long does integration actually take?
For the LLM boundary: the time it takes to change a base URL and issue a proxy API key. Agent features want one more header – X-Guardrails-Session-Id – so requests group into runs. Checkpoint and MCP gateway surfaces are opt-in additions, not prerequisites.
Do I need to change my prompts or models?
No. in/guard/out is model-agnostic and prompt-agnostic: it enforces on what crosses the wire. You keep your provider account, your models, and your prompts; you can also keep your provider key and let in/guard/out forward with it.
What happens when a check fails?
Depends on the mode. In FIX, safe repairs are applied (arithmetic corrected, JSON re-parsed, profanity censored) and everything is flagged in the response headers and dashboard. In PREVENT, the request fails closed with a 422 carrying the reason – your code handles it like any API error.
Does it support streaming?
Streaming responses are buffered in the current version: most guardrails need the complete output before they can pass judgment on it (you cannot fact-check half an answer). Documented, deliberate, and on the roadmap for token-level checks that allow it.
What latency does the pipeline add?
The deterministic stages run in milliseconds; classifier and judge stages cost a model call each and only run where enabled. Rather than quote one number, in/guard/out times every stage of every request and shows the per-stage overhead in the dashboard – measured on your traffic, not our benchmark.
Where does it run?
in/guard/out is a cloud-based SaaS service. Your applications point their LLM clients at our hosted proxy; traffic is screened and routed to your chosen upstream providers. A sandbox demo exists so you can test behavior before pointing production traffic at it.
The integration is a base URL. Try it.
We’re running a limited demo – sign up and we’ll get you in as soon as we can.