# Trust model

> What a seal proves, who vouches for each part of it, and what it can't tell anyone.

A seal is only worth what the party who watched the writing can't fake. This page sets out who watches what when you build on Proof, so you can say accurately what a seal means to your users and to the people who read their work.

## Two parties, two claims

Every seal made on your platform rests on two claims from two parties:

- **Proof observes the writing.** Every change in the editor travels from Proof's own code, on Proof's own domain, to Proof's servers. Proof decides which words were typed, shaped, written by an agent or pasted, and when a person was present.
- **You vouch for who wrote it.** Proof has no accounts. When your server creates a user for your id `u_42`, named Ada Lovelace, and starts editor sessions for them, Proof takes your word for it.

The seal page says both. A seal made in Acme Notes reads "Written in Acme Notes", and the people on it are named as Acme Notes named them, with a note that Acme Notes vouches for who they are.

## What Proof observes directly

| Signal | How Proof knows |
| --- | --- |
| Typed text | Each change arrives over the editor's own connection, from keys pressed in the editor. |
| Pasted and imported text | Text that arrives without keys pressed for it, from a paste, a drop, or a tool driving the browser, is counted as external. |
| Agent text | Agents write only through Proof's MCP server, under their own tokens, so their words carry their own credit. |
| Shaped text | Words of an agent's sentence that a person changed afterwards, while the change lasts. |
| Presence | Every half minute while a writer's editor is visible, the browser reports whether they typed or pointed there, from events the browser itself sent. |
| A real browser | Each editor connection earns a Cloudflare Turnstile token when it first writes and every few minutes after. Proof keeps whether it passed. |
| Check-ins | Taps of a security key registered on Proof's domain, answered within a minute of being asked. |

Your page can't reach any of these. The editor is a cross-origin iframe: your scripts can't read it, type into it or change what it sends. Embed origins in the console decide which sites may show it at all.

## What you vouch for

- **Identity.** Names, pictures and the detail line come from you. If your sign-in is weak, so is the name on a seal.
- **Access.** Who may open, edit or suggest in a document is your decision, stored at Proof through your API calls.
- **Agent approvals.** A person approves an agent on your consent page, signed in to your product. Proof records that you said this person approved it.

Your secret key can start an editor session as any of your users. That is what lets you build without Proof accounts, and it's also the main thing to protect. Each seal records which of your keys started the sessions behind it, so if a key leaks you can revoke it and find the seals whose sessions it started.

## What nobody can fake easily

A check-in needs a physical tap on a security key at the moment Proof asks. A script can't do it, and neither can your server. That makes check-ins the strongest signal on a seal: when every sitting with writing in it is covered, Presence reads Verified Presence and the seal line ends "(verified)".

A tap shows that someone with that key was at the keyboard when asked. It doesn't show which person. Keys are registered in a window on Proof's domain, opened with a session you start, so who registered a key rests on your sign-in too.

## What a seal can't tell anyone

- **Where ideas came from.** Someone retyping text from another window, by hand, is typing. A seal shows how the words got into the editor, not whose thinking they were.
- **What happened outside the editor.** Drafts written elsewhere and pasted in count as external, with their origin unknown.
- **Who a person is beyond your word.** See above.

Seals don't change after they're made. Each records the version of the method that produced its numbers; when the method improves, a seal page shows the new reading beside the old one and never rewrites it. A seal can be withdrawn, and its page then says so.

## Attacks and what stops them

| Someone tries to | What stops it | What's left |
| --- | --- | --- |
| Inject text from your page into the editor | The iframe is cross-origin; your page can't script it | Nothing, short of compromising the browser |
| Pass agent text off as typed | Agents write through MCP under their own credit; text inserted without key presses counts as external | Retyping by hand |
| Type with a script driving a browser | No key presses means external; Turnstile results are kept | A script faking key events in a real browser; check-ins catch the absence of a person |
| Start sessions as your users with your key | Seals record which key started each session | You remain the authority on identity |
| Edit a document after sealing it | Seals are snapshots; a version can't change | Sealing again makes a new version, which is shown as new |
| Rescore an old seal | Each seal keeps its method version | Newer readings appear beside, labeled |

## What to tell your users

Keep it to what is true for everyone: a seal shows where each word in the document came from and how much of the writing time a person was present, as recorded by Proof, for a person your product signed in. With check-ins on, it also shows that someone with their security key was there throughout.