AethosHub
PricingRequest Demo

DocumentationAgent Access Manager

Roles & permissions

Roles & permissions

What a signed-in person can do is decided by their org role. Roles are strictly nested — each higher role includes everything below it — and grant capabilities. The dashboard hides or disables what your capabilities do not cover, but the server is always the real gate: hiding a button is a convenience, not the security boundary.

The capability matrix

CapabilityGuestUserOperatorAdminOwnerWhat it unlocks
VIEW✓✓✓✓✓Read the dashboards
ISSUE_KEYS✓✓✓✓Issue and manage virtual keys in your scope
VIEW_BUDGETS✓✓✓✓See budgets and spend
MANAGE_GATEWAY✓✓✓Guardrails, rate limits, SOAR rules, notifications
MANAGE_DEPLOYMENTS✓✓✓Catalog deployments (model aliases, pricing)
MANAGE_TEAMS✓✓✓Create and manage teams
MANAGE_MEMBERS✓✓✓Invite and manage users and guests
VIEW_SECURITY✓✓✓SIEM, UEBA, SOAR, sign-in activity
VIEW_REPORTS✓✓✓View reports
MANAGE_REPORTS✓✓✓Author, schedule, and run reports
MANAGE_PROVIDERS✓✓Catalog providers and master vendor credentials
MANAGE_BUDGETS✓✓Set budgets and cost caps (the money domain)
MANAGE_ORG✓Org settings, archive, manage admins

The deliberate splits

A few boundaries in that table are intentional and worth understanding before you assign roles:

  • The operator owns the rules of engagement, not the money. An operator configures guardrails, rate limits, routing (deployments), and SOAR — but cannot set budgets. Budget authority is MANAGE_BUDGETS, admin and owner only.
  • The catalog is split by sensitivity. Connecting a vendor and storing its master key is MANAGE_PROVIDERS (admin-grade, because it holds a credential). Defining a model alias and its pricing is MANAGE_DEPLOYMENTS (operator and up, because routing is the operator's job). Everyone can read the catalog.
  • The team lead is a delegated grant outside the role table. A lead can curate their team's roster and set a project budget inside their team without being an org admin. They cannot raise their own team's cap.
  • Anti-escalation. You can only assign or manage roles strictly below your own. An unknown stored role fails closed to GUEST.

Platform admin

Above all org roles sits the platform admin — the operator of the appliance itself. This is the break-glass admin Basic login, or an SSO user holding the realm role admin at your IdP. The platform admin can act in any org (choosing one per screen or per request via orgId), reviews the global SOAR actions feed, and is the only principal that can create orgs on behalf of others or hard-delete empty scopes.

How roles are assigned

  • Dashboard: Operate ▸ Organizations ▸ Members — change a member's role to any role below your own.
  • Invitations carry a role: when you invite someone by email, you pick their role at or below yours.
  • SSO: identity lives at your IdP; org role lives in Agent Access Manager. The exception is the platform-admin realm role, which is mapped from the IdP token (see Enterprise SSO).