Guardrails proxy for AI apps: fact-checking, PII security, observability

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

LLMs get more expensive with every version. Even the newest ones can mess up the facts. And if you’re cost-conscious, the odds of hallucination are even higher.

With in/guard/out, you secure sensitive customer data, guardrail AI agents and MCP calls, and fact-check the results. Every action an AI agent attempts – every tool call, every MCP request – is checked against your policy before it runs. It’s as simple as swapping two lines of code.

Your appOpenAI · Claude · n8n · LangChain · MCP client

in/guard/out

screenfact-checkinspectmeter

LLMOpenAI · Claude · OpenRouter · local

Every request & response passes through the wire

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 didn’t 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 →

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-…",
)

That's it – 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.

in/guard/out 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.

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 didn’t support. in/guard/out checks every answer against what the user actually provided – and the first, most important pass isdeterministic, so it costs nothing and doesn’t hallucinate 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” isn’t 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 report4 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⁴.

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

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

in/guard/out 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, in/guard/out 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 haven’t had of their own agent.

How agent security works →

Runs · reconstructed run graph

1 blocked

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

#1openai/gpt-4ook
readsearch_orders{"order_id":"4471"}↻2
#2openai/gpt-4ook
injection
#3openai/gpt-4ook
networksend_email{"to":"<EMAIL_ADDRESS_1>"}
taint
#4checkpointblocked
paymentpay_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

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 in/guard/out watch your runs and learn what normal looks like.

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

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.

③POST /v1/checkpoint

Checkpoint API

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.

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.

How it runs, and what it costs you

in/guard/out 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