Every caller is a key↑ Why · Sam lets an AI help, and decides what it sees The agent Sam lets in is a key of its own, so what it may do is what Sam granted that key.↑ Why · Someone checks every claim before trusting it Nothing is trusted for saying who it is; every answer comes from a chain anyone can check.
A caller is known by its key and chain, never by a name or a claim
Two callers that share an identity can't be given different rights.
Shown when two MCP clients on one node, granted different folders, each reads only its own; a call that claims to be from another caller is answered as the key that made it.
How Keys for everything that calls
Not built: nothing in the code or tests names this yet.
A service or an extension has a key the node holds for it
It has to be a caller of its own, on its node and beyond it, without being handed a key it could leak.
Shown when a call one service makes to another node arrives there as that service, by a chain from its node; the service's process holds no key bytes.
How Keys for everything that calls
Not built: nothing in the code or tests names this yet.
A service never receives a key
A service bug must not become an identity.
Shown when the service interface has no key-bearing call.
How Keys for everything that calls
Not built: nothing in the code or tests names this yet.
A service gets each call with its verified caller
Shown when the caller summary matches the verified chain.
How Keys for everything that calls
Not built: nothing in the code or tests names this yet.
What a grant can say↑ Why · Sam lets an AI help, and decides what it sees One folder on the laptop, read but not write, until Friday, is one grant.
Every call is covered by a chain from the account to the caller
The holder must decide alone, offline included.
Shown when a call with a broken, expired or revoked chain is refused.
0 of 1 test passed · 0 places in the code
- not run a broken expired or forged chain is refused
core/tests/seal.rs:66
A delegation can only narrow
No hop may grant more than it holds.
Shown when a chain that widens scope or time is refused.
0 of 1 test passed · 0 places in the code
- not run a chain that widens scope or time is refused
core/tests/seal.rs:83
A grant can name one folder or one file
A grant to a whole service is a grant to everything in it.
Shown when a grant on notes/** reads notes/a.md; notes-old/, a path
through .. and a symlink that points out of notes/ are refused.
Not built: nothing in the code or tests names this yet.
What kind of call a verb is, the holder says
A caller that could call its write a read would fit under any grant.
Shown when a read-only grant can't change a file by any verb, name or argument a client sends.
Not built: nothing in the code or tests names this yet.
A shell outside a box is shown as all of its node
A real shell as your user can do anything you can, whatever the grant around it says.
Shown when granting a terminal outside a box says "everything this node's user can do" before it's confirmed; a grantee that isn't one of your devices can only be given a terminal in a box.
Not built: nothing in the code or tests names this yet.
A grant a holder can't read in full is refused
A restriction a holder skips is a wider grant.
Shown when a grant with a field an older holder doesn't know is refused by that holder, not read as its known part.
Not built: nothing in the code or tests names this yet.
A session loses a grant the moment it expires or is taken back↑ Why · Alex loses a phone, and it opens nothing Taking back a grant stops a session already open, not only the next one.
Shown when with a session reading files, an ungrant from another device makes its next read fail, without the session closing.
Not built: nothing in the code or tests names this yet.
Allow, ask, deny↑ Why · Sam lets an AI help, and decides what it sees What the agent changes waits for Sam, and Sam answers from whichever device is to hand.
Policy answers allow, deny or ask, and only a person answers ask
The caller must never approve itself.
Shown when an ask stays pending until a trusted device answers; an answer signed by the caller, or by any key that isn't one of your devices, is refused.
How An ask, from call to answer
Not built: nothing in the code or tests names this yet.
Whether a call asks is part of its grant
Whoever grants decides whether a person is asked, not whoever wrote the verb, and a caller with no grant gets no, never someone else's yes.
Shown when one verb, two clients: one grant allows, the other asks; a third client with no grant is refused.
Not built: nothing in the code or tests names this yet.
An ask reaches your devices wherever they are
An ask that only an open tab can see times out while you're away from it.
Shown when with no tab open, an ask arrives on a second device, woken by Web Push.
How An ask, from call to answer
Not built: nothing in the code or tests names this yet.
An answer covers exactly the call it was shown
An answer that covers more than was shown is a blank cheque.
Shown when an approved write, sent again with different contents, asks again; a write's ask shows the diff it would make.
How An ask, from call to answer
Not built: nothing in the code or tests names this yet.
Yes can mean once, for this task, or always
Asking every time trains you to say yes without looking.
Shown when once runs one call; for this task covers what was shown until the task ends or an hour passes; always is a grant in the log, listed and revocable like any other.
How An ask, from call to answer
Not built: nothing in the code or tests names this yet.
A yes that widens a grant needs you there, not only your tab
A script running in your tab can sign as your tab.
Shown when always, a new grant, pairing and a terminal outside a box each need a passkey with user verification; signed by the tab alone, they are refused.
How An ask, from call to answer
Not built: nothing in the code or tests names this yet.
Between nodes, and inside one↑ Why · Alex reaches the laptop at home from a café A machine reaching another machine is held to what it was granted, as any caller is.
A machine reaches another only by a grant
A broken-into machine must not be a way into the rest.
Shown when a Member machine with no grant on another machine is refused there; given a grant on one folder, it reads that folder and nothing else.
How Nodes and services calling each other
Not built: nothing in the code or tests names this yet.
A service calling another on its own node is checked like any caller
A bug in one service must not borrow another's reach.
Shown when a service with no grant on files is refused by it; an
extension's manifest is the most it can be granted.
How Nodes and services calling each other
Not built: nothing in the code or tests names this yet.
Nodes that face outward↑ Why · Sam changes the café's page without waiting on anyone Sam's page is served by a node granted the published version, and nothing else of Sam's.
There is no "public". A node that serves people outside your account (a site's worker, a door for agents) is a grantee like any other: what it was granted is the most that can reach anyone through it, and who it serves is its own business.
Granting to a node that faces outward says who will see it
A grant to a worker looks private and is publishing.
Shown when granting read to a node whose manifest says it serves the internet says "anyone can read" the scope before it's confirmed.
Not built: nothing in the code or tests names this yet.
A grant can name a version, not the folder being edited
Otherwise every keystroke is live.
Shown when a grant on site@published reads the published version; edits
since reach it only when the ref moves.
Not built: nothing in the code or tests names this yet.
A grantee can be let add without changing anything
What strangers send through a form must only ever fill a folder.
Shown when an append grant on inbox/ adds a new file; writing over,
moving or removing one is refused.
Not built: nothing in the code or tests names this yet.
What's written down↑ Why · Sam lets an AI help, and decides what it sees Sam can say what each agent read, changed and asked for.
Every call is written down by the node that answered it
The holder is the one place that saw the call, whatever the caller says.
Shown when an MCP client's reads, asks and refusals are listed on another device, each naming the client, the verb and the resource.
How The audit
Not built: nothing in the code or tests names this yet.