---
title: Access control
description: How AKOS decides who can do what — roles map to capabilities, and sensitive actions like approving a human-in-the-loop step require a specific capability.
---

AKOS controls every significant action with role-based access control (RBAC). The model is simple: **people are assigned roles, roles grant capabilities, and each capability unlocks a specific kind of action.** Sensitive actions — approving a paused run, deciding a release gate, granting emergency access, or reading the audit log — require the matching capability, so they can only be performed by someone whose role allows it.

## Roles map to capabilities

A **role** is a named bundle of **capabilities**. A capability is a fine-grained permission, such as "approve a human-in-the-loop step" or "read the audit ledger". When you assign someone a role, they receive exactly the capabilities that role carries — nothing more.

You manage roles and the capabilities they grant in the [Governance](/docs/using-the-app/governance) screen, using the capability matrix. New members receive the workspace's default role until an administrator assigns them a specific one.

Typical roles and what they can do:

| Role | Can do |
| --- | --- |
| **Viewer** | Read workspace data; cannot approve or change governed actions. |
| **Editor** | Build and run agents, flows, and processes. |
| **Reviewer** | Approve or reject human-in-the-loop steps and release gates. |
| **Auditor** | Read the signed audit ledger. |
| **Admin** | Manage roles and members, grant break-glass access, and perform every governed action. |

Your workspace may define additional or renamed roles — the capability matrix in Governance is the source of truth for your setup.

## Sensitive actions require a capability

Some actions are gated because they carry weight: approving them resumes work, releases code, or grants access. AKOS checks the calling person's capability **before** the action runs, and denies it if they lack the matching capability. Examples:

- **Approving a human-in-the-loop step** (resuming a paused run) requires the *decide HITL* capability — typically held by **Reviewer** and **Admin**.
- **Deciding a release gate** (passing or blocking an SDLC gate) requires the gate-decide capability — typically **Reviewer** and **Admin**.
- **Requesting break-glass access** (temporary elevated access for an urgent action) requires the break-glass capability — typically **Admin** only.
- **Reading the audit ledger** requires the audit-read capability — typically **Auditor** and **Admin**.

A denied action returns a clear authorization error and is itself recorded, so attempts are visible in the [Governance](/docs/using-the-app/governance) history.

## Enforcement applies everywhere

Capability checks run at the boundary where every action is dispatched, so they apply consistently across all three surfaces — the desktop app, the managed cloud, and the CLI. A request that bypasses the web sign-in layer (for example, a direct or automated client) still passes through the same capability check, so there is no back door around the access model.

## Single-user and local-first

On a single-user, local-first install — the desktop app on your own machine, or a self-hosted sidecar without a separate identity store wired in — there is no team to govern. In that case AKOS resolves you as the **local administrator**, who holds every capability. You get the full product with no setup friction, and the same enforcement seam is still in place: the moment a real identity store is connected (for a team or the managed cloud), the role-to-capability rules take effect automatically.

## Where to go next

- [Governance](/docs/using-the-app/governance) — assign roles, edit the capability matrix, manage members, and review the signed audit trail.
- [Workspaces](/docs/using-the-app/workspaces) — invite members, choose their role, and configure break-glass access.