> ## Documentation Index
> Fetch the complete documentation index at: https://docs.agents.labs.bandwidth.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Roles & Permissions

> Workspace access control — what Owner, Admin, Editor, and Viewer can do

Everything in Bandwidth Agent Builder is scoped to a **workspace**. When you join a workspace you are
given a **role**, and that role decides what you can do inside it — from read-only
viewing all the way up to managing billing and deleting the workspace.

Roles are **per workspace**: the same person can be an Owner of one workspace and a
Viewer of another. Your active workspace (and therefore your current permissions) is
whichever one is selected in the workspace switcher.

## The four roles

| Role       | In short                                                      |
| ---------- | ------------------------------------------------------------- |
| **Owner**  | Full control — billing, member roles, and workspace deletion. |
| **Admin**  | Manage agents, integrations, and members.                     |
| **Editor** | Build agents, tools, and knowledge bases.                     |
| **Viewer** | Read-only access to calls and dashboards.                     |

Roles are hierarchical: every Owner can do everything an Admin can, every Admin can do
everything an Editor can, and every Editor can do everything a Viewer can.

## What each role can do

| Capability                                                            | Viewer | Editor | Admin | Owner |
| --------------------------------------------------------------------- | :----: | :----: | :---: | :---: |
| View agents, calls, runs, dashboards, knowledge base                  |    ✅   |    ✅   |   ✅   |   ✅   |
| Create & edit agents, tools, knowledge bases, campaigns, folders      |    —   |    ✅   |   ✅   |   ✅   |
| Run & test — test calls, start/pause/resume campaigns, publish agents |    —   |    ✅   |   ✅   |   ✅   |
| **Delete** agents, tools, knowledge bases, folders                    |    —   |    —   |   ✅   |   ✅   |
| Configure **integrations** — telephony, webhook credentials           |    —   |    —   |   ✅   |   ✅   |
| Configure **AI connections** — LLM / TTS / STT provider keys          |    —   |    —   |   ✅   |   ✅   |
| **Members** — invite, remove, revoke invites                          |    —   |    —   |   ✅   |   ✅   |
| **Change member roles**, billing, delete the workspace                |    —   |    —   |   —   |   ✅   |

<Note>
  **Editor vs Admin, in one line:** Editors *build* (create, edit, run), Admins
  *manage* (delete, integrations, members). Deleting content and configuring
  integrations/AI connections are intentionally Admin-and-above.
</Note>

### Viewer

Read-only. Viewers can open agents, browse the knowledge base, and review calls, runs,
and dashboards — but they cannot create, edit, run, or delete anything. Buttons for
those actions are hidden, and the API rejects the request if attempted.

### Editor

Editors build the product: create and edit agents, tools, knowledge bases, campaigns,
and folders, and run/test them (test calls, starting campaigns, publishing agents).
Editors **cannot delete** content or touch integrations, AI connections, or
members.

### Admin

Everything an Editor can do, plus the "manage" surface: **delete** content, configure
**integrations** (telephony, webhook credentials) and **AI connections** (model/provider
keys), and manage **members** (invite, remove, revoke invites).

### Owner

Full control. Everything an Admin can do, plus **changing other members' roles**,
billing, and **deleting the workspace**. The first person in a workspace is its Owner,
and a workspace always keeps at least one Owner (the last Owner cannot be removed or
demoted).

## How permissions are enforced

* **Server-side first.** Every action that creates, edits, deletes, or configures is
  checked on the API against your role in the active workspace. An insufficient role
  gets `403 Forbidden` regardless of what the UI shows — this is the real guard.
* **UI reflects your role.** Controls you can't use (create, delete, integration
  settings, member management) are hidden or disabled so you don't hit dead ends.
* **Reads are open to all members.** Any role can view the data in workspaces they
  belong to.

Labs Auth proves user identity; Bandwidth Agent Builder still applies the active workspace membership and
role to every authenticated request.

## Managing roles & access

* **Assigning a role** happens when you invite someone. From **Team members → Invite
  members**, pick the workspace(s) to grant access to and choose a role for each — one
  invite link can grant access to several workspaces, with a different role in each.
* **Changing a role** later is done by an Owner from the **Team members** page.
* **Inviting** is available to Admins and Owners, and you can only invite people to
  workspaces where you are an Admin or Owner.

See [Workflows & Agents](/core-concepts/workflows-and-agents) for what you build inside a
workspace, and [Campaigns](/core-concepts/campaigns) for running agents at scale.

## Additional Labs access

Phone-call controls and campaigns also require the Labs `super_user` role. Workspace roles still apply: an Editor or higher can initiate calls, while changing telephony configuration requires Admin or Owner access.

Labs API keys act as their owner and retain that user's workspace permissions. They cannot use bearer-only call or campaign endpoints. Manage keys through the Labs platform.