Permission Model & Role Bundles

Every action in Athena is guarded by a named permission — a stable, dotted id such as agents.delete or commands.execute. Each of Athena's four roles holds a fixed bundle of those permissions, and what an account may actually do is the bundle for its role. This page is the reference for that model: the full permission catalogue, which bundle each role gets, and how to read it all back so you can answer “why was this person allowed (or refused) that?” with a query instead of a guess.

How the model fits together#

Three pieces make up the model:

• The permission catalogue. The single list of every capability Athena guards. Each entry has a stable id (lowercase, dotted — e.g. deployments.execute), a display category, and a one-sentence description of what granting it lets someone do.
• Role bundles. Each of the four roles — User, Helpdesk, Operator, Admin — holds a fixed set of permission ids.
• Effective permissions. What a specific account ends up with, resolved from its role's bundle. This is the exact set the server checks on every request, so what a screen shows and what the server will actually allow can never disagree.

The four role bundles#

The bundles are fixed in this release — there are exactly four roles, no custom roles, and no per-resource scoping. They also nest: everything a User can do, a Helpdesk can do; everything a Helpdesk can do, an Operator can do; and Admin holds every permission in the catalogue. There is deliberately no wildcard — Admin holds each id explicitly, so a destructive capability is always separately visible rather than hidden behind a catch-all.

View vs. manage, and the delete / api.view splits#

Reading the catalogue is easier once you know the naming pattern:

• <area>.view — read the area's screens. Held from Helpdesk up (these are the reads that make up the Helpdesk bundle).
• <area>.manage / <area>.execute — the writes and actions for that area. Held from Operator up.
• <area>.delete — destructive removal that cannot be undone (e.g. agents.delete, commands.delete, collections.delete, deployments.delete). These are Admin-only and are kept separate so deleting is never bundled in with ordinary management.
• <area>.api.view — reading the same data through the REST API, which sits at a tighter tier than the equivalent console page for a few areas (agents, commands, collections, deployments, scheduler). It lets the console read stay broad while the API read stays at the Operator tier.
• Module permissions don't follow the view/manage tiers above. Their *.manage ids are Admin-only. See Module permissions.

The permission catalogue#

Every permission Athena guards, grouped by category. This is the authoritative list the authorization checks use; the descriptions are the same operator-facing sentences shown in the console and returned by the API.

Agents#

Inventory#

Remote Support#

Commands#

Deployments#

Collections#

Compliance#

Scheduler#

Reports#

Monitoring#

Alerts#

Tagging#

Audit#

Settings#

Users#

Security#

Agent Software#

Module permissions — BitLocker, Sysmon and Power Management#

The BitLocker, Sysmon and Power Management modules add their own permissions to the catalogue. Once added, they behave exactly like any other permission: they show up on Settings → Security → Permissions, in api/permissions and in Get-AthenaPermission, and the server checks them the same way. Each module's permissions are listed under the module's name as the category — BitLocker, Sysmon or Power Management — so you can filter them with ?category=BitLocker or -Category "Power Management".

The default holders differ from the core naming pattern. Admin holds every module permission. The read-only ones (bitlocker.view, sysmon.view, power.view) and the help-desk PIN reveal (bitlocker.pin.reveal) are also given to Helpdesk and Operator. The policy-editing ones (bitlocker.manage, sysmon.manage, power.manage) are also given to Operator. The rest (bitlocker.reveal, bitlocker.decrypt, sysmon.config.delete) are Admin-only. These pages live in the Policies group.

For what each permission unlocks on screen, see BitLocker Management, Sysmon Configuration Management and Power Management.

Effective permissions — what an account can really do#

An account's effective permissions are simply the bundle for its role, resolved from the same source the authorization check itself uses. That means a permissions view can never show a set the server would not honour. Every account can look up its own effective permissions — even a User-role account — from its Profile or the api/permissions/me endpoint. Looking up another account's permissions requires the users.view permission.

REST API#

The permission model is read-only over the API — you inspect it, you don't edit it (role bundles are fixed in this release). All endpoints require an authenticated session; the per-endpoint permission is noted below. See the API Reference for authentication details.

PowerShell#

The Athena module reads the same model. Connect first with Connect-Athena. The catalogue and role-bundle cmdlets require the settings.view permission; asking about your own effective permissions needs only a connected session.

A few practical one-liners, from a connected session:

# What can I do right now?
Get-AthenaEffectivePermission | Select-Object Username, RoleName, PermissionCount

# List just the agent permissions and what each one allows
Get-AthenaPermission -Category "Agents" | Format-Table Id, Description

# Can Helpdesk acknowledge an alert?
(Get-AthenaRolePermission -Role Helpdesk).PermissionIds -contains 'alerts.acknowledge'

# Exactly what would promoting someone from Helpdesk to Operator add?
$hd = (Get-AthenaRolePermission -Role Helpdesk).PermissionIds
$op = (Get-AthenaRolePermission -Role Operator).PermissionIds
Compare-Object $hd $op

# Does a specific user hold the (Admin-only) delete-agent permission?
Get-AthenaUser -Username jsmith | Get-AthenaEffectivePermission |
  ForEach-Object { $_.PermissionIds -contains 'agents.delete' }

Common questions#