Skip to main content
MagOneAI uses a tiered role-based access control (RBAC) system to manage user permissions. Roles are assigned at both the organization and project level, allowing you to grant exactly the access each user needs while maintaining strict isolation between organizations.

​
Role hierarchy

The RBAC system follows a hierarchical structure with three distinct scopes:
  1. Platform level — SuperAdmin role for platform-wide administration
  2. Organization level — Org Owner and Org Member roles for organization management
  3. Project level — Project Owner and Project Member roles for project-specific work
  4. Consumer level — End User role for workflow execution and chat
Each level inherits certain capabilities from the levels below while adding administrative permissions at its scope.

​
Role definitions

Scope: Entire MagOneAI platformSuperAdmins have complete control over the platform but operate within clear boundaries to ensure organization data isolation.Capabilities:
  • Create and manage all organizations
  • Assign Org Owners and manage organization membership
  • Configure platform-level model providers and credentials
  • Access the Admin Portal for platform administration
  • View platform-wide audit logs and usage metrics
  • Manage platform settings and infrastructure configuration
Limitations:
  • Cannot access organization-specific data or resources directly
  • Organization data remains isolated — SuperAdmins manage the containers, not the contents
  • Cannot execute workflows or create agents (must be assigned an org/project role)
Who needs this role: Platform administrators responsible for managing the entire MagOneAI installation. In most deployments, this is 1-2 people.
Scope: Single organizationOrg Owners have complete control within their organization and act as administrators for their business unit or department.Capabilities:
  • Create and manage projects within the organization
  • Add and remove organization members
  • Assign organization and project roles to members
  • Configure organization-level model providers
  • Set organization policies and quotas
  • View organization-wide audit logs and cost tracking
  • Access all projects within the organization
Limitations:
  • Cannot access other organizations or platform settings
  • Cannot manage SuperAdmins or platform-level configuration
  • Cannot view or modify platform-level provider configurations
Who needs this role: Department heads, team leads, or administrators responsible for managing an entire business unit’s AI resources.
Scope: Assigned projects within an organizationOrg Members are standard users who can access and work within projects they’re assigned to.Capabilities:
  • Access projects they’re explicitly assigned to
  • Create and manage resources (agents, workflows, tools, knowledge bases) within assigned projects
  • Execute workflows and chat with agents in assigned projects
  • View project-level audit logs and usage metrics
  • Collaborate with other project members
Limitations:
  • Cannot create new projects (must request from Org Owner)
  • Cannot manage organization settings or membership
  • Cannot access projects they’re not assigned to
  • Cannot configure model providers
Who needs this role: Most users in an organization. Developers, analysts, and operators who build and run agents and workflows.
Scope: Single projectProject Owners have complete control within a specific project, including managing project members and settings.Capabilities:
  • Full access to all project resources (agents, workflows, tools, knowledge bases)
  • Add and remove project members
  • Assign Project Owner and Project Member roles within the project
  • Configure project settings and policies
  • Delete or archive the project
  • View project audit logs and cost tracking
  • Share agents to MagOneAI Hub
Limitations:
  • Cannot access other projects or organization settings
  • Cannot create new projects (must be Org Owner or Org Member requesting a new project)
  • Cannot configure model providers (uses organization-level configuration)
Who needs this role: Project leads responsible for a specific use case or application. Typically 1-3 people per project.
Scope: Single projectProject Members are contributors who create and manage resources within a project but cannot change project settings or membership.Capabilities:
  • Create and edit agents, workflows, tools, and knowledge bases
  • Execute workflows and test agents
  • View project resources and audit logs
  • Collaborate with other project members
  • Use Studio for development
Limitations:
  • Cannot manage project members or settings
  • Cannot delete the project
  • Cannot share agents to MagOneAI Hub (Project Owner approval required)
  • Cannot configure project-level policies
Who needs this role: Developers and builders working on agents and workflows. Most project users should have this role.
Scope: MagOneAI Hub onlyEnd Users are consumers of agents and workflows. They have no access to Studio or Admin Portal.Capabilities:
  • Chat with agents published to MagOneAI Hub
  • Trigger workflows they have access to
  • Complete human tasks assigned to them
  • View their conversation history
  • Access mobile and web Hub interfaces
Limitations:
  • Cannot access Studio, Admin Portal, or any development tools
  • Cannot create or modify agents, workflows, or other resources
  • Cannot view audit logs or system configuration
  • Limited to consuming published agents and workflows
Who needs this role: Business users, customers, or anyone who needs to interact with agents without building them. Sales teams using a CRM agent, support teams using a help desk agent, etc.

​
Permissions matrix

