Agents go off the rails. Run yours OnRails.

Written down.
But not reliably enforced.

Agents have gone from co-pilot to operator, but the rules meant to keep them in check still live in AGENTS.md, where the model treats them as advice. That works while you watch.

1. A

   It forgets the rule.

   AGENTS.md says never delete anything under /home. Three hours in, asked to clear build output, the agent runs rm -rf build/ dist/ ~/. The rule was in its context the whole time, but nothing checked the command against it.

2. B

   The guard watches one door.

   A filter on the Bash tool can reject rm -rf ~. It never sees the shutil.rmtree inside a script the agent wrote, or the rm in a make clean recipe. The rule holds on one path and misses the rest.

3. C

   A secret leaves in two steps.

   A debug script reads .env and dumps state to /tmp/out.json. Later, a helper the agent wrote reads that file and posts it. No single tool call looked wrong.

Where each layer holds, and where it doesn’t.

The script is new. The syscalls are not.

In Linux, a program can’t delete a file, start another program or reach the network on its own. It asks the kernel, through a system call. A cleanup can run through rm, find -delete, Python’s shutil.rmtree or a Makefile recipe, and all four make the same request: unlink this file. Write one rule for each intent in your AGENTS.md, and OnRails checks it there, every time the agent makes that request. Rules follow the agent’s process tree however deep it goes, and the same check covers program launches and IPv4 connections.

1. Bash toolclaudebashrm -rf ~/✕ unlink refused
2. find one-linerclaudebashfind ~ -delete✕ unlink refused
3. Python scriptclaudebashpython3 cleanup.py✕ unlink refused
4. Makefile recipeclaudebashmake cleanshrm✕ unlink refused
5. your own shellzshrm ~/old.log✓ not under the agent

$ cat onrails.yamlversion: 1policy: |  source AGENT = exec "**/claude"   rule no-home-deletes:    block unlink file "/home/**" if AGENT    because "Deleting under /home is off limits. Clean up inside /work."

Some rules can’t be judged
from one action.

A filter on one tool call sees one call. OnRails follows the data and remembers the run, across every script and subprocess, so a rule can depend on what came before. The rule isn’t about the call. It’s about what happened first.

$ cat onrails.yamlversion: 1policy: |  source AGENT = exec "**"  source CLAIM = file "/claims/**"   # 198.51.100.20 is the carrier’s claims system.  rule claims-to-carrier:    block connect endpoint "*" if CLAIM unless target "198.51.100.20"    because "Claim data goes only to the carrier’s claims system."

$ cat onrails.yamlversion: 1policy: |  source AGENT = exec "**"   rule stale-approval:    block exec "send-payments" if AGENT      unless after exec "approve-batch" exits 0 since write "/ap/batches/**"    because "This batch changed after its last approval. Run approve-batch, then send."

It doesn’t just say no. It says why.

A rule’s because line is written for the agent. When the rule fires, the agent gets an [OnRails] message that names the rule, quotes your reason and suggests a next step. So it can change course instead of retrying.

The message reaches Claude Code and Codex as hook context, and MCP clients as the onrails:///feedback resource. Any harness can read the per-run file, which keeps every match.

Not what it said. But what it did.

Most agent logs keep what the agent said: prompts, replies and tool calls. OnRails sits where actions reach the kernel, so its record shows what actually ran, including inside scripts and subprocesses that a tool log never sees. Every rule that fires is logged with your reason and where the data came from.

$ jq -r '[.op, .comm, .target, .action, .rule.name] | @tsv' .onrails/events.jsonl | column -texec     claim-summary  /usr/local/bin/claim-summary  report  record-launchesexec     curl           /usr/bin/curl                 report  record-launchesconnect  curl           203.0.113.7                   block   claims-to-carrierexec     claims-upload  /usr/local/bin/claims-upload  report  record-launchesconnect  claims-upload  198.51.100.20                 report  record-connections $ jq 'select(.action == "block") | {reason: .rule.reason, from: .provenance.origin_target}' .onrails/events.jsonl{  "reason": "Claim data goes only to the carrier’s claims system.",  "from": "/claims/CLM-2291/claim.pdf"}

• For compliance

  Each refusal with its rule, your reason and where the data came from. Evidence that the control ran.

• For review

  Read any run back, step by step, long after it ended.

• For evals and RL

  Each refusal marks a wrong step, and why, as one line of JSON.

Every rule match is recorded as it happens. Add a notify rule for anything else you want on the record, such as every program the agent starts or every connection it opens. It flags without stopping anything.

It works where you work.

OnRails runs in the Linux kernel your agent already uses, with or without a sandbox around it. It works with any agent because it checks system calls, not a particular harness. A sandbox sets where the agent can go. OnRails adds rules for what the agent does there and leaves your isolation in place.