What we process

Every category of data this service touches, what it is for, how long it stays, and whether you can get it back. Written against the code rather than around it.

The design constraint everything else follows from

We govern your sessions without knowing what they are doing, or why.

That is a structural property, not a promise. Your agent reports one thing: for each file we published into the directory we created, is it present, what is its SHA-256, and what is its file mode. That is the entire vocabulary of the wire protocol. There is no field for what you are working on, no field for a prompt, no field for a result, and no endpoint that would accept one.

So the question "what is this customer building?" is not one we decline to answer. It is one we cannot answer, because the information required to answer it never arrives and there is nowhere in the schema to put it. A governance service that had to understand your work in order to govern it would be a surveillance product with a compliance story attached.

Check it rather than believe it: mw-govctl attest --print-payload prints the literal bytes your machine sends, before it sends them.

The one time we ask anything about you

The access-request form asks who you are and what you intend to test. That is a human telling us about themselves once, at signup, so a closed alpha has known participants — it is not, and cannot become, knowledge of what any session does. Nothing your agents run ever adds to it, and it is deleted on the schedule below while your identity remains.

If that distinction ever stops being true, this page is where it would have to change, and the retention figures on it are read from the code rather than typed beside it.

What we hold

What you type on the access-request form

Exactly what	the name you chose, an email address, an organization, where you intend to run it, what you plan to test, and the moment you accepted the alpha terms
Why we have it	To know who is in a closed alpha, and to be able to reach you about it. A closed alpha with anonymous participants is not a closed alpha.
How long	180 days after the invite is used or expires, then the text is deleted and the invite record stays without it. Swept at boot and on every invite issued.
Where it lives	A data file in a private cloud storage bucket, mounted by the service. Not a third-party CRM, mailing list, or analytics product.
Can you see it?	Yes — in full, verbatim, at /me and through `mw-govctl me`.

Your agent's identity

Exactly what	the name your invite carried, your agent's Ed25519 public key, and the key id derived from it
Why we have it	To verify the signature on everything your agent sends. This is the whole security model: the key is the credential, so a name without a key bound to it would let anyone claim to be you.
How long	Until the enrollment is removed. There is no automatic expiry — an identity that vanished on a timer would silently stop your agents from attesting.
Where it lives	The same private bucket. The public key is public by construction; the private half never leaves your machine and is never transmitted.
Can you see it?	Yes — at /me and through the API.

What your agent reports about the files we published

Exactly what	for each artifact this service installed: its path relative to the governance directory, whether it is present, its SHA-256, and its file mode — plus a timestamp and a single-use random nonce
Why we have it	This is the product. You report what your machine looks like; the service compares it to what it published and returns a signed verdict. The service refuses an observation naming anything other than a file it published, including any absolute path, so this cannot become a channel for your filesystem.
How long	Not stored as sent. The resulting receipt is held in memory only — the newest 10000 across all agents — and a restart clears them. Yours was handed to you at the time and verifies without us.
Where it lives	Process memory. Never written to disk.
Can you see it?	Yes — whatever is still held, at /me. And you hold your own copy, which is the one that matters.

A digest of your read token

Exactly what	the SHA-256 of the token, the name it belongs to, the key it was issued against, when it was issued and expires, and whether it has been revoked
Why we have it	So a person at a browser can see their own record. A human cannot sign Ed25519 by hand, so without this the browser route would not exist for them.
How long	90 days from issue. Only the digest is stored, so neither we nor anyone who obtains our database can recover the token itself.
Where it lives	The same private bucket.
Can you see it?	Its existence, yes — listed at /me. Its value, no: we do not have it.

A digest of your invite code

Exactly what	the SHA-256 of the code, the name it reserves, when it was minted and expires, and which key redeemed it
Why we have it	To make a code work exactly once, and to hold your chosen name from the moment it is issued — which is what stops two testers being promised the same identity.
How long	The record is kept. The code expires 14 days after minting if unused.
Where it lives	The same private bucket.
Can you see it?	Yes — at /me.

Your network address

Exactly what	the source IP address of your request, and a timestamp
Why we have it	Two reasons, and they are different. Ordinary HTTP access logging, which every web service on earth does. And, for the signup form only, enforcing the one-per-hour limit that stops one caller reserving the whole namespace.
How long	The cooldown entry is held in memory for one hour and is discarded on restart. Access logs follow our hosting provider's default retention.
Where it lives	Process memory, and our hosting provider's log store.
Can you see it?	No, and this is the honest limit of /me: neither is keyed by your identity, so there is no query that could return "your" rows without us building the very index that would make them personal. We would rather not have it.

What we never receive

Stated with the same weight as what we do, because on this service the absence is the product. An unstated absence is worth nothing.

The contents of any file. Your agent sends digests, never bytes. mw-govctl attest --print-payload prints the literal request so you can check rather than take our word.
Any path of yours. Only paths of files this service installed, relative to the directory it created. The service refuses an observation carrying anything else.
Your source code, prompts, model calls, or model responses. The client has no filesystem enumeration step and no content field. There is nowhere for them to go.
Environment variables, credentials, or configuration. Same reason. The one credential that ever crosses the wire is an invite code, and it crosses once, from us to you.
A history of what your agents did. An attestation describes files at a moment. It does not describe actions, and no endpoint accepts them.
Payment details. There is no payment method on file because there is no billing. The alpha is free.

Who else sees it

Nobody. There is no analytics, no advertising network, no session recorder, no third-party error reporting, and no data sold, rented, or shared. The pages here load nothing from anywhere else — no fonts, no scripts, no images — which is a claim you can check with your browser's network tab rather than take on faith.

Two categories of processor are unavoidable: a hosting provider runs the service and holds the private bucket, and a CDN sits in front of it and terminates TLS. Both see traffic in the ordinary way a host and a CDN do. We name them specifically to any customer who asks, and in writing in any data-processing agreement — publishing our infrastructure map on a marketing page tells an attacker where to aim and tells you nothing you can act on.

Getting it, and getting rid of it

To see it: /me with the read token issued at enrollment, or mw-govctl me, or the governance_my_data MCP tool. All three read the same function on the server, so they cannot show you different answers.

To delete it: write to alpha@mistwire.io and we will remove the enrollment and its request record. There is no self-service delete button yet, and saying so is better than a page that implies one. Your receipts are yours already and are not ours to delete.

During the alpha we will also delete on request without asking why, because the alternative — a retention argument with someone who has decided to leave — is not a business we want.

When this changes

The alpha is free and will not always be. Pricing arrives before general availability, and you will be told the terms before anything is charged — the request form says so before you fill it in, not after.

If what we process changes, this page changes with it, and the retention figures on it are read from the code rather than maintained beside it.

Back to the overview · See your own record · Read what we would install