Skip to main content

​
Access control

An agent’s Access section in the workbench determines which users can open the agent in Chat. The RBAC control presents four mutually exclusive sharing modes.

​
Sharing modes

Team-scoped sharing (“Teams” mode) is available when your deployment has the RBAC teams feature enabled. Until that flag is active, the mode list shows only Private, Users, Roles, and Public.

​
Changing access

1

Open the Access section

In the workbench, scroll to or click Access in the section navigation.
2

Select a mode

Choose Private, Users, Roles, or Public.
3

Add users or roles

If you chose Users, search and add each user. If you chose Roles, pick one or more roles. Public and Private require no further selection.
4

Save

Click Save in the workbench header. The new sharing rules take effect immediately.

​
How access interacts with admin settings

Administrators can also apply organization-wide defaults and override access controls from the Administration area. An agent set to Public still respects any global budget or model restrictions the administrator has configured.

​
Guest publishing

Internal sharing modes cover authenticated IMP users. To expose an agent to visitors outside your organization — without requiring an IMP account — enable Guest access in the workbench. When guest access is on, the agent is reachable at a public URL (/public/agents/{id}). Three authentication modes are available: Public (no credentials required), Password (shared password gate), and Login (external email self-registration with persistent sessions).
Guest access supersedes the legacy rights_mode=public field. If an agent has both guest access enabled and the legacy public flag, the guest-access gate — with its chosen authentication mode and abuse limits — applies, and the old anonymous path is bypassed. Agents that have never had guest access set keep their previous behavior unchanged.
For the full configuration guide, see Guest access.

​
Knowledge base write access

When the Knowledge base editor tool is enabled, an agent can create and update knowledge context items during chat. The following safety model applies:
  • Explicit per-context opt-in — only contexts checked in the tool’s configuration sheet, with at least one of Create or Update enabled, are writable. All other contexts are read-only regardless of the agent’s knowledge settings.
  • Dual gate — a write attempt must pass both the agent-level configuration (is the context opted in?) and a row-level write check (does the active user have write access to that specific item?). Either gate failing blocks the write.
  • Guest refusal — write tools require an authenticated user session. Requests from anonymous guest sessions are refused before any database call is made.
  • Schema exclusions — the following are never included in the tool schema: file and uuid fields, calculated fields, fields marked editable: false, hidden fields, and reserved internal parameter names. This limits what the model can write to well-defined, safe columns.

​
Next steps

Back to workbench

Review all nine workbench sections.

Knowledge overview

Connect knowledge contexts to this agent.