User Roles

Alloy uses organization membership roles for customer workspaces, plus a separate internal developer access flag for Alloy internal team.

Customer users have one organization role in each workspace:

• `member` — regular workspace access.
• `admin` — elevated workspace access for organization management tasks.
• `owner` — highest workspace role, used for ownership-level actions such as changing human user roles.

Most customer-facing permission checks are based on the user's current organization membership. When a surface is described as org-admin gated, both `admin` and `owner` users should be treated as passing that gate unless the surface explicitly requires owner-only access.

Access Groups add resource-level authorization beneath organization roles:

• Owners and admins can manage Access Groups and have organization-wide read and update access to AI teammates, conversations, workflow runs, and related activity, including resources tied to personal Allies.
• Members receive the union of regular AI teammates granted through their active Access Groups.
• Members can read and update accessible AI teammates, but cannot create or delete AI teammates.
• A member's own personal Ally is available separately from group grants.
• For members, Access Group scope is enforced server-side beyond the teammate catalog: conversation visibility, execution-log and workflow-run reads, and the dashboard activity feed are limited to granted regular AI teammates plus the member's own personal Ally.
• Staff deliberately hides other users' personal Allies even from owners and admins; that list filter does not reduce their backend organization-wide authorization.

See `access-groups.md` for management, assignment, API, and realtime behavior.

`developer` is not a customer role and is not be granted to customer users.

Developer access is an internal Alloy platform flag used by Alloy's own team for support, operations, and system administration surfaces. Developer-gated pages may expose tools that are not part of normal customer workspace administration.

Treat developer access as an Alloy-operator capability, not as part of the customer role hierarchy.

User roles are only one part of Alloy permissions. Human access to regular AI teammates is controlled through Access Groups. Each AI teammate's own capabilities are controlled separately through storage folder sharing, enabled tools, enabled MCP servers, and other teammate settings.