About The Harness

ai2rules is an open-source security project aimed at one problem in the era of autonomous developer tools: ambient authority.

When you run an agent like Claude Code or Codex on your machine, it runs as you. It inherits your SSH keys, your production cloud credentials, and write access to everything you own. Nothing about the tool is malicious; the authority is simply yours, and it is handed over whole.

The common answer is to write a better system prompt — "do not delete my files." Prompt injection is the standing proof that this cannot hold: you cannot filter danger with the thing being manipulated. A model asked to police its own inputs is one persuasive input away from not doing so.

The kernel approach

So the decision moves out of the model. You describe what the agent may do in an immutable WorldManifest, and a deterministic kernel decides every proposed tool call against it — before the host acts. A tool absent from the manifest is not merely refused; it is never offered. Data that arrived from somewhere untrusted is marked, and marked data cannot reach an externally-effectful action.

The property that matters is that none of this is a judgement call. The same manifest and the same call always yield the same verdict, the rule that fired is named in the answer, and the whole decision is recorded and replayable. You can disagree with a verdict and go read exactly why it happened.

What is actually governed

Coverage is uneven, and pretending otherwise is the fastest way to lose a reader who checks. Hosts that expose a pre-tool hook — Claude Code, the Antigravity CLI, OpenCode — are governed deeply: every native tool call is decided by the kernel. Hosts that do not are reachable only through their MCP seam, via a gateway that shapes the tool surface and gates each call. Same kernel, same manifest, different depth. Which host lets you control what is measured, host by host, in the Agent Governability Index — including the parameters where our own integration scores badly.

What it is not

It is a decision layer, not a sandbox. It rules on an action before it happens; it does not confine a process that is already running, and it cannot stop a tool that never asks. Command classification reads shell strings, which is a heuristic — the safety comes from unmatched commands falling into a fail-closed bucket, not from the patterns being exhaustive. If you need containment, you need containment. The full list of what this does not protect against, kept current rather than flattering, is in SECURITY.md.

How it is built

The harness governs its own development: the manifest in this repository is the one applied to the agents working on it, so a weakness in the kernel is a weakness the project runs on. That has caught real defects — a policy that two hosts silently disagreed about, a taint marker that stopped being written when a directory was read-only, an in-browser demo quietly running a two-month-old engine.

Findings against our own kernel get a number, a fix, and a written record, whether they came from outside or from us. Every design decision, including the ones later reversed, is in DECISIONS.md with the alternatives that were rejected and why. That trail is the point: a security tool you are asked to trust should be one you can audit instead.