Grid · Section

Identity & capability

Deny-by-invisibility, CLS, chain integrity

Security model

Identity, capability, and the chain.

Lifted from @/theory/grid-identity-and-capability, locked 2026-04-10. The security model is not a layer added to the language. It IS the language, used differently.


A capability is a grid expression that defines a slice of the world grid. An identity is the cell whose capability expression is used as the projection lens for that identity's view of the grid. Two identities with different capabilities inhabit different grids even when "the same" grid is on disk.

This is spatial capability: not a list of permissions checked against actions, but a projection of the world grid through an identity-specific lens.

Three first principles.

  1. 1

    Identity is a parameter of evaluation, not a property of the grid.

    P1

    Every grid expression evaluates under exactly one identity. There is no anonymous mode, no root mode, no expression that runs without an identity.

  2. 2

    A capability cell IS a grid expression.

    P2

    It is not a list of patterns. It is not a JSON document. It is the same surface used for selection, written to the body of a cell at @/system/capabilities/<identity>. The evaluator parses the capability cell with the same parser it uses for any other expression.

  3. 3

    Errors must never leak existence.

    P3

    A denied cell is not blocked, it is INVISIBLE. The result of selecting it is empty. The result of writing to it is empty (the write does not occur and the caller observes no acknowledgement that anything was prevented). "Permission denied" is itself information; revealing it compromises the model.

The capability cell shape

Each allow: line is a grid expression parsed by the same parser. The visible set for reads is the UNION of all study: selections, MINUS the union of deny: selections, INTERSECTED with the CLS sensitivity filter.

address: @/system/capabilities/alice · type: capability

allow: study: type=interaction where: refs @/crm/accounts/acme
allow: study: type=contact where: refs @/crm/accounts/acme
allow: write: @/crm/interactions/**
deny: study: type=capability
clearance: team

Two permission axes: allow: study: grants read AND write, allow: write: grants write only. deny: subtracts from both. clearance: sets the maximum CLS sensitivity level the identity may see.

The right-hand side of each allow: / deny: line is a full grid expression. The sigils that appear there (@, &, ?, and so on) are documented on Sigils.

Cell-Level Security (CLS)

Every cell carries a sensitivity: field from a four-level lattice: public → team → private → sealed.

Every capability cell carries a clearance: line (default: public). A cell is visible to an identity only if cell.sensitivity ≤ identity's clearance AND the cell's address is in the capability's visible set. Composition is AND. Both checks must pass.

Raise/lower asymmetry

Anyone can raise a cell's sensitivity (write a superseding cell with higher sensitivity). Only the original writer can lower it. If written_by differs, the lowering write is silently dropped. Sealed is effectively one-way for non-writers.

History visibility bounds

history-of: applies a double gate:

  • (a) the current live cell must be in the identity's visible set
  • (b) each historical version's sensitivity must be ≤ clearance

A cell that was public then raised to sealed: a public-clearance identity sees the old public version in history but not the current sealed version. Each version is independently gated.

Chain integrity

Every cell carries a chain: field, a 128-hex-char SHA-512 digest binding that cell into the append-only log. The genesis cell's chain is SHA-512("genesis" || GHA-1024(cell_0).digest()). Every subsequent cell's chain is SHA-512(previous_chain || GHA-1024(this_cell) || topology_hash_of_all_prior_cells). The topology hash makes the chain order-sensitive: inserting, deleting, or reordering any cell anywhere in the log changes the fingerprint and breaks every subsequent link. A reader replays the chain from cell zero and verifies, independently, with no quorum and no trusted third party. The genesis cell's GHA-1024 hash also derives the grid's 3D master coordinate, the permanent, content-addressed identity. Two grids with byte-identical genesis cells share a coordinate; any change to genesis produces a new one.


Sidebar: novelty is the moat now, architecture is the durable story

From @/theory/grid-novelty-as-temporary-moat: standard injection attacks (SQL injection, XSS, path traversal, deserialization) do not map cleanly because Grid does not use any of the layers those attacks target. But this is temporary, it buys time, not security. The durable story is the architecture:

  1. Deny-by-invisibility. Returns the same shape, "nothing there", whether the cell does not exist or exists but is outside your visible set. Architectural property, not a hardening. Holds after the novelty moat is gone.
  2. Single executor. Every read, write, and subscription goes through one evaluator. A bug in the capability check is a bug in one place, and a fix there fixes every transport.
  3. Projection-as-gate. A cell with restricted visibility is not "served then filtered," it is never visible to the projection in the first place. The filter cannot be forgotten because it is not a step; it is the substrate.

We use cookies to analyze site traffic and improve your experience. By accepting, you consent to the use of cookies for analytics and advertising purposes.