Access control
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 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 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 — assign roles, edit the capability matrix, manage members, and review the signed audit trail.
- Workspaces — invite members, choose their role, and configure break-glass access.