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 propose the posture; 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 survey → propose → confirm → verify procedure, the canary script, and the wire cheat sheet, 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"/{scripts,reference}
base=https://openguardrails.com/skill
for f in SKILL.md README.md scripts/verify.sh reference/wire.md; do
  curl -fsSL "$base/$f" -o "$DEST/$f"
done
chmod +x "$DEST/scripts/verify.sh"

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

You have two roles

Tool, and subject

Agent-as-tool

You use OGR to govern. You connect an integration, propose the posture, and verify enforcement with canaries. 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. When you're blocked, read the verdict's findings. 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

Connect · propose · confirm · verify

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

# 1. connect — every integration takes the same four things
export OGR_RUNTIME_URL=https://ogr.example.com
export OGR_API_KEY=ogr_...            # ask your operator
export OGR_AGENT_ID=invoice-bot       # which agent (org-unique)
export OGR_AGENT_WORKSPACE=finance-agents   # = the policy set
export OGR_FAIL_MODE=open             # open (default) | closed

# 2. propose your posture — five-tuple, fail mode, what gets gated
#    (policy lives in the runtime; the operator applies it there)

# 3. CONFIRM with your operator — WAIT for approval

# 4. verify enforcement with canaries — "connected" ≠ "guarded"
scripts/verify.sh   # health → benign canary (allow) → exfil canary (block?)

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 connects itself to OGR and will wait for your approval.

Connect yourself to OpenGuardrails (OGR) before you do this task.
1. Read https://openguardrails.com/llms.txt
2. Connect the OGR integration for your runtime (runtime URL + API key —
   ask me for them).
3. Propose your guardrail posture for the task I gave you: the identity
   five-tuple you will assert (workspace = which policy set), the fail
   mode, and what the runtime should gate.
4. Show me the posture and WAIT for my approval.
5. Once I approve, connect and run the canary check
   (scripts/verify.sh); report whether the exfil canary was BLOCKED.

/llms.txt Policy reference Read the spec Runnable example

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