> ## Documentation Index
> Fetch the complete documentation index at: https://docs.myrmex.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Native Roles

> Pre-configured roles designed to cover the most common operational needs.

import { AccordionGroup, Accordion, Warning, Note } from "@mintlify/components";

The Myrmex platform comes with five native roles designed to cover the most common operational needs. These roles are automatically created for every organization and cannot be deleted or modified, ensuring consistent security baselines across the ecosystem.

<AccordionGroup>
  <Accordion title="Super Admin - Full Control" icon="crown">
    **Full Access.** The highest privilege level with unrestricted access to all platform features and resources.

    **Typical Use Cases:**

    * Organization owners
    * C-level executives
    * Platform administrators

    **Key Capabilities:**

    * Manage all organizational settings and billing
    * Create/Delete users and assign any role
    * Access all devices, integrations, and sites across all contexts
    * Manage sub-organizations (Enterprise)

    <Warning>
      Limit Super Admin access to trusted personnel only. This role has unrestricted access and can make irreversible changes.
    </Warning>
  </Accordion>

  <Accordion title="Admin - Operations Management" icon="user-tie">
    **Operational Control.** Designed for day-to-day operational management without access to sensitive billing or critical organizational changes.

    **Typical Use Cases:**

    * Security operations managers
    * IT administrators
    * Team leads

    **Key Capabilities:**

    * Manage users, devices, integrations, and sites
    * Execute actions on integrations and devices
    * Manage security cases and run playbooks/runbooks
    * View billing information (read-only)

    **Restrictions:** Cannot delete the organization, change billing, or create sub-organizations.
  </Accordion>

  <Accordion title="Analyst - Security Operations" icon="magnifying-glass">
    **Security Operations.** Designed for security analysts who need to operate security tools and investigate incidents.

    **Typical Use Cases:**

    * SOC analysts (Tier 1, 2, 3)
    * Security engineers
    * Incident responders

    **Key Capabilities:**

    * Full management of devices and integrations
    * Execute actions and commands
    * Generate and view reports
    * Access chat and artifacts

    **Restrictions:** Cannot manage users, roles, or organization settings. Read-only access to playbooks.
  </Accordion>

  <Accordion title="Viewer - Read-Only Access" icon="eye">
    **Read-Only.** Perfect for auditors, stakeholders, or temporary access needs.

    **Typical Use Cases:**

    * External auditors
    * Management oversight
    * Compliance officers

    **Key Capabilities:**

    * View all devices, integrations, and configurations
    * View and download reports
    * Access chat and read artifacts

    **Restrictions:** Cannot create, update, or delete resources. Cannot execute actions or commands.
  </Accordion>

  <Accordion title="Billing - Financial Management" icon="credit-card">
    **Financial Management.** Specialized role for finance teams and billing administrators.

    **Typical Use Cases:**

    * Finance department
    * Procurement officers

    **Key Capabilities:**

    * Manage subscriptions, seats, and licenses
    * Purchase and manage tokens
    * Access billing metrics and dashboards

    **Restrictions:** No access to security operations (devices, integrations, etc.).
  </Accordion>
</AccordionGroup>

<Note>
  If these native roles do not meet your specific requirements, you can create **Custom Roles** with more granular permission combinations. See [Managing Access](/documentation/management/rbac/managing-access) for more information.
</Note>

***

## Combining Roles with Security Policies

Native roles define *what* a user can do. To add *when* and *where* restrictions, combine roles with [Security Policies](/documentation/management/security-policies/overview). For example:

* Restrict **Analyst** access to business hours only
* Require **MFA** for all **Admin** actions
* Limit **Viewer** access to weekdays

See [Managing Policies](/documentation/management/security-policies/managing-policies) for step-by-step instructions.