Integrations
OGR binds guardrails at three integration points: the agent hook, the
gateway hook, and the sandbox hook. Each binding emits the same
GuardEvent and consumes the same Verdict, so one policy can correlate a
logical action across all three boundaries.
The fastest agent-hook path is Claude Code: install a plugin and risky tool calls are gated even in bypass mode. The deepest reference integration secures a Hermes agent across every altitude, with a choice of sandbox backend.
The runnable gateway-hook integration shows how an OpenAI/Anthropic gateway normalizes wire requests and responses into OGR events. It is an integration example, not an OpenGuardrails-operated service.
The Hermes reference below shows the full picture: the agent connects to OGR once, then you choose an enforcement backend for the sandbox altitude. You write guardrails in one OGR policy model that compiles to either backend; the policy content differs, because a personal assistant and a multi-tenant agent are different security and infrastructure problems.
Two deployments, one policy model
| Personal assistant | Multi-tenant agent | |
|---|---|---|
| Backend | Anthropic srt | NVIDIA OpenShell |
| Isolation | OS-level (sandbox-exec / bubblewrap), no container | Docker/K8s container + gateway, per tenant |
| Network | per-process domain allowlist | central OPA/Rego egress proxy |
| Threat model | trusted user, untrusted inputs | untrusted tenants and workloads |
| Best for | one developer, one laptop | shared / multi-tenant service |
| Policy | OGR sandbox block — guards your host | OGR sandbox block — deny-by-default, no host FS, hard per-tenant limits |
The portability is the model, not the file: one schema, one integration. You still author the policy that fits each deployment — the multi-tenant one is much stricter — but you write it once in OGR instead of hand-coding srt JSON for the laptop and Rego for the cluster. Security is policy, compiled to each backend.
Standalone Anthropic srt and NVIDIA OpenShell sandbox-hook examples will be
added under integrations/; the Hermes integration currently demonstrates both
backends.
An ebpf integration category
is also reserved for future kernel-level process, filesystem, and network
adapters. These adapters reuse the OGR contract and correlate with the three
existing observation points.
How Hermes connects to OGR
Hermes needs no fork and no proxy — it already exposes the hooks OGR needs. The
ogr-guard plugin binds them:
| OGR altitude | Hermes surface | Enforces |
|---|---|---|
| gateway | pre_api_request / post_api_request hooks | observe + taint |
| agent_hook | pre_tool_call hook | block before dispatch |
| (provenance) | post_tool_call hook | taint web/MCP results |
| sandbox | wraps BaseEnvironment.execute | run exec under srt / route to OpenShell |
One Runtime + one policy drive all altitudes, correlated by guard_id. The same
integration runs in both deployments; only the policy and the sandbox backend change.
Choose your path
- Claude Code — install a plugin; a
PreToolUsehook denies risky tool calls (curl|bash, obfuscated exec, egress, credential reads) before they run, even in bypass mode. - Gateway hook — integrate OpenAI/Anthropic wire traffic with OGR.
- Hermes + srt (personal) — 5-minute laptop setup, OS-level enforcement.
- Hermes + OpenShell (team) — container isolation + central policy.
- Instrument your own agent — the same pattern for a non-Hermes framework.