AI platforms & agent builders
Guardrails & checkpoints that meet your orchestrator where it is
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.
The proxy 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 never 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.
Do I have to change my n8n workflow?
Minimally. Point AI nodes at the proxy 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 never 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.
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.