Access Control

Studio checks identity, role, resource ownership, and service state before allowing an action. The Worker API enforces these checks; hidden navigation alone does not protect a resource.

Find a Policy

Topic	Documentation
Password acceptance, mandatory MFA, and attempt limits	Authentication
Authenticator timing and one-use codes	TOTP Verification
Passwordless sign-in, hostname scope, and credential names	Passkeys
Five-session limit, expiry, and revocation	Sessions
Fixed roles and content ownership	Roles & Capabilities
Lost factors or administrator access	MFA Recovery
An additional Cloudflare identity gate	Cloudflare Access
Major actions and retained connection information	Audit Log

Authorization Layers

1. A valid session identifies an active account and its authentication revision.
2. Its fixed role grants the required capability.
3. Resource ownership can narrow that permission. An Author can manage only Posts belonging to the public Author linked to that account.
4. Database state, bindings, and integration settings determine whether the service can perform the action.
5. Mutations verify origin, CSRF proof, and any required reauthentication.

Unknown roles and unsupported capabilities are denied. An Administrator has all Studio capabilities but does not bypass lifecycle or infrastructure checks. Every active role can use its capability-filtered Dashboard, account security, session management, and interface preferences.

Operations Is a Separate Boundary

Maintenance & Recovery requires its own exact-IP allowlist and Operations token. In operational mode, an active Studio administrator session is also required. Maintenance and recovery have explicit workflows for cases where normal authentication is unavailable.

Cloudflare Access may restrict entry before either boundary. Requiring Access inside Studio adds verified assertion checks; it does not grant a Studio role or an Operations token.