Roles & Permissions
How organization and project roles control what members can see and do.
Tektona access is organized in two levels: an organization contains projects, and each member's role decides what they can see and do.
Organization roles
Every member of an organization has one org role.
| Role | What you can do |
|---|---|
| Member | See the organization and its projects, and the access your project roles grant. |
| Admin | Everything a member can, plus add and remove members (at the Member role). |
| Owner | Full control: manage all members and roles, change organization settings, and delete the organization. Owners automatically have Admin access on every project. |
Only an owner can change organization settings or remove other owners, and an organization must always keep at least one owner.
Anyone with a Tektona account can create a new organization and becomes its owner. Within an organization, any Member can create a new project and becomes that project's Admin. Renaming or otherwise updating an organization requires the Owner role; updating a project requires project Admin. All of this works from the console or the CLI (see Organizations & projects).
Project roles
Within a project, each member has one project role. Owner is an organization concept. The top project role is Admin.
| What you can do | Reader | Writer | Admin |
|---|---|---|---|
| View the project, its repositories, and settings | ✅ | ✅ | ✅ |
| View (read-only) a sandbox shared with you | ✅ | ✅ | ✅ |
| Create and manage repositories | ❌ | ✅ | ✅ |
| Create sandboxes (you become the owner) | ❌ | ✅ | ✅ |
| Operate sandboxes you own or that are shared with you | ❌ | ✅ | ✅ |
| Use a project or org secret / egress proxy profile when creating a sandbox (without seeing its value) | ❌ | ✅ | ✅ |
| Manage your own personal secrets (incl. git credentials) | ❌ | ✅ | ✅ |
| Operate, delete, or expose any sandbox in the project | ❌ | ❌ | ✅ |
| Manage project secrets, egress proxy profiles & security: shared secrets/git credentials, container registries, egress network policies | ❌ | ❌ | ✅ |
| Change project settings and manage project members | ❌ | ❌ | ✅ |
| Delete the project | ❌ | ❌ | ✅ |
Organization owners appear in a project's member list as Admin, because they automatically have full access to every project.
Secrets & egress proxy profiles
Secrets and Egress Proxy Profiles exist at three scopes, and who manages them follows the scope:
| Scope | Who manages it | Who can use it |
|---|---|---|
| Organization | org Owners and Admins (in organization settings) | every project in the org (subject to its selected-projects list) |
| Project | project Admins | anyone who can create a sandbox in the project (Writer+) |
| Personal | you (Writer or Admin) | only sandboxes you own |
Managing is not the same as using. Creating a sandbox that uses a project or org secret needs only Writer. The value is injected at the network edge and never shown, so a Writer can run a sandbox with the team's Anthropic key without being able to read or change it. Only Admins/Owners (per the policy below) can create, edit, or delete the shared secrets and profiles themselves. Values are write-only everywhere: managing a secret means setting or replacing it, never reading it back.
Restricting who can manage
Managing project secrets and egress proxy profiles always requires Admin. Writers can use them but never create, edit, or delete them. Admin is a fixed floor, not something a project can lower.
What an organization can configure, in organization settings (Owner or Admin), is the governance around that:
- Who manages org secrets & egress proxy profiles. Owners only, or Owners and Admins (default).
- Allow projects to add their own secrets & egress proxy profiles. On by default. Turn it off to restrict projects to organization-provided profiles and secrets only.
- Allow personal secrets. On by default. Turn it off to require every credential to go through managed org or project secrets (for compliance). Turning this off does not delete existing personal secrets. They simply stop resolving (they are no longer injected), so a sandbox that relied on one falls back to the project or org scope, or fails closed if no shared value covers it.
Sandbox ownership
Sandboxes are not visible to everyone in a project by role alone. Each sandbox is owned by one user and private by default, so only its owner and project or org admins can see or operate it. Owners share a sandbox explicitly to let project members use it (and let readers observe it), and ownership can be transferred. Deleting or exposing a sandbox you don't own requires Admin (or owning it).
See Sharing Sandboxes for how sharing, transfer, and the admin oversight commands work.
Default project role
When someone joins your organization, they get a default role on its projects, the default project role, set by an organization owner. It can be:
- None. No access to projects unless added to one explicitly (good for keeping projects private by default).
- Reader, Writer, or Admin, the access every org member gets on projects automatically.
You can always grant an individual member a different role on a specific project, and an explicit project role overrides the default.
Outside collaborators
You can add someone to a single project without making them a member of your organization. They see only the project they were added to, with the project role you give them.