grantr¶

Why: one model of who may do what¶

Before grantr, any user of a tenant could do anything in every workspace of that tenant. artifactr's and reflexr's authorize hook was asked when a workspace was opened, and never heard what the actor was about to do, so a viewer couldn't be kept from editing. A user had exactly one tenant, set in their token. Nothing stored members, groups or roles, and an integration's key was a person's token.

lattice RFC-0001 designs access once, for every surface, and grantr is where its model is built. It imports neither library, and neither imports it: actions cross as strings, and stackr's template wires the two together.

What it does¶

• Check every command and read. The libraries' hook hears the action, such as artifactr:edit_artifact, and asks grantr before each command and read, on REST, WebSocket, MCP and in process (ADR-0001).
• Grant down to threads and artifacts. A role is granted on the deployment, a tenant, a workspace, or a thread, artifact or rule in it; a restricted thread or artifact is hidden from everyone without a role on it (ADR-0002, ADR-0003).
• Act for a user. An agent's turn is checked as the person whose message started it (ADR-0004).
• Own membership. A user's tenants come from grantr, and each request names its tenant (ADR-0005).
• Built-in and custom roles, groups and service principals, with keys shown once, and checks that deny by default (ADR-0006).
• An append-only audit log of every change to access (ADR-0007).
• Its own model, with OpenFGA-shaped ports, in memory or in SQL (ADR-0008).
• A deployment-wide operator role, an audited grant held by few (ADR-0009).
• Keys that can't pass for the libraries' own actors, since a service principal's id can't take theirs (ADR-0028).
• Row-level security under the libraries' scoping, with PostgreSQL keeping each tenant's rows to that tenant (ADR-0026).

stackr's template wires it in by default. RFC-0001 built it in seven phases after the foundation.

Where to go next¶