Groups & roles

Access in LEMA Chat rests on two ideas: groups decide who and what knowledge belong together, and roles decide what a person can do. Together with the anti-escalation rule, they make access safe by construction.

Groups & clearance

• A group is the single unit of both membership and clearance.
• Every user has an implicit personal group.
• Brains and integrations are granted to groups, at levels read / write / admin.
• A Brain or integration is usable in a chat only when every group present in the chat holds at least read on it — the clearance intersection — further narrowed to what the querying principal can personally read.

The practical upshot: you grant access to groups, and the platform computes what's usable in any given room. Adding a less-cleared group to a chat narrows what's available there. Access fails closed.

📸 Screenshot: granting a group read/write on a Brain.

Dynamic roles

Roles are data-defined, not hard-coded. Alongside the built-in roles (Owner, Admin, Member, Curator, Facilitator — plus the platform LCAdmin and SuperAdmin tiers), you can create workspace roles with a chosen set of permission checkboxes, and assign / unassign them per member.

• A member's effective permissions are the union of their assigned roles.
• Manage roles on the Admin console's Roles page.

The anti-escalation rule

When you build or edit a role, only the permissions you hold yourself are offered. A role can never grant more than its creator has.

Only permissions you hold yourself are offered: a role can never grant more than its creator has (anti-escalation).

This is enforced on both sides — the console filters the checkboxes to your own effective permissions, and the server independently re-checks. The same invariant governs API keys (a key never exceeds its owner) and agent turns (an agent acts within its own clearance).

How it all composes

• Groups → clearance (what knowledge is allowed in a room).
• Roles → capabilities (what a person can do).
• Anti-escalation → nobody can mint power they don't have.

This is the model behind ADR-0010 (groups, clearance, Brains, and capabilities); the clearance intersection is enforced centrally in the platform's access-control layer.