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

Integrations

Guardrails & fact-checking for the stack you already run

The proxy meets your architecture where it is: an OpenAI-compatible surface for anything with an SDK, a checkpoint API for orchestrators, and an MCP gateway for tool servers. No rewrite is the design goal, not a marketing line.

§02 The three surfaces behind every integration
① The LLM boundary
POST /v1/chat/completions

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.

② MCP gateway
POST /mcp/{server}

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.

③ Checkpoint API
POST /v1/checkpoint

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.

Don’t see your stack? It probably still works.

Anything that speaks the OpenAI API or can POST JSON can use the proxy. Tell us what you run and we’ll tell you the integration path.