Grants

Three levels, per environment, per person.

Level	Can read values	Can change values	Rendered as
No access	no	no	dashed outline, faint — an absence
Read	yes	no	neutral chip
Write	yes	yes	blue chip

The default is no access, on every environment. A new member gets nothing until you grant it. This is invariant 5, and it is structural rather than a default someone could change: the database has no default role, and the absence of a grant row is what no-access means. “Accidentally granted” is not representable.

One asterisk on read, since personal overrides shipped: a member with a read grant can write their own personal overlay on that environment — values only they can decrypt, never the shared stream. The shared write gate is unchanged, and no grant at all still means the uniform not-found on every surface. The feature exists for exactly the read-only collaborator who needs a personal token.

Granting

Granting an environment to someone wraps that environment’s key to their public key. It requires that you have verified their fingerprint — a member with no verified key cannot be granted anything, and the attempt fails rather than silently trusting the server’s copy of their key.

Read versus write

Read and write are enforced by the server, not by cryptography. Anyone with either level holds the environment’s key and can therefore decrypt every value in it.

That distinction is worth being clear about, because it is easy to assume otherwise: read-only is not a cryptographic boundary. It stops the server from accepting their writes. It does not stop them knowing the values, and it could not — they need the key to read at all.

If you need someone to be unable to know a value, the level you want is no access.

A personal overlay does not weaken any of this: writing your own override changes nothing anyone else ever decrypts.

Roles are not access

A project admin can invite people, change roles, and manage grants. That is administrative power over membership, and it is not the same as access to secrets.

An admin with no grant on production cannot read production. They can grant it to themselves — they have the administrative power to — but that action writes an audit row with their name on it, which is the point. Silent access and deliberate, attributable access are different things.

See roles.

Revoking

Revoking deletes the wrapped key, which stops future reads.

It does not un-share what was already read, and Cendarum will tell you so and offer to rotate. Take the offer: see rotation.

Reading the matrix

The members screen is a grid: people down the side, environments across the top, current level in each cell. Production is amber, with a shield glyph and its name, so the distinction survives for a colour-blind reader and in a screenshot.

It is deliberately the boring view. “Who can read production” should be answerable by looking at one column, not by reasoning about inherited roles.