Users & roles
A member’s baseline in Lunen is one of two words: User or Admin. Users run agents and use what is shared with them. Admins also manage the workspace — team, roles, policies, secrets, and the MCP registry. Everything finer-grained than that is a role you attach on top.
How members join
Membership comes from your identity provider. Invitations are sent from Settings → Team with + Invite to workspace; each invite carries a workspace access level (User or Admin) and appears under Pending invitations until accepted. The first administrator of an organization is whoever holds the admin membership role in your identity provider — there is no in-app bootstrap.
Changing a member’s baseline later is the Workspace access selector on their Team entry. The change takes effect at their next sign-in or immediately via the identity provider’s webhook, whichever comes first — the two paths converge on the same result.
Directory sync (SCIM) is not currently supported. Members arrive through invitations and leave when their membership is removed in the identity provider.
The three built-in roles
Lunen ships three managed roles. A member always holds exactly one of the two baselines; Agent Reviewer is additive.
| Role | Grants |
|---|---|
| Admin | Team, policy, and secret administration, plus access to all agents in the organization. |
| Agent Reviewer | Access to all agents in the organization — without any administration rights. |
| User | Access to the member’s own personal agents. |
Admin and User are assigned automatically from workspace access. Agent Reviewer is assigned by hand, on a member’s Team entry under Roles, and is the right grant for someone who should see every agent and run without being able to change policy.
Custom roles and policies
Roles bundle the policies that grant access to agents, tools, and secrets across Lunen. When the three built-ins are too coarse, create a role under Settings → Roles, attach policies to it, and assign it to members.
A policy is edited as a permission matrix under Settings → Policies. Its sections cover the same ground as the product itself:
| Section | Governs |
|---|---|
| Agents | Creating, listing, deleting, and executing agents. |
| Users | Team management and role assignment. |
| Policies | Policy lifecycle itself. |
| Files | Viewing and managing session file attachments. |
| Secrets | Provider key lifecycle — manage, list, use, delete, per provider. |
| MCP Registry | Registry visibility and org-level enablement. |
| MCP Org / User Credentials | Credential lifecycle at each scope. |
| Audit Log | Audit visibility. |
| Usage | Usage and analytics visibility. |
| Tools | Per-tool Allow/Approve — see Policy & approvals. |
Every check in the product resolves against these policies — pages you cannot access simply do not appear, and server actions re-check before they write. There is no permission that exists outside a policy.
Delegation
A role can be delegated: a member with an active membership can be granted
the right to assume another Lunen role. Grants are managed per role from the
Team pages, and both the grant and the revoke land in the
audit log as role.delegation.grant and
role.delegation.revoke.
Role and policy changes take effect immediately — every mutation invalidates the authorization cache and revokes outstanding session tokens for the affected members. Expect a member’s next action, not their next sign-in, to reflect the change.