Roles & Permissions (Beta)¶
Manifest Platform uses role-based access control (RBAC) to govern what users can see and do across the platform. Every API request, UI action, and agent tool invocation is checked against the caller's assigned roles and their associated permission scopes.
How RBAC Works¶
Each user in an organization is assigned one or more roles. A role is a named collection of permissions, where each permission grants access to a specific action on a specific resource type. Permissions are scoped to an organization, workspace, or solution.
graph LR
U["User"] -->|"assigned"| R["Role"]
R -->|"contains"| P["Permissions"]
P -->|"scoped to"| S["Org / Workspace / Solution"]
Built-in Roles¶
Manifest Platform ships with a set of built-in roles that cover common access patterns. These roles cannot be deleted, but their permissions can be viewed for reference when creating custom roles.
| Role | Description | Typical Use |
|---|---|---|
| Admin | Full access to all organization resources, settings, billing, and user management | Organization owners, IT administrators |
| Solution Builder | Create and manage solutions, components, connectors, and deployments | Developers, data engineers, AI engineers |
| Viewer | Read-only access to solutions, deployments, and dashboards | Stakeholders, auditors, business analysts |
| Billing Manager | Manage subscriptions, view invoices, configure budgets | Finance teams |
| Security Auditor | Read access to audit logs, compliance dashboards, and security settings | Compliance officers, security teams |
Built-in Role Comparison¶
| Permission | Admin | Solution Builder | Viewer | Billing Manager | Security Auditor |
|---|---|---|---|---|---|
| Manage users and roles | Yes | -- | -- | -- | -- |
| Manage organization settings | Yes | -- | -- | -- | -- |
| Manage billing | Yes | -- | -- | Yes | -- |
| Create/edit solutions | Yes | Yes | -- | -- | -- |
| Deploy to dev/staging | Yes | Yes | -- | -- | -- |
| Deploy to production | Yes | -- | -- | -- | -- |
| Manage connectors | Yes | Yes | -- | -- | -- |
| View solutions and dashboards | Yes | Yes | Yes | -- | Yes |
| View audit logs | Yes | -- | -- | -- | Yes |
| View compliance reports | Yes | -- | -- | -- | Yes |
| Run red team evaluations | Yes | Yes | -- | -- | -- |
| Manage API keys | Yes | Yes (own keys) | -- | -- | -- |
Custom Roles¶
When the built-in roles do not match your team structure, create custom roles with exactly the permissions you need.
Creating a Custom Role¶
- Go to Admin > Users & Roles > Roles
- Click Create Role
- Enter a role name and description
- Select permissions from the available list
- Click Save
Coming Soon
The REST API for role management is not yet publicly available.
# Step 1: Create the role
ROLE=$(curl -s -X POST https://api.flow.marut.cloud/api/v1/policy/roles \
-H "Authorization: Bearer $FLOW_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"name": "qa-engineer",
"description": "QA team members who can deploy to staging and view logs",
"org_id": "'$ORG_ID'"
}')
ROLE_ID=$(echo $ROLE | jq -r '.id')
# Step 2: Assign permissions (resource:action format)
curl -X PUT https://api.flow.marut.cloud/api/v1/policy/roles/$ROLE_ID/permissions \
-H "Authorization: Bearer $FLOW_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"permissions": ["solution:read", "deployment:create", "audit:read"]
}'
Permission Reference¶
Permissions follow a resource:action naming convention (colon separator). Some permissions support scope qualifiers.
| Permission | Description |
|---|---|
organization:update |
Manage organization settings |
user:update |
Invite, deactivate, and manage user roles |
billing:write |
Manage subscriptions, view invoices |
solution:create |
Create new solutions |
solution:read |
View solutions and their components |
solution:update |
Edit solution components and configuration |
solution:delete |
Delete solutions |
deployment:create |
Deploy to dev, staging, or production rings |
deployment:update |
Promote or roll back deployments |
connector:create |
Create and configure connector instances |
connector:update |
Manage connector credentials |
component:update |
Configure AI model routing and parameters |
audit:read |
View audit log events |
compliance:read |
View compliance dashboards, reports, and configure frameworks |
api_key:create |
Create and revoke API keys |
Permission Scopes¶
Permissions can be scoped to limit their effect to a specific part of the organization hierarchy.
graph TD
ORG["Organization Scope<br/><i>Applies to everything</i>"]
WS["Workspace Scope<br/><i>Applies within a workspace</i>"]
SOL["Solution Scope<br/><i>Applies to a single solution</i>"]
ORG --> WS
WS --> SOL
| Scope | Effect |
|---|---|
| Organization | Permission applies across all workspaces and solutions |
| Workspace | Permission applies only within the specified workspace |
| Solution | Permission applies only to the specified solution |
Example: A user with solution:update scoped to workspace engineering can edit solutions in that workspace but not in marketing.
Managing Role Assignments¶
Assigning Roles¶
- Go to Admin > Users & Roles
- Select a user
- In the Roles section, click Add Role
- Select the role and scope
- Click Save
Revoking Roles¶
In the user's role list, click the remove icon next to the role you want to revoke. The change takes effect immediately.
Admin role protection
Every organization must have at least one user with the Admin role. The platform prevents you from revoking the last Admin assignment.
Viewing Effective Permissions¶
To see the combined permissions a user has after all role assignments and scoping, go to Admin > Users, select the user, and review their combined role assignments. The effective permissions panel shows every permission the user holds along with its scope.
Best Practices¶
Principle of least privilege
Assign the narrowest role and scope that allows a user to do their job. Start with Viewer access and add permissions as needed.
- Use workspace scoping to isolate teams. A contractor working on one project should not have access to all solutions in the organization.
- Create custom roles for specialized teams rather than over-assigning built-in roles. A QA engineer needs different permissions than a data engineer.
- Audit role assignments regularly. Use the Audit Logs to review who changed role assignments and when.
- Use service accounts for automation. CI/CD pipelines and background jobs should authenticate with API keys tied to a dedicated service account with scoped permissions, not a human user's credentials.