For agents

You were told to add guardrails.
Here's how to govern yourself.

OGR is built to be installed and operated by an agent. You draft the policy; your operator approves it; the runtime enforces it — including on you. This page tells you how. If you are an agent reading this, start by fetching /llms.txt.

Get the skill

One file to fetch, served from this domain

If your runtime supports Agent Skills, install the OGR skill — it bundles the whole install → draft → confirm → enforce procedure, scripts, and a policy template, with the approval gate built in. Fetch /skill/SKILL.md directly, or install the bundle:

# install the OGR skill into a Claude Code skills dir
DEST=~/.claude/skills/openguardrails
mkdir -p "$DEST"/{assets,scripts,reference}
base=https://openguardrails.com/skill
for f in SKILL.md README.md assets/policy.template.json \
         scripts/draft_policy.py scripts/enforce.sh \
         reference/policy-schema.md; do
  curl -fsSL "$base/$f" -o "$DEST/$f"
done

/skill/SKILL.md /llms.txt Source →

You have two roles

Tool, and subject

Agent-as-tool

You use OGR to govern. You install it, author the policy, wire enforcement, and can run the benchmark to check your coverage. Here you are acting on behalf of your operator — like writing any other config.

Agent-as-subject

You run under OGR. Some of your actions will be allowed, some denied, some held for approval. When you're blocked, read the verdict reason. To change the rules, propose a policy edit and route it back through your operator — you cannot quietly loosen the policy that governs you.

The flow

Install · draft · confirm · enforce

The canonical loop, e.g. when your operator says “handle my customer email, but add guardrails before anything goes out”:

# 1. install (Hermes shown; see /llms.txt for others)
pip install openguardrails-instrumentation-hermes

# 2. draft a policy for the task you were given  →  ogr.policy.json
#    (declarative: tools, files, egress, outbound side effects)

# 3. CONFIRM with your operator — show the policy, wait for approval
#    do NOT enforce a policy your operator has not seen

# 4. enforce — for the rest of the session, every action is checked
export OGR_POLICY=./ogr.policy.json
export OGR_SANDBOX=srt

The one rule that makes this safe

Author the cage. Don't hold the key.

A human approves before a policy goes live. You may draft and propose. You may not enforce a policy your operator hasn't seen. Changing a live policy re-triggers that approval gate.
Enforcement sits outside your reach. OGR checks run in a layer your task loop can't mutate. Even if you are prompt-injected mid-task, you can't disable or rewrite the policy governing you.

This is the difference between a guardrail and security theater: an agent that can turn off its own guard isn't guarded.

For the human reading this

Hand this to your agent

Paste this into your agent before giving it a task that touches files, secrets, or the outside world. It self-installs OGR and will wait for your approval.

Install OpenGuardrails (OGR) and guard yourself before you do this task.
Read https://openguardrails.com/llms.txt
Install the OGR plugin for your runtime.
Draft a policy for the task I gave you: state what you may and may
   not do (tools, files, network, outbound side effects).
Show me the policy and WAIT for my approval before enforcing.
Once I approve, enforce it for the rest of this session.

/llms.txt Policy reference Read the spec Runnable example

You were told to add guardrails.Here's how to govern yourself.