OpenAI-compatible guardrails proxy

See what your AI agent actually did – and stop what it shouldn’t.

Your AI agents call real tools with real credentials. The proxy checks every action before it runs, keeps private data from leaking, and fact-checks every answer against its source – with a one-line change to your app.

Your app OpenAI SDK · n8n · LangChain · MCP client

in/guard/out

screengroundinspectmeter

LLM OpenAI · Claude · OpenRouter · local

Every request & response passes through the wire

§00 What it does

AI agent security

Every action is checked before it runs

A tool call has to pass your policy first: what the agent may call, up to which risk level, within which budget. A payment to an account the agent never read about simply doesn’t execute.

Agent security →

Data protection

Private data stays private

Names, emails, cards and IDs are masked before anything reaches the model provider, and restored on the way back. Screened data can’t leave through a tool call either.

PII screening →

Fact-checking

Wrong answers get caught

Every response is checked against its source: the math is recomputed, figures are matched, unsupported claims are flagged. Safe fixes are applied automatically.

Fact-checking →

>_Two steps to start

Step 1

Change one line of code

Swap your base URL from your LLM provider to In Guard Out. That's it.

client = OpenAI(
    base_url="https://api.inguardout.com/v1",
    api_key="gr-…",
)

Step 2

Whitelist your IP

Add your IPv4 and IPv6 addresses in the In Guard Out console. Our firewall will block anything else.

Once these two steps are done, you're live and protected. Fine-tune policies and settings whenever you're ready.

The premise

AI models aren’t getting cheaper. Your reputation is still on you.

Each new frontier AI model tends to cost more – and sometimes runs slower – than the last. So teams reach for cheaper, faster models to keep latency and spend in check. That’s the right call for the business; it just leaves the output less guarded.

The proxy stands before and after the model and adds the verification back: it screens sensitive data on the way out, and fact-checks, grounds, and inspects the answer on the way back. Use the cost-effective model – the guarantees don’t have to come from it.

Before the model

Screen PII & secrets, scan for injection, enforce budgets – so nothing sensitive or unsafe reaches the provider.

After the model

Fact-check, ground every figure, enforce format & policy, restore data – so a cheaper model’s output still meets your bar.

§01 Hallucination prevention & fact-checking

Our most important check

Catch the invented number before it reaches a decision.

Most hallucinations that matter are quiet: a figure that drifts from the source, arithmetic that doesn’t add up, a confident claim the data never supported. The proxy checks every answer against what the user actually provided – and the first, most important pass is deterministic, so it costs nothing and never hallucinates about hallucinations.

When the math is clean but the claim still smells wrong, an LLM judge and optional retrieval take over. Layered cheapest-first, so you only pay for the depth a given answer needs. More on fact-checking →

Deterministic

Numeric grounding · zero model cost

Recomputes every arithmetic claim, flags figures that drift from the source, and catches directional contradictions – “up 12%” when the numbers went down. It runs inline, with no extra model round-trip.

LLM judge

Fact & consistency check · one guard-model call

A guard model catches what arithmetic can’t: internal contradictions, claims false by common world knowledge, and overconfident extrapolation. An honest “I don’t know” is never punished – only unhedged certainty without support.

External grounding

Check against a source of truth · opt-in, priced per run

When a claim needs outside verification, ground it against an independent source – each sub-call metered into the request and the run.

RAG

your vector store (pgvector)

Web search

live results via Bright Data

Consilium

a second model as a critic

Private data (MCP) Soon

check a claim against a private source

Grounding report 4 caught

Source the user provided

July revenue: $2.4M · August revenue: $1.8M · Prior quarter total: $4.6M

What the model answered

Combined July–August revenue was $4.5M¹, and August alone reached $1.9M². That’s up 14%³ on the prior quarter – the strongest stretch since the firm was founded in 1798⁴.

1 Deterministic Arithmetic – 2.4 + 1.8 = 4.2 – the model said 4.5.
2 Deterministic Altered figure – August is $1.8M in the source, not $1.9M.
3 Deterministic Contradiction – “up 14%” but $4.6M → $4.2M is a decrease.
4 Judge Unsupported claim – “Founded in 1798” appears nowhere in the source.

An honest “I don’t know” or a clearly hedged estimate is never flagged – only unhedged certainty the source can’t support.

§02 Why a proxy can see the whole agent

The proxy sees the whole run, not one request at a time.

Agent loops resend everything on every step – the system prompt, every prior turn, every tool call, every result. By step #7, the proxy has seen steps #1–6 in full. Tied together by a session id, that becomes a complete picture of the run as it happens.

That picture is what run-level rules are enforced on – budgets, loops, ordering – and it’s a view most teams have never had of their own agent.

How agent security works →

Runs · reconstructed run graph

1 blocked

SESSION run-4f9c21 STEPS 4 TOOL CALLS 3 COST $0.0143 COVERAGE 1/1

#1 openai/gpt-4o ok

read search_orders {"order_id":"4471"} ↻2
#2 openai/gpt-4o ok

injection
#3 openai/gpt-4o ok

network send_email {"to":"<EMAIL_ADDRESS_1>"}

taint
#4 checkpoint blocked

payment pay_via_bank {"iban":"DE89…"}

ungrounded

What it caught

injection
poisoned tool result, step 2
taint
screened email leaving via send_email
ungrounded
IBAN absent from the run’s sources
↻ repeat
same call fingerprint as step 1

§03 Two classes of protection

Invariants

Rules that protect any AI agent – no setup needed.

Tool results are untrusted, so they’re scanned. Private data must not leave through a tool call. A payment’s account number must exist in what the agent actually read. Runs have hard budgets, and a call repeating over and over is a loop. None of this needs to know what your workflow is for – like a firewall.

Conformance

Rules about order: “pay only after the lookup”.

These need to know what you intended – and that’s usually already written down: in the system prompt, or in the n8n workflow you already have (upload it, get an enforced policy). Or let the proxy watch your runs and learn what normal looks like.

§04 One engine, three surfaces

The LLM boundary stays the core – it’s the only place that sees everything the model sees. Two more surfaces cover the blind spots, reusing the same policy engine, ledger, and audit trail.

① POST /v1/chat/completions

The LLM boundary

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.

② POST /mcp/{server}

MCP gateway

The proxy 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.

③ POST /v1/checkpoint

Checkpoint API

A Policy Decision Point for steps that never 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.

§05 Prevent vs Fix – try it

Block it, or record it and learn.

Every check runs in two modes. Prevent blocks the offending content or action and returns a 422 the caller can’t ignore. Fix repairs what’s safely repairable and records the rest – observe-first, so you understand your traffic before you enforce on it.

Pick an action and watch it move through the outbound stages.

Try it · one action through the outbound stages

Proposed action

Stage verdictsBlocked (422)

pay_via_bank { "iban": "GB29 NWBK…", "amount": 250 }

allowtool_policypassed
denypermission_checkpayment tier – over authorized ceiling
denyaction_groundingIBAN appears nowhere in the run’s sources
allowtaintpassed

Prevent blocks the offending action and returns a 422 the caller can’t ignore.

§06 How it runs, and what it costs you

The proxy is engineered to keep overhead low – but the real “guardrail tax” depends on which checks you enable, your model, and your traffic, so the dashboard measures it per request instead of quoting a single number. Each stage times itself (offline compute vs. network wait), and guard-model sub-calls are priced into the request and the run.

Inbound

before your model