mistwire.io/ governance

mistwire.io governance for AI sessions

AI sessions that refuse to run ungoverned.

Governance loads before work starts, and monitors itself while your agent works. How it works

Request access Read what we would install

Connected session surface

What a governed session receives

The governance connection establishes a repeatable working environment across AI sessions in the same workspace.

Signed policy

A pinned publisher key, verified artifacts, and a rollback floor define the session’s governance baseline.

Shared skills

The signed bundle supplies the same verified workflow library to every governed session that installs it.

Workspace memory

Connected sessions read and write the same remote workspace memory without using local project files as the memory store.

Shared hooks

The installed hook set applies the same local controls to governed sessions running in that environment.

Governed session bootstrap and capability flow A session start enters a mandatory governance bootstrap. A failed check exits the session. A successful check creates a governed session connected to shared skills, remote workspace memory, local hooks, and signed evidence. SESSION EVENT Start / resume No work dispatched yet MANDATORY GATE Governance bootstrap policy · identity · bundle ALL REQUIRED CHECKS PASS ACTIVE SESSION Governed / ready Pinned policy is active WORK MAY BEGIN FAIL-CLOSED Session exits SHARED SKILLS Signed workflow library WORKSPACE MEMORY Remote and cross-session LOCAL HOOKS Same enforcement surface SIGNED EVIDENCE Observations and receipts any failure
Bootstrap is fail-closed. Once active, policy hooks run locally while shared services and signed evidence remain available through the connected control plane.

Current signed bundle

Shared skill library

These workflow definitions travel with the verified policy bundle and can be used by any session governed by that installed bundle. Every one is readable before you install it — the literal bytes, what arguments it takes, which tools it may use, and the digest your agent checks.

checkpointcommit-ritualdavinci decision-treedispatchgoal-forge grey-cellsreport-rendersecurity-lint verify-ladder

A skill is instruction text a model loads into its own context, which makes it the supply chain into agent behavior. That is why they are graded for drift like an enforcement hook, ship non-executable, and are worth reading first.

Workspace-scoped service

Memory follows the workspace

Each connected session can reach the same remote workspace memory. Session context can move between clients without a memory file being written into the local project.

SESSION AREMOTE WORKSPACE MEMORY
SESSION BSAME WORKSPACE MEMORY

NO SESSION MEMORY FILES IN THE LOCAL PROJECT

Evidence flow after bootstrap

observe → adjudicate → countersign

Trust flow from signed policy to countersigned receipt The policy publisher signs a bundle. A local customer agent verifies and installs it, observes only manifest-listed artifacts, and signs those observations. The server verifies the agent signature, compares the observations to its manifest, and signs the resulting verdict. 01 · POLICY PUBLISHER Signed policy bundle Manifest + content-addressed artifacts 02 · CUSTOMER MACHINE Agent verifies, installs, observes Walks the paths in the signed manifest SIG CHECK · SHA-256 · MODE · LOCAL HOOKS 03 · GOVERNANCE SERVICE Server adjudicates Verifies agent signature Compares against its manifest 04 · RECEIPT Verdict Agent + bundle Time + server signature signed bundle same signed manifest signed observation signed verdict
  1. The publisher defines the reference.The manifest identifies the policy artifacts and expected digests.
  2. The agent reports observations.The observation schema contains no field that lets the agent declare a verdict.
  3. The service signs the result.The receipt key is held by the service and is separate from the customer’s agent key.
Three Ed25519 roles keep the evidence legible: publisher key for policy, agent key for observations, service key for receipts.

Verification

Inspectable proof

The evaluation path exposes the trust root, exact attestation payload, artifact digests, rollback state, and signed receipt. Each check can be performed outside the service’s own presentation layer.

01

Fetch trust before enrollment

Read /v1/trust, verify the publisher key ID through a separate channel, then enroll with --expect-publisher-key-id. Omitting that option leaves the first connection as trust on first use.

02

Recompute artifact hashes

On every pull, the client verifies the bundle signature and re-hashes each artifact against the signed manifest before installation.

03

Read the transmitted bytes

mw-govctl attest --print-payload prints the literal signed bytes transmitted by the client, including each observation the service will adjudicate.

04

Verify receipt and rollback state

An independent verifier can check a receipt with the receipt key in the trust root. The client also refuses a bundle older than its installed rollback floor.

Evaluate first

Never trust, always verify.

Everything below runs with no account, no token, and nothing installed. The signed material is public on purpose: handing it to a stranger costs nothing, and verifying it is the whole point. Read what we would put on your machine, and check that the bytes match what we signed, before you decide whether any of this deserves your trust.

