Documentation · Access control
Roles and capabilities
Warden uses named roles made from explicit capabilities. Administrator is an assignable role, so an instance can have multiple administrators without one permanently special account.
Checkbox-managed permissions
System → Access shows accounts, their assigned roles and the capabilities contained in each role. Administrators can edit the normal User role or assign several roles to one account. The built-in Administrator role always retains every capability.
Capabilities are intentionally functional rather than page-shaped: file reading, file writes, workspace replacement, Git mutation, terminal access, system administration, Warden settings, audit visibility and account management are separate decisions. Audit access is represented by its own audit.read capability. AI access is split into ai.use for using providers, ai.credentials for supplying personal credentials, and ai.manage for shared instance provider settings. This lets an organization force users onto company credentials without disabling AI access.
Frontend and backend enforcement
Warden disables or removes unavailable controls in the browser for a clear UX, but the browser is never the security boundary. Every protected API route checks the authenticated account's effective capabilities and returns 403 Forbidden when the permission is absent.
Read-only combinations are first-class: for example, system.read without system.manage keeps system inspection available while mutation buttons/forms are disabled; source.read without source.write keeps Git status available while stage/commit controls are disabled.
Live authority
Capabilities are resolved from current server-side account and role state on every HTTP request, not copied permanently into the session. Removing a role capability therefore affects already-issued sessions immediately. Account-owned identifiers such as sessions, conversations and terminal metadata remain scoped by account in addition to capability checks.
Terminal authority warning
An account with terminal access receives the operating-system authority of the user running that Warden instance. File/workspace capabilities do not sandbox commands typed into the PTY.
Multiple identities
Accounts can have additional password logins and email identities. This supports several people deliberately sharing one Warden account while still keeping separate login identities for audit trails. Google identities attach to the same account model instead of making email addresses the account key.
Local administrator recovery
Warden always retains at least one enabled Administrator with an enabled password login. Other administrators may rely on linked Google identities, but the final local administrator password cannot be removed or disabled. This keeps optional external authentication from becoming the only recovery path for the instance.