The Keel Agent Governance Specification (SPEC.md, version 0.2) specifies two portable things independently of any agent runtime: (1) the Keel permission model — how an autonomous agent decides whether it may act or must stop and get a clear yes from a human, and (2) theDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/quitohooded/keel-skills/llms.txt
Use this file to discover all available pages before exploring further.
AGENT_POLICY.md format — the per-project configuration file that tells a conforming implementation what this project treats as risky, where its source of truth lives, and what approvals already stand. An implementation that satisfies the Conformance section may describe itself as Keel-compatible.
Spec version: 0.2 — Status: open draft — License: MIT — Maintainer: Esteban Aguilar (github.com/quitohooded)This version replaces the old code names
L1 / L2 / L3 with plain words: a goal (was L1), a method (was L2), and a green light (was L3). Same model, readable names.§1 Terminology
The following terms have precise meanings throughout this specification.- Agent — an autonomous or semi-autonomous LLM-driven process that can take actions (write files, run commands, call tools, send messages).
- Action — anything the agent does that writes, edits, commits, pushes, deploys, sends, publishes, charges, deletes, or reconfigures a system. Reading, searching, and analysis are not actions in this sense.
- Hot zone — a path, surface, or action where a mistake is expensive or hard to undo. (See §4.)
- Source-of-truth file — a file other work depends on.
- Goal / Method / Green light — the three things that get confused with permission; only one of them is. (See §2.)
§2 The Permission Model
Three things look like permission. Only one of them lets the agent act.A Goal
A direction with no specific scope: “improve this”, “do what’s needed”, “handle it”, “make it better”. Does NOT let the agent act. It lets the agent look into it and write up a clearly-labeled proposal.
A Method
The human names how: “use a migration”, “edit the config”, “use a subagent”. Naming the method is not approving the action. Does NOT let the agent act.
A Green Light
Either (a) the human clearly approves a specific action together with its scope, or (b) a written-down, still-current decision already covers that scope. A green light lets the agent act — and the agent MUST NOT go beyond the approved scope.
§3 The Four-Step Check
A conforming implementation MUST run this check before any action (per §1). The first step that applies wins.Read-only, looking into something, or writing a proposal?
Free. Act. Read-only operations, analysis, and clearly-labeled proposals do not need a green light.
Does it touch a hot zone (§4)?
Needs a green light. Hot zones are listed in §4 with project-specific refinements in
AGENT_POLICY.md.Does it build/reconfigure a system, or is it a chain whose combined effect rebuilds something?
Needs a green light — even if each individual step is tiny. The whole-picture effect determines the level, not the granularity of any single change.
- Risk wins — if something is both “free” and “hot”, it needs a green light.
- The whole picture wins — a system-rebuilding effect needs a green light even when delivered in small steps.
- Doubt resolves toward stopping.
§4 Hot Zones
A conforming implementation MUST treat the following as hot by default. A project MAY refine the specifics in itsAGENT_POLICY.md, but MUST NOT remove a category wholesale.
| Category | What it covers |
|---|---|
| Anything users or the public see | Published copy, marketing pages, public APIs, user-visible UI. |
| Production, databases, schema, settings, hooks, CI/CD | Anything that runs in or shapes the live system. |
| Actions that reach outside or can’t be undone | Commit, push, deploy, send an email or message, publish, charge money, delete data. |
| Turning a draft into a decision | Marking something [APPROVED] / [CONFIRMED] is itself a risky action. |
| Source-of-truth files | Files other work depends on. New decisions, meaning-changing edits, or other changes need a green light, except following through (§5). |
In a repository the agent does not know well, a file’s reach is risky until the agent understands how far it goes.
§5 Following Through on a Green Light
A change that comes straight out of an already-approved decision MAY run without a new green light only if it meets all four conditions:- No judgment needed — two people applying the same decision produce the same change.
- The decision states the scope — it is not being guessed.
- The change points back to the source decision.
- The decision is still current — nothing later has overridden it.
§6 Delegation (Optional)
An implementation that supports subagents SHOULD enforce:- A subagent cannot approve, confirm, or act in a hot zone on its own say-so. Permission always returns to the human (or to a parent acting under a human’s green light). Delegation never creates permission out of thin air.
- Cheapest-capable model selection; the cheapest tier never spawns subagents; maximum nesting depth 2; no self-escalation.
§7 The AGENT_POLICY.md Format
A project configures a conforming implementation through a single Markdown file at its root, namedAGENT_POLICY.md. It SHOULD contain these sections (all may be brief; empty optional sections may be omitted):
| # | Section | Required | Purpose |
|---|---|---|---|
| 1 | Hot zones | yes | Concrete paths/surfaces/actions that need a green light. |
| 2 | Source-of-truth files | yes | Files where only following-through runs without a green light. |
| 3 | Where state and decisions get recorded | yes | Decisions log, project-state file, per-task notes. |
| 4 | Model tier overrides | no | Project-specific overrides of the delegation defaults. |
| 5 | Definitions for this project | no | Pin down “undoable”, “internal”, “release”, etc. |
| 6 | Standing approvals | no | Written decisions that grant a green light in advance for a defined scope. Each MUST state its scope explicitly. |
- Hot zones MUST be concrete (a real path or a real action). Vague hot zones get ignored.
- Anything not listed is treated as potentially risky only when the four-step check says so; under doubt, the implementation stops and asks.
- A standing approval (§7.6) that does not state its scope explicitly is not a valid green light — the implementation MUST NOT guess the scope.
§7.1 Optional Machine-Readable Block
The prose sections above are written for an LLM to reason with. An implementation that enforces the policy with deterministic code (e.g. a pre-action hook, §8.1) needs a concrete, parseable subset. It SHOULD read it from a single fenced```keel-policy block inside the same AGENT_POLICY.md, keeping one file for both human and machine readers. The block uses flat lists only:
hot_paths/hot_commands— glob paths and command substrings that are hot.standing_allow_*— scoped exceptions, the machine-readable form of §7.6.- The block refines the §4 defaults; it MUST NOT be read as removing a default category. Anything not in the block still falls under the four-step check (§3).
- The block is optional. Its absence means the enforcing layer runs on §4 defaults alone; the reasoning layer (the LLM) is unaffected either way.
§8 Conformance
An implementation is Keel-compatible if it:- Reads
AGENT_POLICY.mdfrom the project root (or a path the user designates) and treats it as authoritative over these defaults. - Runs the four-step check (§3) before every action (§1).
- Treats every §4 default category as hot unless the policy concretely refines it.
- Only lets a green light carry over through following-through when all four §5 conditions hold.
- Never lets a subagent grant a green light (§6) if it supports delegation.
- Resolves any doubt toward stopping and asking.
§8.1 Enforcing Implementations (Optional, Stricter)
The conformance above is satisfied by a reasoning implementation — one where the agent applies the check itself. An implementation MAY additionally enforce the policy with deterministic code that intercepts actions before they run and blocks risky ones that lack a green light. An enforcing implementation:- Intercepts actions (§1) before they run and maps them to
allow/ask/deny, whereaskis the request for a green light (an explicit human-approval prompt). - Treats the §4 defaults as hot even with no machine-readable block (§7.1) present.
- In a non-interactive context (no human able to give a green light), denies any action it would otherwise have asked about.
- Is understood to be a backstop, not a cage — it raises assurance against accident, drift, and hallucination, but cannot contain an adversarial agent. Real isolation (scoped credentials, sandboxing) is complementary, not replaced.
PreToolUse hook (enforce-policy.cjs). See the Enforcement Hook example for a call-by-call walkthrough.
§9 Versioning
This spec usesMAJOR.MINOR. A MINOR bump adds or clarifies without breaking a conforming implementation; a MAJOR bump may change required behavior. The 0.1→0.2 bump renamed the three permission levels (goal / method / green light) without changing how they work. Implementations SHOULD declare which spec version they target.
This specification is a draft (v0.2). Proposals to clarify, tighten, or extend are welcome via issues/PRs on the GitHub repository.