# How mistwire governance works > Signed policy loads before the session. Local hooks check each request outside the model. A signed receipt shows what is installed. Follow the five moves and try a request yourself. Canonical: https://mistwire.io/how-it-works Every page as Markdown: https://mistwire.io/llms.txt Primary product # Agent governance that starts before the session does. Signed governance loads at start or resume. Local hooks enforce the installed policy outside the model. Signed observations and service receipts make the result inspectable. [Request access](https://governance.mistwire.io/request)[Inspect the signed skill library](https://governance.mistwire.io/skills)[See your data ](https://mistwire.io/portal) Alpha access is free and no payment method is collected. Pricing will be introduced before general availability, with advance notice and an explicit choice. Two ways to run an agent ## Check each action, or set up the world first. Both keep an agent inside limits. They differ in where the check happens and how many chances there are to slip past it. The first is often called supervision, the second governance. mistwire's alpha installs hooks, which is the first; setting up the session first is next. Check each action as it happens Set up the session first, then let it run Next **What has to be watched**: Every way the agent can act. **What can be missed**: Any path nobody covered. **When a bypass is possible**: At any action. The cycle in five moves ## From published trust to local enforcement. Every arrow from the service carries something signed by a key your machine pinned. Every arrow from your machine carries something signed by a key the service enrolled. Neither side acts on an unsigned claim from the other. Click a numbered step or play the sequence. All 1 Trust 2 Bootstrap 3 Verify 4 Enforce 5 Attest ▶ Play **The complete lifecycle** Trust and signed policy originate outside the agent-controlled session. Verification and request enforcement happen locally. Installed-state attestation remains a separate evidence lane. What happens to a request ## See the local decision—and keep attestation separate. Choose a behavior covered by the current signed alpha bundle. Follow its local outcome, then inspect the separate evidence path for installed governance state. The request Read a file Write a file Run a command It points to Choose a current alpha behavior. The path lights up from local request to a bounded, legible outcome. **Auto-approved locally** Bounded safe-read rule matches. Host proceeds within the signed boundary. 01 Request 02 Local rule 03 Outcome Separate Attestation Tool request ### The session asks to read one source file. The host exposes the requested operation and path to the installed local permit hook before deciding whether to proceed. Plainly: the action is named before any auto-approval. **Runs locally**: Host harness and local hook **Leaves the machine**: Nothing at this stage **If it fails**: The host remains responsible Separate lane **Attestation verifies installed governance state.** It does not claim to be a per-action log or proof of what this individual request did. What the receipt catches ## Your machine reports what it saw. The service decides what it means. Set the state of each governed file and read the verdict. The service compares the report against the policy it signed, and signs the answer with a key your machine does not hold. report `what arrived from your machine` Arrived Names an unknown policy version Not received yet policy `policy/governance.toml` Present Changed Missing hook `hooks/mw-permit.sh` Present Changed Missing Not executable skill `skills/commit-ritual/SKILL.md` Present Changed Missing doc `docs/ENFORCEMENT.md` Present Changed Missing extra `an unlisted file in the governance folder` None Present next `a second, independent witness` Off Agrees Disagrees The receipt says **Compliant** Every governed file matches the signed policy. Every verdict - Compliant live - Drifted live - Unknown live - No report yet planned - Reports disagree planned Mirrors the service's adjudicator: policy, hooks and skills are graded; docs are not. Unknown means the report named a policy the service does not know, so it cannot judge. No report yet and Reports disagree are planned verdicts, drawn here so the layout has room for them. A signed receipt binds an enrolled key, observation, bundle, time, and service verdict. It attests installed governance state; it is not a per-action activity log or proof that a customer-controlled machine reported truthfully. Both planes Outside the session Inside the execution path Outside the agent-controlled session ### Trust & policy plane Identity, trust roots, signed policy distribution, and attestation remain above the session so the agent cannot rewrite its own governance. Protected **Trust roots**Publisher and receipt keys **Signed bundles**Versioned policy artifacts **Enrollment**Bound agent identity **Attestation**Installed-state verdict Inside the execution path ### Local enforcement plane Installed hooks evaluate covered requests before execution. A safe read may proceed, a signed hazard is denied, and uncertain requests remain with the host and human. Local **Agent request**Proposed tool action **Signed rule**Local match and boundary **Outcome**Allow, deny, or ask **Host control**Human remains authoritative **Two locations, one governance model** The policy is distributed from outside the session and enforced locally in the request path. Attestation remains separate from individual action outcomes.