This table shows the specific permissions granted to each role:
PermissionSuperAdminOrg OwnerOrg MemberProject OwnerProject MemberEnd User
Manage organizations✓-----
Manage users (platform)✓-----
Configure platform providers✓-----
Create organizations✓-----
Create projects-✓----
Manage org members-✓----
Configure org providers-✓----
Access all org projects-✓----
Manage project members-✓-✓--
Manage project settings-✓-✓--
Create agents-✓✓✓✓-
Create workflows-✓✓✓✓-
Create tools (MCP)-✓✓✓✓-
Create knowledge bases-✓✓✓✓-
Execute workflows-✓✓✓✓✓
Chat with agents-✓✓✓✓✓
Complete human tasks-✓✓✓✓✓
Access Studio-✓✓✓✓-
Access Admin Portal✓-----
Access MagOneAI Hub-✓✓✓✓✓
View platform audit logs✓-----
View org audit logs-✓----
View project audit logs-✓✓✓✓-
Share agents to Hub-✓-✓--
Delete projects-✓-✓--

​
Organization isolation

Organization isolation is a fundamental security principle in MagOneAI. Each organization functions as a complete data boundary with no cross-organization access.

​
Isolation guarantees

  • Data isolation — Organizations cannot see or access data from other organizations. This includes agents, workflows, execution logs, knowledge bases, and all metadata.
  • User isolation — Users belong to specific organizations. A user in Organization A has no visibility into Organization B, even if the same person is a member of both organizations with different user accounts.
  • Provider isolation — Model provider configurations are scoped to organizations. Credentials configured in one organization are not accessible to others.
  • Audit isolation — Audit logs are scoped to organizations. Org Owners can only view logs for their organization.

​
SuperAdmin boundaries

SuperAdmins can perform administrative functions across organizations, but they respect data boundaries:
  • Can do: Create organizations, assign Org Owners, configure platform-level providers, view platform metrics
  • Cannot do: Access organization-specific agents, workflows, or execution data without being explicitly granted an Org Owner or Org Member role
This ensures that platform administrators can manage the system without compromising organizational data privacy.

​
API key management

API keys provide programmatic access to MagOneAI workflows and agents. Keys are scoped to projects and inherit the permissions of the user who created them.

​
Creating API keys

1

Navigate to project settings

In Studio, go to the project where you need API access and open Settings.
2

Generate a new API key

Click “Create API Key” and provide a descriptive name (e.g., “Production deployment - ETL workflow”).
3

Set key permissions

Choose whether the key can execute workflows, chat with agents, or both. Keys cannot create or modify resources.
4

Store the key securely

Copy the key and store it in your secrets management system (like HashiCorp Vault). The key is only shown once.

​
Key rotation

To rotate an API key without downtime:
  1. Create a new API key with the same permissions
  2. Update your application to use the new key
  3. Verify the new key is working in production
  4. Revoke the old key
The old key remains active until explicitly revoked, allowing for zero-downtime rotation.

​
Key revocation

Revoke a key immediately if:
  • The key is compromised or accidentally exposed
  • The user who created the key leaves the organization
  • The key is no longer needed
Revocation is instant — all requests using the revoked key will fail immediately.

​
Audit trail

All API key usage is logged in the project audit trail:
  • Key creation with creator and permissions
  • Every API request with key ID, endpoint, and timestamp
  • Key revocation with user and reason
Follow the principle of least privilege when creating API keys. Assign users the minimum role they need to do their job. Most users should be Project Members or End Users, not Org Owners or Project Owners. Create separate keys for different applications and revoke keys as soon as they’re no longer needed.

​
Role assignment workflows

​
Adding a new organization member

1

Invite the user

As an Org Owner, navigate to Organization Settings → Members and click “Invite Member”.
2

Assign organization role

Choose whether the user should be an Org Member (standard) or Org Owner (administrator).
3

Assign to projects

Select which projects the user should access and their role in each (Project Owner or Project Member).
4

User accepts invitation

The user receives an email invitation and creates their account or links their SSO identity.

​
Promoting a user to Project Owner

1

Review current access

Ensure the user is already a Project Member and has demonstrated the need for elevated permissions.
2

Update role

As an Org Owner or existing Project Owner, go to Project Settings → Members and change the user’s role to Project Owner.
3

Communicate responsibilities

Inform the user of their new responsibilities, including managing project members and settings.

​
Offboarding a user

1

Revoke organization access

As an Org Owner, remove the user from the organization in Organization Settings → Members.
2

Revoke API keys

Revoke any API keys created by the user in all projects they had access to.
3

Revoke OAuth tokens

If the user had OAuth integrations, revoke their tokens in the Admin Portal or organization settings.
4

Review audit logs

Check audit logs for any unusual activity during the user’s final days of access.

​
Best practices

Apply least privilege

Assign the minimum role needed for each user’s responsibilities. Most users should be Project Members or End Users.

Regular access reviews

Quarterly review of all user roles and permissions. Remove access for inactive users.

Separate production and development

Use different projects for development and production with separate team assignments.

Limit Org Owners

Typically 2-3 Org Owners per organization. Too many reduces accountability.

Document role decisions

Maintain documentation explaining why each user has their assigned role.

Automate offboarding

Integrate with your HR system to automatically revoke access when employees leave.
Role-based access control is most effective when combined with other security measures. Use RBAC alongside HashiCorp Vault for secrets management, comprehensive audit logging, and network-level security controls for defense-in-depth.

​
Next steps

Secrets and Vault

Protect credentials with HashiCorp Vault integration

Audit and monitoring

Track all user actions with comprehensive audit trails