Reins: A Pre-Execution Gate for AI Agent Actions
Stop AI agents from doing things you didn't ask for.
At a glance
- What is it?
- Reins is an Apache-2.0 policy engine that intercepts agent tool calls through Claude Code hooks and MCP, blocks destructive actions before they run, and writes an append-only decision log. The useful part is the synchronous, fail-closed hook. The open question is how much of your security posture ends up depending on a project still on 0.0.x.
- Who is it for?
- Adopt Reins if you run Claude Code or an MCP-compatible agent that touches destructive tools (bulk deletion, browser automation, shell commands) and you want a synchronous, fail-closed gate plus a machine-readable decision log. Do not adopt it as your only control if your agents run outside the hook surface it supports, or if you cannot tolerate a 0.0.x dependency in the enforcement path.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 116 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Reins targets: agents that act before anyone can object
The README frames the project around a single failure mode: an agent doing something the operator did not ask for. The demo described there is an OpenClaw agent attempting to bulk-delete 4,382 Gmail messages, with Reins blocking the action before execution. That is the shape of the problem. An agent with tool access is a process with credentials, and the distance between a plausible-looking plan and an irreversible side effect can be one tool call. Reviewing transcripts after the fact does not undo a deletion.
Reins is aimed at engineers who already run agents with real permissions and want a checkpoint in front of the tool call rather than a dashboard behind it. The README lists three jobs: prevent destructive actions, pause high-impact ones for approval, and prove what happened via an audit trail. The audience is narrow by design. If your agent only reads files, a policy gate adds latency for little gain. If your agent can send mail, delete records, or drive a browser, the pre-execution check is the whole point.
How the hook mechanism works, and why synchronous matters
According to the README, Reins works with Claude Code PreToolUse and PostToolUse hooks, OpenClaw, and any MCP-compatible agent. The PreToolUse hook is the enforcement point: the agent's proposed action is evaluated against policies before it executes. The README states that policies evaluate in under 50ms and that no network is required in the hot path because policies are cached locally and enforced offline.
The design property that matters most is the one the README calls synchronous: the agent cannot proceed until the hook exits. Combined with fail-closed behaviour, where any unhandled hook error blocks the action, this inverts the usual default. Most observability tooling is passive and fails open, meaning a broken collector produces silence and the agent keeps running. Reins fails closed, so a broken hook produces a blocked agent. That is the right trade for destructive tools and the wrong trade for a production agent where availability matters more than the specific action being attempted. You should decide which of those you are before installing it.
The second mechanism is the pause path. High-impact actions can be routed through terminal or messaging approval flows, and the README says catastrophic operations require explicit CONFIRM-* tokens. The audit trail is append-only JSONL at ~/.openclaw/reins/decisions.jsonl, which is a format you can ship into an existing log pipeline without writing a parser. The README also mentions scanning configs for OWASP ASI10 vulnerabilities and tracking drift over time, though the README does not specify what drift is measured against.
Installing and wiring it into Claude Code
The README gives two setup paths. The CLI is distributed on npm as @pegasi-ai/reins and installed globally:
npm install -g @pegasi-ai/reins reins init
The package name in the install command is @pegasi-ai/reins, while the npm badge in the README points at clawreins. That discrepancy is worth resolving before you script anything around the package name. The README requires Node.js >= 18.0.0.
For Claude Code, the README offers a skill that gives the agent awareness of your security posture, installed by fetching a single markdown file:
mkdir -p ~/.claude/skills/reins curl -o ~/.claude/skills/reins/SKILL.md \ https://raw.githubusercontent.com/pegasi-ai/reins/main/.claude/skills/reins/SKILL.md
Alternatively the README notes the skill is included at .claude/skills/reins/ if you clone the repository. Note that this curl pulls from the main branch rather than a tagged release, so the skill file you install is whatever main currently holds. If you care about reproducibility, clone and pin a tag instead. The README does not document the hook configuration keys themselves; it points to reins.sh/docs for the CLI reference and policy documentation, so the exact settings you edit to register the PreToolUse hook are not visible in the repository README alone.
Fail-closed is a real constraint, not a slogan
The strongest claim in the README is also the one most likely to bite. Fail-closed means an unhandled hook error blocks the action. Consider the failure modes that follow. If the Reins CLI is upgraded or removed while a hook is registered, the hook invocation fails and the agent stops. If the local policy cache is missing or unreadable, the same thing happens. If the hook exceeds whatever timeout the host applies, the outcome depends on how the host treats a timed-out hook, and the README does not say. None of these are bugs; they are the intended behaviour of a gate that defaults to denial. But they mean Reins belongs in the same category as a firewall rule, not the same category as a linter. You need a rollback path that does not require the agent to run.
The second limitation is coverage. The README names Claude Code hooks, OpenClaw, and MCP-compatible agents. Any agent that invokes tools outside those surfaces is not gated, and a policy engine that covers some of your execution paths can create a false sense of completeness. If you run agents in three frameworks, Reins covers the ones it integrates with and nothing else. The README does not describe a generic interception layer for arbitrary Python processes, which is notable given the repository's primary language is listed as Python while the install path and badges are Node and TypeScript.
Where Reins sits next to a sandbox like gVisor or a container runtime
The natural alternative is not another policy engine but process isolation: run the agent inside a container or a sandboxed runtime and constrain what it can reach at the syscall and filesystem level. That approach and Reins differ in where the decision is made. A sandbox decides what is reachable; it does not know that deleting 4,382 messages is different from deleting one, because both are the same write operation. Reins decides at the semantic level of the tool call, which is why it can score irreversibility and require a CONFIRM-* token for a specific class of action.
The trade runs the other way too. A sandbox does not depend on the agent framework emitting a hook, and it does not care whether the tool call arrives through MCP, a shell, or a library import. Reins only sees what its integrations surface. If your threat model is a misbehaving agent using tools it legitimately has, Reins is the closer fit. If your threat model is an agent that can be induced to run arbitrary code, sandboxing addresses a layer Reins does not claim to cover. The two are complementary, and the README does not present Reins as a replacement for isolation.
Version 0.0.22, release cadence, and what that implies for maintenance
The release history is short and recent: v0.0.1-beta in February 2026, beta-0.0.2 in April, and 0.0.22 (labelled Watchtower Integration) on 2026-04-14, with the last push to main on 2026-05-22. The jump from 0.0.2 to 0.0.22 in a week suggests rapid iteration rather than a stabilised interface. For a component in the enforcement path, that matters. A breaking change in policy schema or hook behaviour is a change to what your agent is allowed to do.
The practical cost is not the install; it is the pinning and the review. Plan on pinning the npm package version and cloning the skill file from a tag rather than curling main, then reading the diff before each bump. The audit log format is plain JSONL at ~/.openclaw/reins/decisions.jsonl, so downstream consumers are relatively insulated from internal changes, but the policy definitions are not. The README does not describe a schema version field or a migration path for policies, which is something to check in the docs before you write a large policy set.
On licensing: the repository is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant. That is a permissive choice consistent with embedding the CLI in an internal toolchain. It is not legal advice, and if you redistribute Reins inside a product you should read the LICENSE and NOTICE handling yourself.
What to check before you put Reins in front of a real agent
The README's security guarantees are testable claims, and you should test them rather than assume them. Three checks are worth running in a staging agent before rollout. First, break the hook deliberately (rename the CLI binary, corrupt the policy cache) and confirm the tool call is actually blocked rather than silently allowed. Second, exercise the pause path and confirm that the CONFIRM-* token has to come from a channel the agent itself cannot write to; if the agent can produce the token, the approval flow is decorative. Third, confirm the JSONL decisions file lands where your log shipper expects and survives rotation.
Beyond that, the README points to reins.sh/docs for the policy reference, architecture notes, and a cloud offering. The architecture page is the one to read if you need to know exactly which hook events are intercepted and what happens on timeout, because the README does not cover either. Reins is a small, focused tool with a clear mechanism and an honest default. Its value depends entirely on whether the surface it covers matches the surface your agents actually use.
Editorial conclusion
Adopt Reins if you run Claude Code or an MCP-compatible agent that touches destructive tools (bulk deletion, browser automation, shell commands) and you want a synchronous, fail-closed gate plus a machine-readable decision log. Do not adopt it as your only control if your agents run outside the hook surface it supports, or if you cannot tolerate a 0.0.x dependency in the enforcement path. Before trusting it, verify three things yourself: that a hook error actually blocks the tool call in your setup, that a CONFIRM-* token cannot be produced by the same agent that triggered the pause, and that ~/.openclaw/reins/decisions.jsonl is written where your log pipeline can pick it up.
Community notes