# Access Control

> **Audience:** Studio administrators, editors, and authors

ZeroPress Studio uses three fixed system roles and a deny-by-default capability
model. Each account has exactly one role. Roles are product policy rather than
site content: Studio does not provide custom roles or a capability editor.

Read [Roles & Capabilities](roles-and-capabilities/index.md) for the complete
matrix and the practical meaning of each capability.

## How access is decided

Access is evaluated in layers:

1. A valid Studio session identifies the current account and role.
2. The role grants a fixed set of capabilities.
3. The requested resource may apply a narrower ownership rule. In particular,
   an Author can work only with Posts owned by the public Author profile linked
   to that account.
4. Product state can make an otherwise permitted feature unavailable. Edge
   integration, database lifecycle, required bindings, and provider
   configuration are examples.

The browser uses the same capability policy to hide navigation and show access
guidance, but the Worker API is the security boundary. Entering a hidden URL or
sending a request directly does not bypass authorization. Unknown roles and
unknown role/capability combinations are denied.

## Access available to every signed-in account

Every active Administrator, Editor, and Author can use the capability-filtered
Dashboard, interface preferences, Account Security, session management, and
sign-out. The Dashboard returns only the domains available to that account; it
does not use a broad read permission to expose hidden totals.

## Role changes

Only an Administrator can change another account's role. A successful role
change rotates the account's authorization revision and ends its existing
sessions, so the new role takes effect through a fresh sign-in.

## Operations are a separate boundary

The [Maintenance & Recovery](../operations/maintenance-and-recovery/index.md)
surface is not an extra Administrator capability. It is controlled separately
by Worker configuration, an exact-IP allowlist, and an operations token. Some
workflows additionally re-confirm an active Administrator, but the
Administrator role alone never exposes the operations surface.