Know which identity touched your data.
Every actor on your data is a registered identity, not an anonymous service call.
KnowMessenger is registered with Token Holder as a named consumer under your tenant, holding a fixed, least-privilege set of scopes: list, read and write on your vault, read on your usage record, the ability to issue its own sessions — and the ability to kill them. Nothing it does reaches your data outside that set, you can read the list, and you can revoke the whole thing from one page.
Each person who signs in gets their own Token Holder identity under your tenant, and their session bearer is what binds a turn to them. That is why an audit row names a person rather than a service account.
Least-privilege consumer registration
Live todayA named consumer per tenant with a fixed scope set — including a kill-self scope, so it can be cut off from the inside as well as the outside.
vault read/write/list · usage:read · audit:read
Per-user identity + session binding
Live todayA turn runs on the signing-in user's own Token Holder session, so the record names who did it.
Per-agent key registration + attestation
RoadmapA local agent generates an Ed25519 identity, registers the public key with Token Holder, and Token Holder signs a statement binding it. Live on the local agent host; registration there is fail-open, so an agent that cannot register downgrades to unsigned rather than refusing to run.
The independently-pinnable trust root is narrower than the phrase sounds. Token Holder's public signing key is served on a repeatable route, but that route requires an authenticated consumer — so a stranger holding only a receipt cannot fetch it yet. Until it is open, an outside verifier can check the chain and the per-event signatures, not the trust root behind them.
The verifiability claim is always one click from a way to check it — no account, no trust required.