01

See the keys you would be trusting

Two roots: one verifies the bundles we publish, one verifies the receipts we issue.

curl -sS https://governance.mistwire.io/v1/trust
02

Read what the service claims about itself

The machine-readable contract, including the limits. It is generated from the same constants the server enforces, so it cannot describe behavior the service does not have.

curl -sS https://governance.mistwire.io/v1/bootstrap
03

List what would land on your machine

Every artifact, its kind, and the file mode it installs with. Nothing here is a surprise at install time.

curl -sS https://governance.mistwire.io/v1/bundle/stable
04

Read a policy file before installing it

Artifacts are content-addressed. Take a sha256 from the manifest above and fetch those exact bytes.

curl -sS https://governance.mistwire.io/v1/blob/<sha256>
05

Confirm the bytes match the signature

Recompute the digest yourself. If it differs from the manifest, the artifact was substituted — and this is the check the client performs on every pull, which is why the blob endpoint can be public and cached without being trusted.

curl -sS https://governance.mistwire.io/v1/blob/<sha256> | shasum -a 256
06

Then, and only then, enroll

Registering a key is the first step that needs a credential, and it is the one step a machine cannot do alone — deliberately. Without it, whoever answered first would become trusted. Request an invite code: you pick your name, it is reserved on the spot, and the code is issued immediately. Everything after it is automatic.

Connection paths

Establish governance before the session works.

The MCP endpoint exposes the full governance surface to an agent session and requires nothing installed. The CLI is the same protocol with a client written for you. The session harness treats a failed policy load or identity registration as a terminal bootstrap failure.

Session profile

Two paths. The MCP endpoint needs nothing installed and is the one to start with; the CLI is the same protocol with a client written for you. A complete governed session also attaches the workspace memory service and uses the locally installed shared skills and hooks.

MCP · nothing to install

Point a session at the endpoint.

Every step runs over this one transport. An agent that can make HTTPS requests and write files needs no client from us.

Endpoint https://governance.mistwire.io/mcp
  • Preferred revision2026-07-28
  • Also accepted2025-11-25
  • TransportStreamable HTTP
governance_enroll governance_get_trust_root governance_get_bundle governance_submit_attestation

governance_enroll takes the operator token in the Authorization header, not as a tool argument — arguments are mirrored into Mcp-Param-* headers so an edge can route without reading bodies, which would copy a credential somewhere intermediaries log.

An agent that wants the whole contract in one fetch, before it has enrolled or trusted anything, can read /v1/bootstrap.

CLI · enroll / pull / attest

Pin, install, then produce a receipt.

Not distributed yet. The client is written and tested but has no published build, so these commands are shown for shape rather than to run today. The MCP path above does the same work with nothing to install.

curl -sS https://governance.mistwire.io/v1/trust

export MW_GOV_ENROLL_TOKEN='<invite-code>'
mw-govctl setup \
  --server https://governance.mistwire.io \
  --expect-publisher-key-id <verified-key-id>

mw-govctl attest --print-payload

One command does enroll, pull, and attest. The invite code carries the name you chose when you requested access, and that name wins over whatever the client asks for — which is what stops two testers being promised the same identity. Without an invite, the label defaults to an opaque identifier rather than your hostname, because the label is the one field on the wire you could over-share in.

Runtime boundary

Bootstrap fails closed, enforcement stays local and outside the model.

Start and resume events require a successful governance load. After that gate, installed hooks make local decisions inside the agent harness. Policy, memory, and evidence traffic travel separately from model and tool requests.

Request path and evidence path

solid = local request · dashed = governance traffic

Local enforcement and out-of-band governance service After a mandatory session bootstrap, a tool request passes through a local policy hook to an allowed tool entirely on the customer machine. A local governance client separately pulls policy from and sends observations to the governance service. Installed hooks continue enforcing between governance refresh boundaries. CUSTOMER MACHINE AGENT Tool request LOCAL Policy hook LOCAL OUTCOME Allowed tool check allow mw-govctl · pull / attest installs hooks GOVERNANCE SERVICE Policy + adjudication Outside the request path Issues signed receipts signed bundle observations + receipt
A new or resumed session exits when mandatory governance bootstrap fails. Once bootstrapped, the installed hooks remain local; remote memory, policy refresh, and new receipts require the connected services.
Start / resume gate

Required governance policy and identity checks complete before the session may work.

Local decision

The installed hook evaluates each governed action on the customer’s machine.

Control-plane loss

Local hooks remain active. A required refresh failure ends the session; remote memory and new evidence are unavailable while disconnected.

Data disclosure

A narrow attestation view of installed artifacts.

