Most AI coding governance fails in one of two ways. It is either so permissive that every agent can change anything, or so bureaucratic that every harmless edit waits for a human approval. A good Nool configuration does neither. It makes scrutiny proportional to risk.
This guide presents a practical Nool 6.2.0 setup for teams searching for **AI coding agent governance**, **blast-radius control**, **agent trust thresholds**, and **role-based approval gates**. The configuration is ready to paste into a project-level `nool.toml`, but the important part is the operating model behind it.
> The short version: block large blast radii, let proven agents proceed on small changes, and call a named human role only when a concrete risk signal fires.
## The production-ready nool.toml
```toml [gating] fail_fast = true blast_block_threshold = 30
[trust] enabled = true base_trust = 0.5 auto_proceed_threshold = 0.8 auto_proceed_max_blast = 10
[[steer.points]] point = "pre-push" role = "ciso" [[steer.points.triggers]] signal = "sensitive_path" paths = ["auth", "crypto", "identity", "billing", "secret"]
[[steer.points]] point = "pre-solidify" role = "architect" [[steer.points.triggers]] signal = "coupling_slope_gt" value = 0.3 ```
This setup creates three layers of control. Gating establishes a hard safety boundary. Trust removes repetitive approval work for low-impact changes. Steering asks the right accountable role to intervene when a specific security or architecture condition appears.
## 1. Gate on semantic blast radius, not line count
`blast_block_threshold = 30` means a proposal with a broad computed impact is stopped early. That is more useful than a rule such as “review every change over 500 lines.” A ten-line edit to identity middleware may be more consequential than a thousand-line documentation reformat.
With `fail_fast = true`, an agent learns about the decisive failure immediately. It can split the work, narrow its declared intent, or explain why the wider impact is necessary before consuming another review cycle.
The threshold is a starting point, not a universal constant. Review the blast-radius distribution in your own ledger. A tightly coupled monolith and a collection of isolated services will produce different baselines. What matters is that the threshold is explicit, measurable, and adjusted from evidence.
For a deeper explanation of the underlying signal, read [Semantic Blast Radius: Finding the Real Impact of AI-Generated Code](/blog/semantic-blast-radius).
## 2. Use trust to remove ceremony from small changes
Trust should be earned from a track record, not granted because a model produced a convincing explanation.
The example begins each identity at `base_trust = 0.5`. Automatic progress requires both conditions below:
- trust has reached at least `0.8` - computed blast radius is no greater than `10`
That conjunction matters. A highly trusted agent still does not receive a blank check for a high-impact refactor. Conversely, a tiny change from an unproven identity still receives appropriate scrutiny until the ledger contains enough evidence.
This is what proportional autonomy looks like in practice: **trust changes the amount of friction, never the existence of the safety boundary**.
## 3. Route security risk to the CISO
The pre-push steering point activates when a proposal reaches sensitive paths such as `auth`, `crypto`, `identity`, `billing`, or `secret`.
The role name is deliberately organizational. The configuration does not hard-code one person or one vendor. A team binds the `ciso` role to an accountable owner in its environment. That keeps company governance portable while preserving local responsibility.
Path triggers are easy to understand and audit. They are also intentionally conservative. Include the vocabulary used in your repository—for example `payments`, `tokens`, `kms`, or `compliance`—rather than copying a list that does not match the codebase.
## 4. Route structural risk to an architect
The second steering point runs before solidification and watches `coupling_slope_gt = 0.3`. Its job is not to block all dependency growth. It is to notice when a change makes the system materially harder to separate, reason about, or release.
That is the right moment for an architect to ask:
- Is the new dependency intentional? - Can the contract be narrower? - Does this change create a release-order constraint? - Is a shared abstraction actually shared, or merely convenient today?
Because the gate is signal-driven, the architect is not asked to approve routine local work. Human attention is reserved for changes that alter the shape of the system.
## Add invariants before adding more meetings
Declarative invariants encode facts that should remain true across every agent and session. A project can define them under `[invariants.rule_definitions.<id>]` without adding application code.
Good first invariants are boring and testable:
1. protected modules do not import presentation layers 2. public API changes include contract tests 3. migrations preserve an explicit rollback path
Begin with warning-level enforcement. Observe false positives, tighten the rule, and only then make it blocking. A weak rule marked “required” creates alert fatigue; a precise warning that graduates to enforcement becomes durable engineering memory.
## Model multi-repository dependencies correctly
When a team grows beyond one repository, add a `workspace.toml` and distinguish release ordering from contract relationships.
```toml [[workspace.depends]] from = "api-gateway" on = "billing" kind = "release" # billing must ship first
[[workspace.depends]] from = "web" on = "api-gateway" kind = "contract" # shared contract only, no ordering ```
A `release` edge gates build and shipping order. A `contract` edge records a shared interface but does not force one repository to ship before another. Mixing those meanings creates fake bottlenecks, so model the operational truth rather than drawing every relationship as a release dependency.
## The maturity ladder that actually works
An optimal setup is not a maximal configuration on day one. It is a sequence:
1. **Day 1:** enable gating, the shipped secret/PII policies, and warning-level invariants. 2. **Weeks 2–4:** enable trust after the ledger contains a real track record. 3. **When criteria-writing is habitual:** require acceptance-criteria review. 4. **When ownership is named:** enable steering for CISO and architect roles. 5. **After the second repository:** introduce `workspace.toml`.
Turning on a steering gate before anyone owns the role does not create governance. It creates a queue nobody can clear. The system becomes powerful when technical signals, accountable roles, and team habits mature together.
## Start from the scaffold, then inspect the effective config
Nool 6.2.0 can scaffold the governance surface:
```bash nool config init-governance nool config show ```
Review the generated configuration before writing it into the project. Then compare the effective configuration with the intended operating model, especially when workspace or enterprise layers are involved.
The complete copy-ready reference is available in the [Advanced Nool Setup documentation](/docs/advanced-setup). For organization-wide reuse, continue with [Enterprise AI Agent Governance with Nool Packs](/blog/enterprise-ai-agent-governance-nool-packs).