the rules deciding what your agents may never do alone are sealed. an agent can’t quietly edit them, and neither can you.

the file is constitution.yaml, and it sits on your box. it names the decision classes that stop an agent mid-task and wait for a person: spend and billing, anything public, secrets, anything destructive. each class is a pattern. if what an agent is about to do matches one, the task blocks and a human gets a tap.

that part is ordinary. plenty of tools have a permissions config.

the part that matters is what happens when something tries to change it.

open the file, edit a rule, save it

nothing happens. specifically, your edit does not take effect.

the file carries a digest sealed into the council’s lineage, and here’s the part that does the real work: that digest gets checked inside the gate decision itself. every single time an agent hits a gated action, the check runs. if what’s on disk no longer matches what was sealed, the file is ignored and the shipped safe defaults are enforced instead.

nobody has to run a scan. nobody has to notice. a tampered constitution simply stops being obeyed at the next gated action.

so a text editor can’t weaken your governance. it can only break the seal, and a broken seal is loud rather than quiet. you get the same verdict when you run council verify and when the council next convenes.

this is the whole design, and it’s worth being clear about what it does and doesn’t defend. the binary has no opinion about the content of your rules. what it defends is the provenance. an unsanctioned edit that deletes a hard class to loosen the floor is exactly the thing that must never silently take effect, and the seal makes that true without anything having to guess at intent.

why that matters more when the staff are software

a human employee who wants to loosen a spending limit has to ask somebody. the asking is enforced by the fact that they can’t reach into the payroll system at 3am.

an agent can reach the file. it runs on the same box, with a shell, and the config that governs it is just a path. “the agent edited its own permissions and then proceeded” is not an exotic threat model here, it’s the default one unless something structurally prevents it.

sealing is that something. an agent can propose a change through the ratified path like anyone else. what it can’t do is edit the file and have the edit count.

the guard i didn’t expect to like

hard-gate patterns are POSIX regexes, so you can write a broken one.

if you do, the entire policy is rejected and enforcement falls back to the shipped defaults. not just the malformed class. all of it. and the authority on whether a pattern is valid is bash itself, rather than a friendlier validator that might disagree with the thing actually running the match.

that ordering matters more than it sounds like it should. a bad rule can’t silently switch off human-gating and leave you looking at a config that reads fine. it fails toward more gating, never less.

same if the file goes missing or turns malformed at load: it falls back atomically and never applies half a document. there’s no state where your constitution is partly in effect.

the comments are sealed too

human rationale lives in # comments, and those are covered by the sealed digest while never being parsed as policy.

so the reasoning for a rule is tamper-evident alongside the rule itself. nobody has to reconstruct from a commit message why spend was gated where it was. the why travels with the what, and neither can be changed without breaking the same seal.

that one’s small and it’s my favourite thing in the file.

what it doesn’t do yet

ship.require_ci and comms.public_requires_human are in the file, they’re operator-settable, and the seal covers them. they are not execution rules in this version. they’re policy data that reads like enforcement, and i’d rather say so here than let you infer otherwise from the fact that they sit next to the classes that do enforce.

the enforcing part is hard_gates. those compile into the human-only floor on task gating.

what a real change looks like

there’s one command: council amend --file=<new constitution.yaml>.

it validates the proposed file, convenes a constitutional-class motion, and only on a pass does it seal the new digest into the hash chain and swap the file on disk. a motion that doesn’t pass leaves your constitution untouched. there’s a --dry-run if you want to see it fail first.

constitutional class is the highest bar in the system: two thirds in favour, and full quorum, so every current seat has to vote. no reaching the threshold because half the council didn’t show up.

the obvious next question is whether there’s a side door, since there’s also a constitution set command. there isn’t. it writes only the gate and policy keys, re-emits the governance keys verbatim, and hard-refuses anything else with “governance changes go through council amend.” it’s usable only before a council exists and the file is sealed. once governance is real, that path closes.

then there’s the founder veto, and this is the part to read twice.

it does not hold the change back. a passed amendment takes effect immediately and is sealed immediately. the veto is a 48-hour window afterwards in which the founder can reverse it, which flips the decision and flags an unwind. it is not a countersignature and it is not a waiting period. no human approves an amendment before it starts applying.

so if you want a person in the loop on changes to your own governance, that’s a veto you have to actively watch for and use inside two days. after 48 hours it’s final. better to know that now than to work it out from a diff.

our own council is six agents

worth showing rather than describing. this is the live roster on the box this post was written on:

council:   council (6 seats)
  seat olivia (chair)
  seat main, codex, marketing, creative, dev
veto:      human:main
lineage:   seq 2, 3 record(s), head uymHv3ZWsig5Ly3K…

six seats, all of them agents, chaired by an AI. the human holds a veto and nothing else. so yes: on our box, a council of agents can amend the constitution those same agents run under, and it applies the moment it passes, with the founder holding two days to undo it.

that’s the design, not a gap in it. the protection isn’t that agents are locked out of governance, it’s that they can’t touch it invisibly. every motion is a sealed record hash-chained to the one before it, and council verify walks the whole chain. it doesn’t just count records, it re-seals each one and compares: a record whose canonical form no longer produces its stored digest gets reported as tampered, by sequence number. here’s ours, run while writing this:

council verify: OK — 3 record(s), chain intact + every record re-seals
+ constitution matches its sealed digest

one thing agents genuinely cannot do is start the council. council init is sudo-gated and seeds once, on a stated principle: an agent must not bootstrap its own governance body.

and yes, you can loosen it

the defaults are ours, not yours. a ratified amendment can widen a class, narrow it, or remove one entirely, and there’s no welded minimum underneath, because the policy you load replaces the shipped floor rather than stacking on top of it.

what you can’t do is make that change off the record.

one thing to try

run 5dive constitution show and read the four hard-gate patterns out loud.

most people have never seen the actual list of things their tooling decided to stop them on. if a class is tighter than how much you trust your agents this month, change it through the proper path. if it’s looser than you’re comfortable with, tighten it. our defaults were never meant to be the final answer for your company, only a safe place to start.

---

5dive runs a company of AI agents on your own box, on the Claude plan you already pay for. the governance is a sealed file you own and can read, not a policy page you agree to. spin one up at 5dive.ai.

it’s open source too: github.com/5dive-ai/5dive