AI agent guardrails: what 05 enforces, and how strongly

CI required checks: hard, but borrowed

A required check in CI is the strongest gate in the picture, because the Git host refuses the push or merge until it passes. That strength belongs to the host, not to 05, and we do not claim it as ours. What 05 supplies is the evidence the check looks at: a signed receipt from the portable runner.

This is the principle behind the design: own the truth, rent the enforcement. Receipts, policy and identity are 05's and work on any host. Git hosts are thin, replaceable enforcement adapters. GitHub comes first. 05 stays on your Git host and does not try to become one.

For how this maps to NIST AI RMF, ISO/IEC 42001 and the TBS guide on agentic AI, see AI agent governance with 05.

Policy that only tightens

Policy lives in a file in the repository. An organisation can add a signed floor above it. Repositories and teams can tighten the floor, never loosen it.

The policy also records the oldest version of use05 that reads it, as [use05] min_version. A teammate or a CI runner on an older version is told to upgrade, instead of failing on a rule it has never seen.

Locked folders and file rules

Some files should never change, and some should change only in one way. You mark them in .05/policy.toml, on whole folders or single files, and each rule says how strict it is:

[protect]
paths = ["infra/**"]                         # a person approves any change here
locked = ["LICENSE", "vendor/**"]            # never changed; no approval clears it
append_only = ["db/migrations/**"]           # new files only; existing ones never edited, renamed or deleted
no_delete = ["docs/**"]                      # may be edited, never deleted
no_read = [".env*", "secrets/**"]            # agents may not open these
absolute = ["NOTICE"]                        # a lock that no bypass can clear
bypass = true                                # false: no bypass clears any of these

• Locked means locked. An agent's edit is refused before it happens, through its file tools or the shell. The gate and the CI gate deny any change that touches the file, and an approval cannot clear it.
• Unlocking is its own change. Rules are read from the change's base, so a change that removes a lock and edits the file in one go is still denied. Removing a lock is an edit to the policy that a person approves and lands first.
• Append-only folders suit database migrations and release notes. A released migration is never edited again; a fix is a new migration. Renames count as edits.
• A person can bypass a rule for one exact change, with their passphrase-protected key and a stated reason, and the brief shows it. You can make a lock absolute, or turn bypass off for every rule. An agent can never bypass.
• Do-not-read is advisory. 05 can only refuse a read the agent's own hooks report: Claude Code's Read, Grep and Glob tools, and shell commands like cat. It is not encryption; keep real secrets out of the repository.

Break-glass, logged

Sometimes a change must land when a gate says no. A break-glass bypass exists for that, and every use is logged, so the exception is visible afterwards.

If 05 itself breaks

It fails open, loudly. The failure is shown, so you are not left believing a check passed when it did not run.