Permissions

A scoped credential lets a script or AI agent use less authority than your dashboard session. Tokay checks both the identity's memberships and the credential's action grants on every request.

Last updated August 14, 2026

AI agent? Start with llms.txt.

Workspace membership establishes the outer boundary

Workspace roles are Owner, Admin, and Member.

• Owner and Admin can operate the full Workspace, including its Projects and code.
• Member has no Project or repository access until those grants are added.

Every Workspace has an Owner. Ownership is transferred deliberately rather than through a normal invitation.

Project roles control application operations

Project roles are Admin, Member, and Viewer.

• Admin operates the Project and manages its membership.
• Member deploys and configures its Services.
• Viewer sees status and safe identifying information without making changes.

A person who operates a Project can view the source used by its Services because the code is part of understanding and diagnosing the application. Project Viewers see status rather than source.

Project Config follows source visibility because it is code stored outside the repository. Project Admins and Members can inspect Config when their credential can read source or write Config. Project Viewers and credentials limited to status or logs cannot read Config values. Secrets remain unreadable even when a person is allowed to set them.

Repository roles control the code

Repository roles are Read, Write, and Admin.

• Read can view and clone.
• Write can change the code.
• Admin can also manage repository access and lifecycle.

Repository permission is separate from Project permission because one repository can supply Services to several Projects.

Credential grants narrow Platform authority

Dashboard sessions use the full membership authority of the Person who signed in. API, MCP, Git HTTPS, and SSH credentials always carry an explicit list of action grants. API and MCP credentials also have separate destinations and cannot be exchanged.

A credential never adds membership. Removing Project access or Workspace membership narrows every related credential on the next request. Git credentials work only for repository operations. See SSH keys and git tokens.

For API and MCP credentials, REPO_READ includes Project Config because the same value could have been committed as source. PROJECT_WRITE also permits reading and changing Config. PROJECT_WRITE_SECRETS permits setting Secrets without revealing them. A Git credential can cover all accessible repositories or be pinned to one Workspace or repository, but it never grants Config access through the API.

Credential creation is separately granted through CREDENTIAL_CREATE_API, CREDENTIAL_CREATE_MCP, and CREDENTIAL_CREATE_GIT. The Git grant covers HTTPS and SSH because both provide the same repository authority. A credential created by another bearer must be narrower and cannot create another credential. People and Bots can use either Git encoding. Git credentials may have an access expiry, and linked credentials are revoked with the root that created them. Use a Bot with narrower memberships when automation needs a smaller resource boundary than the Person operating it. See Agent identity and credentials for exact lifetimes, delegation rules, and rotation behavior.

App visitors use a different access model

Workspace, Project, and repository permissions are for People and Bots that manage Tokay. People who use your deployed apps are Visitors. Programs that call those apps use Machines scoped to one Project with independently rotatable credentials.

See Who can open your app and Machines and credentials. A Machine credential can open an app but cannot manage Tokay.