Can an agent bypass a gate?

Not from inside the workflow. Gates run at proposal time on the change itself; an out-of-envelope change without justification is refused, a policy violation is refused, and sensitive paths wait for an attestation before push. Fast mode defers validation, which is why sensitive paths should run --full.

Where is agent activity recorded, and who can read it?

In the repository's ledger, mirrored to Git, readable by whoever can read the repository. Nothing is sent to Nool. A hub server for cross-machine leases is optional and uses OIDC with org and repo access control.

How does this map to a compliance framework?

nool audit export produces audit proof with framework validation, and every control is attached to the change it governed: gate results, approvals with comments, and signed attestations from named checkers.

Can governance be rolled out across many repositories?

Yes. Governance packs bundle roles, policies and controls; nool admin pack verify checks a pack and nool admin pack install applies it. Enterprise licensing covers the CLI everywhere plus Mission Control for oversight.

Where should a security team start?

With the record. Install Nool, let agents work in fast mode for a short period, and read nool insights and nool audit report to see what agents touch and how often they cross boundaries. That evidence tells you which paths need full validation, authored policies and human holds first.

AI Governance and AI Control for Coding Agents

Nool enforces your architectural and security rules at the speed agents work, so only changes that pass them land, each with a signed record of why.

From scaffold to audit-ready evidence

# Roles, responsibilities, controls and starter policies for the team
nool config init-governance

# A distributable governance pack, verified before install
nool admin pack verify ./packs/regulated-baseline
nool admin pack install ./packs/regulated-baseline

# Sensitive change: full gate stack, human holds, signed attestations
nool propose --path src/auth/oidc.ts --intent "Rotate the OIDC client secret handling"
nool approve <knot-id> --comment "Architecture reviewed; coupling unchanged"
nool attest record --target <knot-id> --checker ciso --assertion human-approval --verdict pass
nool solidify --compact

# Evidence for the auditor
nool audit verify --framework soc2
nool audit export --output audit.json
nool evidence knot <knot-id>

Approvals, attestations and gate results are attached to the knot, so the audit trail is the change itself rather than a document about it.

What a security lead actually needs to know

When a CTO or a security lead evaluates coding agents, the questions are not about model quality. They are about control: who can change what, what stops an agent from weakening an authorisation check, where the record of agent activity lives, who can read it, and how a compliance team proves any of it later. Prompts and code review answer none of these to an auditor's standard. Governance for agents has to be a mechanism, not a policy document, and the mechanism has to sit where the change happens.

Gates that cannot be talked out of

Nool's gates run at proposal time and are deterministic: the same change against the same policy gets the same verdict. The envelope gate refuses changes that reach beyond their declared scope without justification. Policy gates evaluate authored rules, in a DSL or compiled to WASM, over the change's paths, boundaries, blast radius and context. Gates are proportional to risk and their thresholds are versioned configuration. Two human holds sit on top: a named architect approves changes that raise coupling, and a named CISO role attests changes to auth, crypto, identity or billing paths before they reach the remote. An agent cannot argue with a gate, and neither can a hurried engineer.

A record built for audit

Every knot is signed and carries intent, blast radius, gate results, approvals and causal parents. Attestations from CI, scanners and reviewers are signed refs replicated with the repository. nool audit report generates a compliance report; nool audit export produces proof with framework validation; nool audit steering reviews the quality of role-based steering; nool evidence retrieves the transition proof for a knot. Identity is enforced end to end: agents propose under agent ids, personas are durable identities, and the hub server uses OIDC principals with org and repo access control. Everything runs locally and verifies locally, so the record lives in the repository the organisation already controls.

Honest about what is and is not governed

Nool's own benchmark publishes the limit of its governance as prominently as the results. Under full validation both real contract breaks in the workload were blocked with zero false alarms, and an authored policy blocked all ten violations in 36 of 40 seed-runs, also with zero false alarms, while five violations shipped across the other four. But fast mode defers validation, and none of the recovery commands distinguish a repository with a landed contract break from a healthy one. The operational rule that follows is to run full validation and authored policies on every path that matters, and to treat fast mode as a local iteration tool. A governance product that hid this would be selling reassurance rather than control.

Rolling out in phases

Governance lands better in stages. First, install Nool and run in fast mode: agents announce, propose and solidify, and the ledger starts recording intent and blast radius while nothing blocks. nool status and nool insights show the shape of agent activity within days. Second, turn on full validation for the paths that matter and run nool config init-governance to scaffold roles, controls and starter policies; the envelope check and policy gates begin refusing what should be refused. Third, add the human holds, the architect gate for coupling and the CISO attestation for sensitive paths, distribute governance packs across repositories, and connect a hub with OIDC if agents work across machines. Each phase produces evidence the next one is justified by.

Frequently asked questions

Can an agent bypass a gate?: Not from inside the workflow. Gates run at proposal time on the change itself; an out-of-envelope change without justification is refused, a policy violation is refused, and sensitive paths wait for an attestation before push. Fast mode defers validation, which is why sensitive paths should run --full.
Where is agent activity recorded, and who can read it?: In the repository's ledger, mirrored to Git, readable by whoever can read the repository. Nothing is sent to Nool. A hub server for cross-machine leases is optional and uses OIDC with org and repo access control.
How does this map to a compliance framework?: nool audit export produces audit proof with framework validation, and every control is attached to the change it governed: gate results, approvals with comments, and signed attestations from named checkers.
Can governance be rolled out across many repositories?: Yes. Governance packs bundle roles, policies and controls; nool admin pack verify checks a pack and nool admin pack install applies it. Enterprise licensing covers the CLI everywhere plus Mission Control for oversight.
Where should a security team start?: With the record. Install Nool, let agents work in fast mode for a short period, and read nool insights and nool audit report to see what agents touch and how often they cross boundaries. That evidence tells you which paths need full validation, authored policies and human holds first.