The supplied client walks the signed manifest rather than enumerating the customer’s filesystem. Its attestation schema reports metadata for the artifacts this service published into its own governance directory.

The full disclosure What we process, why, and for how long → Every category, its purpose, its retention, where it lives, and whether you can retrieve it — with every retention figure read from the constant that enforces it, so the page cannot quote a number the service does not honor.
Inspect it directly

mw-govctl attest --print-payload prints the literal bytes transmitted. This is the most direct way to review the disclosure for a specific machine before submitting it.

Received by the service

Enrollment and artifact metadata

The customer controls the only free-form identifier: the enrollment label.

  • When you request access: the name you chose, an email address, an organization, where you intend to run it, and what you plan to test — verbatim, as typed. This is everything you tell us directly, held against your invite, and /me shows you all of it. It is not the only data that could identify you: like any HTTP service we log source addresses, and one is held in memory for up to an hour to enforce the signup cooldown. Neither is stored against your identity, which is why neither appears on /me.
  • At enrollment: a label — carried by your invite if you used one — and the agent’s Ed25519 public key.
  • Attestation envelope: that label, bundle ID, timestamp, and single-use random nonce.
  • For each service-published artifact: its relative path inside the governance directory, presence, SHA-256, and file mode.

Cannot be received through mw-govctl

Customer workload data

mw-govctl has no filesystem enumeration step and sends no content field.

  • File contents or paths outside the service-created governance directory.
  • Customer source code, prompts, model calls, or model responses.
  • Environment variables, credentials, or application configuration.
  • A history of agent actions or the customer’s broader filesystem.
Stored durablyEnrollments, invites and what you typed on the access form, and read-token digests. These survive a restart.
In-process memoryReceipts, replay state, and a source address per recent signup request. A restart clears all three; a receipt you already hold stays verifiable without us.
Attestation logOne log line per attestation: label, bundle ID, and verdict.
HTTP access logsStandard request logs, including source IP and timestamp.
Memory is separate

The shared workspace memory service receives content only when a connected session explicitly writes a memory. Those writes do not travel through mw-govctl, are not part of an attestation, and do not create memory files in the local project. Memory-service retention is separate from the enrollment and receipt stores described above.

Cost

Free while it is alpha and beta. Paid after.

Saying this up front rather than in a footnote, because finding out later is the part people resent. There is no charge today and no way for you to be charged today — and this will become a paid service once it leaves beta.

No cost today

Alpha and beta access is free. We collect no payment method, so there is no mechanism by which a charge could reach you — not an intention, an absence of plumbing.

It will not become paid silently

Nothing converts to a paid plan on its own. When pricing exists you will be told, in advance, and the service keeps working under whatever terms applied when you enrolled until you agree to new ones.

There is no price yet

We have not set one. Anyone quoting you a figure for this is guessing. What we can say is the shape: this is a control plane, not a proxy, so it is not priced per token or per model call.

What you keep if you leave

Every receipt you have already received stays verifiable without us — they are signed, and the public key that checks them is published. Evidence you collected during the free period does not expire when access does.

Honest limits

A receipt proves what was reported, not what happened on the machine.

This proof of concept separates customer-signed observations from a service-signed verdict. That separation improves attribution while leaving the customer in control of the machine that produces the observations.

A customer can sign a false observation.

If a customer deletes a hook and signs an observation claiming the expected digest and mode, the service can return Compliant. The service does not prevent or detect that lie.

The resulting evidence is specific: the signed observation and countersigned receipt bind the claim to an enrolled agent key, a bundle, a time, and a verdict. A retained observation and receipt support later attribution and cryptographic non-repudiation. The service does not persist its copy, and the signatures do not establish that the observation was truthful.

Single instance

The design currently depends on one process and does not support horizontal scaling.

Partial persistence

Enrollments, invites, and read tokens survive a restart. Replay state and the service’s receipt store do not — they are in memory, and a restart clears both.

One tenant

Tenant isolation and per-tenant trust roots are not implemented.

No key rotation

There is no workflow to issue, overlap, revoke, or replace signing keys.

Built

See your own data

Three doors, one answer. An agent signs a request and calls /v1/me or runs mw-govctl me; a person pastes their read token at /me. All three read the same assembly function on the server, so a human and their agent cannot be shown different accounts of the same identity.

The response is the whole record: the enrolled key, the invite it came from, everything typed on the access-request form, and the receipts still held. It also states what is not retained and what exists outside the view — listed because a page showing only what we keep would read as exhaustive when it is not.

--print-payload remains the other half: it shows the bytes leaving your machine, where me shows the records held on ours.