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

Integrations

Guardrails & fact-checking for the stack you already run

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

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}

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.

③ Checkpoint API
POST /v1/checkpoint

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.

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

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