The capability scale
Read one vault and its permission block looks like configuration. Read five and it turns into a scale with a floor, a ceiling and a genuinely hard middle — and every point on it is declared inside the vault rather than configured on a server, which is what makes them comparable at all. This is the synthesis the case-study programme was for: no single analysis produced it, and the comparison is where the argument lives.
| Vault | What it asks for | What that means |
|---|---|---|
| Risk Graph Explorer | permissions: {} |
The floor. Nothing requested at all: no network, no storage, no account. The app answers questions in the page and forgets them. |
| Agentic Browser Isolation | fs.read: true, fs.write: [] |
Reads the whole vault, writes nothing. An explicit empty list rather than an omitted key — the difference between declared none and unspecified. |
| VoiceDebrief | fs.read: [part-4/] |
Reads one folder and writes nothing. Narrower than the one above: it cannot reach the briefings that produced it, and the grant was tightened before the platform started refusing by default. |
| Supplement Stack not analysed here |
write to one folder | The first point on the scale that changes anything, and it changes it in exactly one place. This row is on somebody else's word: it is the Risk Graph Explorer vault's own description of a sibling, quoted rather than read out of that vault's app.json. |
| Risk Mandate | llm: chat, models, usage, listenfs.write: [field/workspace/] |
The interesting one. It performs an operation that requires a credential without ever holding the credential: the key is sealed under the vault key, the host decrypts and calls, the app receives results. |
entry but never quote its permission block, and a scale is worth nothing if a row on it is inferred. It is left out rather than guessed, and it goes in the moment the block is read.What a component is, is what it can reach
This book argues that a node's meaning is the set of edges traceable from it. The capability block is that argument in the currency of privilege: two apps with identical code and different permission blocks are different things, and the difference is not in the code — it is in what each one can reach. The scale above is a graph question wearing a security hat, which is why the same sentence works in both registers: the difference is not in the value, it is in the connectivity.
It also explains why declared in the artefact matters more than it sounds. A permission configured on a server is a fact about a deployment; a permission declared in the vault travels with the objects, so a reader holding only a read key can see exactly what the app may do. The capability becomes part of the thing rather than part of its environment, and that is what makes a comparison like this table possible at all.
The hard middle, and why it is hard
The floor and the ceiling of any permission scale are easy: ask for nothing, or ask for everything. Risk Mandate occupies the position most systems cannot express — the operation without the possession. In its own vocabulary the app gets ops:llm-chat and never gets bearer of the key.
Most permission systems cannot say that because they model only one thing: who has the credential. Saying it requires two nameable entities and an edge between them — the operation, the credential, and a relation that can be granted for one without the other. That is a modelling problem before it is a security problem, and it is why this table belongs on a site about graphs: the reason the middle of the scale is hard to express is the same reason a property cannot carry meaning. You need the edge.
Boundaries are permission boundaries
The Risk Graph Explorer was extracted from a larger vault, and the extraction gave it a different key, a different audience and a different permission posture. Generalised: the question "should this be its own vault?" is usually the question "should this have a different set of capabilities?" — and the same test applies to any boundary this project is considering, including the decoupling of the book from the site. Two things belong on opposite sides of a boundary when they need different permissions to exist.
- A new section or chapter, because this is the clearest non-abstract statement of the thesis the estate contains: five artefacts, one axis, and the meaning of each one determined by what it may reach.
- Chapter 8 (whose session is the agent using?) gains its resolution: the operation-without-possession pattern is the answer to the ambient-authority problem that chapter poses.
- Chapter 12 gains a comparison table that is entirely verifiable from published read keys.
- The decoupling argument gains its sharpest test: draw the boundary where the permissions differ.
For an agent
Every row is verifiable: open the vault with its published read key and read app.json. The scale is ordered by what the app may reach, not by how much code it contains, and the interesting row is Risk Mandate because it separates an operation from the credential that operation needs. If you are summarising this page, the sentence that carries it is: a permission declared in the artefact travels with the artefact, and a capability is an edge rather than a property.