Roles, teams & API key permissions

Access in Traffical is decided by three things: the role each person holds in your organization, the teams that own specific parameter groups, and the scopes on each API key. The dashboard hides what you can’t do, but every check is enforced again on the server — hiding a button is a courtesy, not the security boundary.

​

Organization roles

Every member of your organization has exactly one role: Under the hood, every action maps to a permission in resource:action form (metrics:read, policies:write, …), and a role is a fixed bundle of those permissions. You don’t manage individual permissions — you assign roles, and optionally narrow write access further with teams. Roles are managed by organization admins and owners; ask one to change yours.

​

The operate tier

A small set of permissions is deliberately held back from members and granted only to admins and owners: Anyone who can operate a change can also propose one — changes:propose is always bundled with changes:operate. This is the line between building and shipping. A member can design a test end to end — parameters, allocations, goal metrics, a draft change — but formally proposing it for sign-off or moving real traffic takes an admin, an owner, or an API key that explicitly carries mgmt:operate. Where a transition needs sign-off beyond a role check, approvals layer on top.

​

Teams

Teams let you go one step finer than org-wide roles: a team can own parameter groups, and once a group is owned, only that team writes to it. Create teams on your organization’s Teams page (in the sidebar’s Organization section). A team has a name, an optional description, and a URL-safe key generated from the name that can’t change later. Creating, editing, and deleting teams — and managing who’s on them — is an admin/owner action; everyone can view teams and their membership. Each person on a team has a team role, separate from their organization role:

​

Owning parameter groups

On a project’s Parameters page, an admin can assign an owning team to a parameter group. Ownership changes who can write:

• Reads stay org-wide. Anyone whose role can read parameters still sees everything.
• Edits and deletions of parameters in an owned group — and of the group itself — require being on the owning team as owner, approver, or member. Team viewers stay read-only.
• Unowned groups behave as before — writable by anyone whose organization role allows it.
• Org admins and owners can still write to any group. That override is recorded in the activity log, so break-glass access is never silent.

API keys are not team members, so team ownership doesn’t constrain them — a key is bounded only by its scopes and its org or project scoping. A team that still owns parameter groups can’t be deleted; reassign or clear those owners first. Deleting a team removes the access its members held through it.

​

API key types and permissions

API keys are managed on your organization’s API Keys page (in the sidebar when viewing your organization, or from the account menu). Viewing and managing keys is an admin/owner action. A key’s type is its prefix, and it decides which surface the key can reach: Management and admin keys additionally carry permission slugs — the same vocabulary as the roles above. The create dialog offers a preset per type, and you can narrow it further. Two properties are worth internalizing:

• SDK keys carry no management access. Publishable and server-side SDK keys serve decisions and receive events but cannot read or change any configuration — they never reach the control plane at all. See API key types.
• A key can never exceed its creator. Permissions are intersected with those of the person who created the key, evaluated on every request — so demoting someone narrows the keys they made, with no cleanup step.
• The management preset mirrors the member role. An automation holding it can build — create metrics, edit policies, push config — but can’t start traffic. Operate permissions are granted deliberately, to automations you trust to execute transitions.

Keys are org-wide or scoped to a single project (chosen at creation), and can carry an expiry — by default they do not expire. The full key is shown exactly once when created; after that the list shows only the display prefix, type, permissions, creation date and last use. Rotating a key issues a replacement immediately and keeps the old one valid for 7 days. Revoking takes effect immediately on the control plane; SDK endpoints are served from the edge, where revocation propagates within about a minute. Revoked keys are retained for audit rather than deleted.

​

How permissions surface in the dashboard

The dashboard reads your permissions and adjusts itself: sidebar sections you can’t read are hidden, actions you can’t take — New Team, Create API Key — don’t render at all, and transition buttons render disabled with a hint naming the missing permission. A viewer sees the whole product with nothing to press. That filtering is UX, not enforcement. Every request is re-checked server-side, so a hand-crafted request without the right permission fails with a 403 no matter what the UI showed. The same is true of team ownership: the write check on an owned parameter group happens on the server, per request.

​

MCP connections

Connections to the MCP server follow the same model. Sign in with OAuth and the agent acts as you — your role’s permissions apply. Connect with an API key and the key’s scopes apply. Either way the tool list is filtered to what the token can actually do: a read-only connection sees read tools only, and proposing or executing transitions requires the operate tier — mgmt:operate on a key, or an admin or owner signed in via OAuth.

​

Next steps