SteelEngine uses policy-based access control (PBAC). A role is a named collection of permissions from the Permission Catalog, not a hard-coded access level. You can assign roles to people or groups for one workspace or for the entire organization.
The old Read, Write, and Admin workspace levels were migrated to the seeded Viewer, Editor, and Workspace Admin roles. Existing access was converted automatically; new access is granted with roles.
Default roles
Every organization starts with six seeded roles. They provide useful defaults and participate in the same policy system as custom roles.
Organization roles
| Default role | Initial purpose |
|---|---|
| Admin | Full organization authority, including organization settings, access management, billing, and workspace administration |
| Supervisor | Read the organization, create workspaces, and manage workspace membership without automatic access to workspace content |
| Member | Read the organization, create workspaces, and use shared credential sets |
Workspace roles
| Default role | Initial purpose |
|---|---|
| Workspace Admin | Viewer and Editor capabilities plus workspace settings, membership, API keys, credentials, inbox, and MCP administration |
| Editor | Viewer capabilities plus workflow, document, table, knowledge, tool, skill, and notification mutations |
| Viewer | Read workspace content, workflows, documents, tables, knowledge, credentials metadata, tools, skills, and MCP server metadata |
The seeded hierarchy starts as:
Member → Supervisor → Admin
Viewer → Editor → Workspace AdminA role on the right inherits the permissions of the role to its left. Organization administrators can edit role names, permissions, and inheritance, so treat the table as the initial configuration rather than an immutable product rule.
SteelEngine blocks any role edit, assignment removal, or member removal that would leave the organization without at least one person able to manage both authorization and organization membership.
Custom roles
Custom roles let you model a job instead of choosing a broad tier. For example:
- A content operator can read and update documents without changing workflows.
- A release manager can read workflows, execute them, and deploy them without managing workspace members.
- A data analyst can query tables and databases without changing their schema.
- An MCP operator can read and manage MCP server connections without seeing credentials.
Create custom roles from Organization Settings → Access → Roles. Choose permissions by resource family and action, optionally add inherited roles, then review the impact preview before saving.
Each permission has a stable catalog key such as:
workspace:read_documents
workspace:update_documents
workflow:execute
table:query
mcp_server:manageRole names are for people. Enforcement uses the permission grants attached to the role, so renaming a role does not change what it can do.
Role inheritance
A role can inherit one or more other roles. The child receives its own grants plus all grants from its parents, including transitive parents.
Use inheritance for reusable layers:
- Create a baseline role such as Workspace Reader.
- Create Document Editor and inherit Workspace Reader.
- Add only document create and update permissions to Document Editor.
SteelEngine prevents inheritance cycles and shows who would gain or lose access before an inheritance change is applied.
Assignments and scope
A role does nothing until it is assigned. An assignment has four parts:
| Part | Meaning |
|---|---|
| Subject | A person or permission group |
| Role | A seeded or custom role |
| Scope | The entire organization or one workspace |
| Source | Direct assignment, group assignment, or organization-wide assignment |
An organization-wide assignment applies anywhere its role's grants match. A workspace assignment applies only to that workspace. Assigning a role does not copy its permissions; edits to the role affect every assignment that uses it.
Effective access
Effective access is calculated at request time from all applicable paths:
- Direct roles assigned to the person
- Roles inherited through permission groups
- Organization-wide roles
- Workspace-scoped roles for the target workspace
- Permissions inherited by each role
- Explicit deny policies, when present
- Product-plan and entitlement requirements
- API-key scope caps for authenticated API and MCP requests
Allows are additive, but an applicable explicit deny wins over an allow. See How Effective Access Is Calculated for examples and troubleshooting.
Workspace ownership
Creating a workspace creates a visible Workspace Admin assignment for its creator. Ownership remains part of the workspace record, but it is not a separate hidden authorization bypass. Access is explained by the creator's role assignment like any other member's access.
Personal organizations
Every account starts in a personal organization with a default workspace. The creator receives the seeded Admin role for the organization and Workspace Admin for the workspace. A personal organization uses the same role, assignment, and policy model as a team organization.