AI platforms & agent builders
Guardrails & checkpoints that meet your orchestrator where it is
Teams shipping agents on n8n, LangChain or MCP – for their own company or for customers.
The step nothing was watching
Your workflow calls a model, and then a plain HTTP node moves the money. Most AI safety tools watch the model call and are blind to the HTTP node – the step that actually does the damage. Meanwhile the MCP server you connected last month quietly changed what its tools do, and nothing told you.
in/guard/out guards all three doors: the model, the tools, and the ordinary workflow steps in between. Your n8n export becomes the rule the running agent has to obey, and a run that crosses all three shows up as one trail.
If you build on n8n, LangChain, or MCP, you already have the workflow – what you lack is enforcement that understands it. Rewriting the stack around a safety SDK is not a realistic ask; pointing a base URL at a proxy is.
in/guard/out covers all three boundaries your agent crosses. The LLM boundary: point your OpenAI-compatible client at it and every request and response runs the guardrail pipeline. The tool boundary: an MCP gateway fronts your MCP servers, inspects each tools/call before it forwards, scans results, and pins the server’s tool manifest against rug-pulls. The workflow boundary: a checkpoint API (with an n8n community node, a LangChain callback, and a plain SDK) gates the deterministic steps – HTTP calls, database writes – that don’t touch a model.
The category-unique piece: upload your n8n workflow export, and it compiles into a runtime sequence policy – your own diagram becomes the enforcement. A run that spans all three surfaces produces one coherent trace in the dashboard.
Where it breaks
- ✕Deterministic steps invisible to an LLM proxy
- ✕Clients that ignore a 422
- ✕Rug-pulled MCP servers
What answers it
- →Checkpoint node before consequential steps
- →MCP gateway enforcement
- →n8n workflow → runtime policy
- →One run graph across every surface
One run, three surfaces
An agent turn emits a payment tool call at the LLM boundary; the workflow’s bank-API node consults the checkpoint API before executing; an MCP tools/call is inspected at the gateway. All three land in the same reconstructed run graph, with the same session id, policies, and audit trail – no orchestrator rewrite involved.
Frequently asked questions
Do I have to change my n8n workflow?
Minimally. Point AI nodes at the in/guard/out base URL, and optionally drop the Guardrails Checkpoint community node before consequential steps. Your workflow export can also be imported to auto-derive a sequence policy.
What does the MCP gateway add over the LLM proxy?
Visibility and enforcement at the tool boundary: it inspects tools/call before forwarding (a deny is a JSON-RPC error the client cannot ignore), scans returned results for injection, and detects a server whose tool manifest changed after you pinned it.
What is the checkpoint API for?
Steps that don’t touch an LLM – an HTTP payment node, a database write. The orchestrator asks “may I proceed?” with the proposed action and gets allow, deny, or require-approval from the same policy engine, recorded in the same run.
Which clients exist today?
An n8n community node, a LangChain callback handler, and a zero-dependency Python SDK; anything that can POST JSON can use the checkpoint API directly.
Other clients
See it on your own traffic.
We’re running a limited demo – sign up and we’ll get you in as soon as we can.