Access control
How roles, groups, and per-user overrides combine to decide what someone can do, and where you manage each of them
Overview
Every action in MagOneAI is a named capability, for example usecase.edit, kb.view, or execution.view.any. There are around 125 of them, spanning agents, use cases, executions, knowledge bases, secrets, SSO, billing, and the rest of the platform.
A role is a bundle of those actions. It is not a hard-coded label with behaviour attached, which means an administrator can build a role that grants exactly what a job needs, rather than picking the closest of a fixed set.
Permission reaches a person through four channels:
| Source | What it is |
|---|---|
| Default | The floor every signed-in user gets, with no assignment at all |
| Role | A role assigned to them directly |
| Group | A role attached to a group they belong to |
| Direct override | A single action allowed or denied for that one person |
Those four combine into an effective permission set. The rest of this page is how they interact.
Role names have not changed. If you have been using Organization Owner, Organization Admin, and the four project roles, they all still exist and still mean what they meant. What changed is the machinery underneath, and the fact that you can now go beyond them.
Where you manage it
Studio — Access
Per workspace: see who can do what, and why. Grant a role, scope it to a project, and set an expiry.
Superadmin — Access Control
Platform-wide: browse the action catalog, build and edit roles, pick a workspace to administer.
Superadmin — Org Groups
Create groups, add members, and attach roles to them.
Superadmin — Apps Catalog
Register portals and project-derived apps, and control who may open them.
The seeded roles
Every organization is seeded with these. They are cumulative: each inherits everything in the tier below it.
| Role | Inherits |
|---|---|
| Default | The floor. Undeletable, and held by every user with no other assignment |
| Project Viewer | Default |
| Project Operator | Project Viewer |
| Project Builder | Project Operator |
| Project Admin | Project Builder |
| Organization Admin | Project Admin |
| Organization Owner | Organization Admin |
| Platform Superadmin | Everything, and exempt from the limits below |
You are not restricted to these. Build your own in Superadmin → Access Control by selecting actions from the catalog.
Groups
A group is a set of people with roles attached to it. Put someone in the group and they pick up its roles; remove them and the roles go with them.
Groups ship with presets that mirror the project tiers: Viewers, Operators, Builders, and Project Admins.
Reach for a group when the same permission set belongs to more than one person. Reach for a direct role assignment when it genuinely applies to one individual.
A group belongs to exactly one organization. A group in one workspace never grants anything in another.
Direct overrides, and why deny always wins
An override grants or denies a single action for a single person, on top of whatever their roles and groups already give them.
A deny beats every allow, no matter where either was written. A deny on a role, a group, or the person directly will block the action even if three other sources allow it. There is no ordering to reason about and no "most specific wins" subtlety: if anything denies, the answer is no.
This is what makes exception handling expressible. To say "everyone in Support, except Priya", you grant the Support group its role and write one deny override on Priya. You do not have to build a second group or fragment the role.
Because deny always wins, a stray deny override is the first thing to look for when someone unexpectedly cannot do their job. It will silently outrank a role you can plainly see they hold. The effective-permissions view described below is the fastest way to find one.
Scoping and expiring a grant
When you grant a role in Studio → Access, two things narrow it:
- Scope it to a project. The grant applies only to that project, rather than everywhere the person can already reach.
- Give it an expiry. Set a date and time and the grant lapses on its own. Useful for contractors, incident response, and temporary cover, none of which should rely on someone remembering to revoke access later.
A targeted grant and a broad one do different jobs. A broad grant narrows what you may do on projects you can already reach. A grant targeted at one project establishes access to that project specifically. Without that distinction, holding Project Operator anywhere would hand you execute rights on every project in the organization.
Seeing why someone has access
The Studio Access page answers "who can do what in this workspace, and why". Open a person and you see each permission with the source that supplied it.
A permission reachable two ways is listed twice, once per source. That is deliberate. If someone holds usecase.edit both directly and through a group, you need to see both, because revoking the direct assignment on its own would not take the access away. Collapsing it to one "winning" source would hide the exact thing you are trying to find.
When someone leaves
Removing a person from an organization revokes everything they held by virtue of that organization: their role assignments, their group memberships, and their per-user allows. Removal and revocation happen together, so there is no window where someone is off the member list but still holds access.
Four details matter when you are cleaning up or investigating:
- Grants are deactivated, not deleted. The record of who held what, and when, survives an offboarding. That is exactly the evidence an incident review needs, and a hard delete would destroy it.
- Re-adding someone does not restore their old access. They come back with the Default floor and nothing else. If an admin removed a person to strip their access, an accidental re-add must not quietly hand it all back. Restoring bespoke grants is a deliberate re-assignment.
- Denies are left in place. Revocation removes grants, not restrictions. A deny that survives a remove-then-re-add cycle errs on the side of less access, which is the safe direction.
- Platform-wide assignments are untouched. One organization removing a member never strips a grant the platform, or a different organization, made. They are not that tenant's to revoke.
If revocation fails, the removal fails with it. A half-offboarded user whose grants survived is the exact state this exists to prevent, and an operator who saw "removed" succeed would never go back and check.
Working across organizations
A few surfaces deliberately span tenants. Your human-task inbox and your project list both mean "everything of mine, everywhere I belong", not "everything in one workspace".
These split the decision in two:
- Can you open the surface at all? Answered once. Holding the action in any organization you belong to is enough to see the inbox.
- Which rows do you see? Answered per organization, independently. Each tenant decides about its own rows with no reference to any other.
A deny in one workspace removes that workspace's rows and nothing else. It cannot reach into another tenant's data, and equally it cannot be escaped by holding the same permission elsewhere. A workspace saying "this person has no task inbox here" holds, even if the same person is an admin in three other workspaces.
Cross-org filtering only ever narrows a list. An organization that cannot be decided about, because enforcement is off, it has not been migrated, or the person holds nothing there, keeps its rows. A shadow-mode deny is recorded and then ignored. Only an enforced deny actually removes anything, so turning enforcement on or moving a tenant to shadow can never change what a list returns.
Requesting access
Where a surface is set up for it, a user who cannot reach something can request access rather than filing a ticket. A request is Pending until an administrator approves or denies it.
Two cases return an error rather than creating a request:
- You already have access. The request is rejected instead of creating a duplicate.
- The surface is not open to requests. Not everything is requestable; that is a deliberate setting, not an oversight.
What an administrator can grant
You cannot grant what you do not hold. An organization admin cannot build a role containing SSO configuration, LLM configs, or org vault access unless they hold those actions themselves. Without this ceiling, anyone able to administer roles could grant themselves everything, which is not administration but escalation.
Three deliberate exceptions:
- A Platform Superadmin may grant anything. Role administration is where you go to fix a lockout, so break-glass has to stay above the ceiling.
- A deny is never blocked. Denying an action you do not hold only removes access, so it cannot escalate anything. The "everyone except Priya" workflow depends on this.
- An existing role may already contain more than its editor holds. Seeded roles are richer than most operators, and editing one does not force you to strip it back to your own level.
Rolling it out
Enforcement is set per organization and per action, so a tenant can be moved over gradually rather than all at once.
| Mode | Behaviour |
|---|---|
| Enforce | Denials are applied. This is the default |
| Shadow | Denials are recorded and counted but not applied, so you can see what would break before it does |
| Off | No decision is made for that scope |
Two safety valves exist so an incomplete rollout fails open rather than locking people out. An organization that has not been migrated is passed through, and a user holding no role at all is passed through. Both are logged loudly.
Holding no role and holding a role that grants nothing are not the same. The first is a seeding gap and passes through; the second is a deliberate policy outcome and denies. Emptying a role is therefore a real change with real consequences, not a way to reset someone to neutral.