Skip to content
in/guard/out
in/guard/out

How it works

One base URL. Every request checked both ways.

in/guard/out sits between your app and its model. Your app keeps its SDK, its models and its prompts – in/guard/out checks what goes to the model and what comes back.

The path of one request

  1. 1Your app

    Your AI agent sends a request

    Same SDK, same prompts – it just calls in/guard/out instead of the model.

  2. 2in/guard/out

    Checked on the way in

    Private data becomes placeholders, and the request is scanned before a token is spent.

    mask private datainjectionbudget
  3. 3Your model

    LLM model answers

    OpenAI, Claude, OpenRouter or a local model – it receives the masked request, not the real data.

  4. 4in/guard/out

    Checked on the way out

    Figures are checked against the source and every tool call against your rules – then the real data is put back.

    fact-checktool rulesformat & safetyrestore data
  5. 5Your app

    Delivered and recorded

    Your app gets the answer – fixed, or blocked with the reason. Every step is on record, with its cost.

What gets checked, in each direction

On the way in – before the model sees it

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 check

On agent traffic: is this run still inside its cost, step, and tool budgets – and is it going round in circles?

On the way out – before your app sees it

Grounding & fact-check

Arithmetic recomputed, figures matched to the source, unsupported claims flagged by the judge.

Tool-call rules

Every tool call the model proposes is checked: is the tool allowed, are the arguments valid, is it too risky, did its values come from a real source, is private data leaving?

Format & safety

Structured output validated and repaired; profanity and unsafe content censored or blocked.

PII restore

The very last check swaps placeholders back to real values – inside your boundary, not the provider’s.

Live in three steps

1

Change two lines

Point your SDK’s base URL at in/guard/out and use your in/guard/out key.

client = OpenAI(
−   base_url="https://openrouter.ai/api/v1",
−   api_key="sk-or-…",
+   base_url="https://api.inguardout.com/v1",
+   api_key="gr-…",
)
2

Watch first

Checks start in Fix & log: safe fixes are applied, everything else is recorded, nothing is blocked.

3

Block when ready

Switch the checks that matter to Block – per key, per user, or per request.

Two modes: watch first, then block

Fix & log · the default

Repair what’s safe, 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 is blocked.

Block

Stop it, with the reason

A request or answer that fails a check doesn’t get through – your app gets an error with the reason and the findings. Set it per key, per user, or per request, so one workflow can block while another still watches.

What the checks cost you

in/guard/out is built to keep overhead low – but the real cost depends on which checks you turn on, your model, and your traffic. So the dashboard measures it per request instead of quoting one number: each check times itself, and guard-model calls are priced into the request and the run.

Inbound
before your model
  • pii screen
  • injection
  • tool-result scan
  • budget gate
Upstream
the model call
  • LLM (OpenAI, Claude, local LLM, etc.)
Outbound
after your model
  • format
  • fact-check
  • safety
  • tool policy
  • permission
  • action grounding
  • taint
  • conformance
  • sequence
  • pii restore
2
Modes · fix & log / block
3
Ways to connect
1
Record per run

Frequently asked questions

How long does integration actually take?

For model calls: the time it takes to change a base URL and issue an in/guard/out API key. Agent features want one more header – X-Guardrails-Session-Id – so requests group into runs. The checkpoint API and MCP gateway 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 & log – the default – safe repairs are applied (arithmetic corrected, JSON re-parsed, profanity censored) and everything is flagged in the response headers and dashboard. In Block, 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 checks run in milliseconds; classifier and judge checks cost a model call each and only run where enabled. Rather than quote one number, in/guard/out times every check of every request and shows the 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 endpoint; 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.