Roles, teams & API key scopes

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 an experiment 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 scopes

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. Each key’s capabilities come from its scopes: The create dialog offers these as presets — SDK Key (sdk:read + sdk:write), Management Key (mgmt:read + mgmt:write), Lifecycle Operate Key (management plus mgmt:operate), and Full Access (admin). Two properties are worth internalizing:

• SDK keys carry no management access. A key with only sdk:read/sdk:write can serve decisions and ingest events but can’t read or change any configuration — that’s why SDK keys are safe to ship in client code. See API key types.
• mgmt:write mirrors the member role. An automation holding it can build — create metrics, edit policies, push config — but can’t start traffic. Grant mgmt:operate only 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. The full key is shown exactly once when created; after that the list shows only the prefix, scopes, creation date, and last use. Deleting a key revokes it immediately.

​

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