Access control
Who can see and change what, how access is enforced, and what the audit log records.
| Grant | Reaches |
|---|---|
| Workspace membership | Everything in a workspace. |
| Per-agent share | One agent only. |
Workspace membership
Members of a workspace can read and edit its agents. Membership carries a role that governs what the application permits (inviting members, managing billing, changing workspace settings, creating webhooks).
Roles narrow writes, not reads
Owner, admin, editor and member can change agents. A viewer can only read them. A few reads are role-restricted too -- only owners and admins can read the audit log.
Every workspace member sees every agent the workspace owns, regardless of role. A role is not a mechanism for hiding agents; use per-agent collaborators for that.
Actions restricted to administrators
These require admin because they create a route for data to leave the workspace:
- Creating and deleting webhook endpoints.
- Creating workspace integrations (stored credentials and a base address).
- Creating, publishing and deleting automations (their actions can send email, messages and requests).
Per-agent collaborators
A collaborator has access to a single agent, not the workspace. Two levels exist:
| Level | Permitted |
|---|---|
| View | Read the agent's settings, calls and results. |
| Edit | The above, plus changing settings. |
What edit access cannot reach
An edit-level collaborator cannot change lifecycle or public exposure (share link, slug). Edit access cannot be escalated into publishing or opening an agent to the public.
A share does not reach an archived or deleted agent. A workspace member still sees an archived agent and can restore it.
How enforcement works
Access is enforced identically on every path. The editor, the in-app assistant, the MCP server and direct API calls all answer to the same check -- is the user a workspace member, or does an explicit share grant them access? See Security.
Settings that can change after publication are checked at save time, at publish time, and again at call time.
Publishable keys
A publishable key authenticates the website chat and voice widgets. It is scoped to one agent, carries an origin allowlist, and has separate switches for chat and voice (voice is off by default). The raw key is shown once at creation; only its prefix is displayed afterwards, and the stored form is a hash.
The origin allowlist
Because a publishable key is embedded in a public web page, the origin allowlist is the meaningful control.
Allowed origins https://example.com
https://shop.example.com
Request from https://someone-elses-site.example refusedRequests from unlisted origins are refused before any billable work runs. Keep the allowlist tight, and use a separate key for staging and local work.
The MCP server
The MCP server authenticates through a browser authorisation flow with proof key exchange and dynamic client registration. The resulting token maps to a real user session, so every operation runs with exactly that user's permissions. Access cannot exceed what the user could do in the application.
Scopes provide a coarse filter above that (read, write, delete, workspace admin). Destructive operations require an explicit confirmation argument.
Audit log
The audit log records who did what and when. Recorded events:
- API key creation and revocation.
- Member addition, invitation, removal, role change and ownership transfer.
- Workspace rename.
- Workspace integration and connector changes.
- Phone number changes.
- Campaign creation and launch.
- Discovery start and stop.
- Billing changes.
- Changes to retention and personal information policy.
Agent settings changed through the MCP server are recorded under the name of
the operation performed, for example agent.publish_version.
Entries cannot be altered
The log is append-only. Timestamps come from the platform clock, not the writer. Reads are restricted to owners and admins, and the log can be exported.
MCP-originated changes are recorded separately -- one entry per successful agent settings change. Reads and failed operations are not recorded.
Account and workspace removal
Deleting a workspace begins a seven-day recovery window. After it, teardown releases telephone numbers, removes the billing record, and cascades deletion to everything the workspace owned.
Account deletion runs on a seven-day operational SLA. Completion is recorded in the audit log, and that record survives the deletion it describes.