---
"@type": Article
"@id": "https://helloloam.dev/principles/fine-grained-permissions"
"@source": "https://helloloam.dev/data/article/fine-grained-permissions.json"
"@stamp": "2026-10-22T21:53:55+00:00"
about:
  "@type": DefinedTerm
  "@id": "https://helloloam.dev/data/definedterm/fine-grained-permissions.json"
  name: Fine-grained permissions
  identifier: fine-grained-permissions
  inDefinedTermSet:
    "@type": DefinedTermSet
    "@id": "https://helloloam.dev/data/definedtermset/mechanics.json"
    name: Mechanics
    identifier: mechanics
author: {"@id":"https://helloloam.dev/#organization"}
datePublished: "2026-10-03"
description: Access is a key, not an account. Each key carries a small, explicit set of rights — and nothing it does not say.
headline: Fine-grained permissions
identifier: fine-grained-permissions
inLanguage: en
publisher: {"@id":"https://helloloam.dev/#organization"}
url: "https://helloloam.dev/principles/fine-grained-permissions"
---

# Fine-grained permissions

## Keys, not accounts

A loam site has no users, roles or groups. A key belongs to a person or an agent, says what it may do, and carries the secret that proves it. The site keeps a fingerprint of that secret, never the secret itself. A key is shown once; lose it and you make a new one.

## The grid

A key's rights are a grid. Each cell is granted on its own, and none implies another.

|  | read | write | remove |
| --- | --- | --- | --- |
| **Content** | see pages and drafts | stage changes | drop drafts |
| **Templates** | see the design source | change the design | drop template drafts |
| **Files** | see images and files | upload | drop file drafts |
| **The guide** | see the site's notes for agents | write a note | drop note drafts |

Read-only views stand apart: the journal, the form inbox, the plan, the list of keys — each granted separately. Setting the plan is the owner's act alone. The inbox holds personal data and is given sparingly.

## Publish and take back

Two rights concern the live site, and they are kept apart on purpose. **Publish** makes drafts live; **take back** returns something live to draft. A key that may write but not publish can do real work and no harm. Most keys that publish should never be able to empty the site.

## Keys in practice

| Key for | Rights |
| --- | --- |
| **Copywriter** | read and write content, no publish |
| **Design agency** | read and write templates, no content, no publish |
| **Auditor** | read everything, write nothing |

A request outside a key's rights is refused with the missing right named — “this key may write content but not publish it” — so the refusal tells you who to ask.

## Handing out keys

The owner's key may hand out keys, and may let another key do the same. Two rules keep that safe: nobody hands out more than they hold, and nobody manages a key beyond their own reach. Delegation can go several levels deep without the owner losing the top. When someone leaves, you revoke their key — nothing else needs cleaning up.

## A key is not a person

Two things every other system folds into “users” are kept apart. Who is named on the site — an author, a speaker, a team member — is content: a public `Person`. Who may write is access: a key with rights, never public. An author needs no key, an agent's key is no person, and who published what is [the journal's business](/principles/mcp-with-a-trust-model).

## What it costs

You decide every key. The template right deserves the most thought: templates are code, so whoever may write them can make the site do anything. It goes only to people you fully trust. And a key is only as safe as the account behind the agent that holds it.