RBAC

Field reference for role-based access control, the role ladder and the full default permission map enforced across the dashboard.

Administration of Agent Stream itself, through its dashboard, is governed by role-based access control (RBAC): an ordered role ladder checked against a per-feature permission map. This page documents the three roles and the concrete default permission list enforced on every appliance. For the conceptual model, see Security and access control.

The role ladder controls who can see and change credentials, policies, and RBAC itself. What a given surface can do at runtime is separate, governed instead by source authentication and OPA policies.

  • Administrator covers anyone who needs to manage credentials, policies, or RBAC itself.
  • Power User suits people who manage connections and mediators day to day but have no business touching secrets or other admin-only views.
  • User is the default for a new account: assign it to anyone who just needs to build and run surfaces.

Role ladder

The role ladder has three values, each a superset of the one below it:

RoleGrants
AdministratorEvery permission in the map: secrets, user accounts, backup and restore, and administrator-only views such as governance records, drift, and attributed metrics. An Administrator account meets the minimum role of every permission the map lists.
Power UserEverything a User can do, plus creating, editing, and deleting mediators and connection points. Secrets, API keys, certificates, RBAC, and other admin-only views stay with Administrator.
UserThe default role for a new account. View-only across most feature families, with surfaces and notifications also open at this base role.

Any capability that isn’t in the permission map is denied to every role, including Administrator.

How permissions are checked

The permission map that decides which role a feature requires is a fixed set of defaults. Each feature has one minimum required role. When an account tries to use a feature, its role is checked against that requirement, and access is granted whenever the account’s role meets or exceeds it.

Default permission map

Each row below is one capability; each column shows the actions that role has for it, cumulative with everything to its left ("—" means no access at that role). Scan a column to see everything a role can do, or a row to compare roles on one capability.

Dashboard, settings & users

CapabilityUserPower UserAdministrator
DashboardViewViewView
Activity logsViewViewView
Appliance Settings——View, change
Dashboard user accounts (Settings → Users tab)——View, edit, approve, delete
Enrolment (member auto-provisioning) settings——View, change

Teams & members

CapabilityUserPower UserAdministrator
Teams——View, create/edit, delete
Members——View, create/edit, delete

Secrets & credentials

CapabilityUserPower UserAdministrator
JWT verification strategies——View, create/edit, delete
OAuth Identifier profiles——View, create/edit, delete
Secrets (Secrets page)——View, create/edit, delete
Managed API keys——View, create/rotate/edit, delete
Personal access tokens (PATs)——View, create/edit, delete
Certificates——View, upload/edit
Delegation Vault identity——Edit
Credential providers——View, create/edit, delete
Delegation Vault entries——View, delete

Surfaces, prompts & policies

CapabilityUserPower UserAdministrator
Prompt templatesViewViewView, create/edit, delete
LLM and IDE Surfaces, on the canvas builderView, build/edit, delete, run (incl. Sandbox)Same as UserSame as User
Surface price overrides. No form control. An Administrator can set them in the surface’s Config JSON view.——Edit
Model catalogue changes——Edit
Terms and conditions (Settings → T&C Manager)——View, publish, deactivate
OPA policy definitions——View, create/edit, delete, enforce globally

Creating, editing, and running LLM and IDE Surfaces is open to every account by default (see the note below).

Trust Fabric

CapabilityUserPower UserAdministrator
GatewaysViewViewView, create/edit, delete
MediatorsViewView, create/edit, deleteSame as Power User
Connection pointsViewView, create/edit, deleteSame as Power User
Integrations (Slack, email, webhook, etc.)ViewViewView, create/edit, delete
Marketplace purchases (the Marketplace tab on a gateway’s edit page)——Purchase

Observability & governance

CapabilityUserPower UserAdministrator
Aggregate and per-surface metricsViewViewView
Per-member and per-team attributed metrics——View
Audit log——View
Governance records——View
LLM drift data and baselines——View, manage

Notifications & appliance operations

CapabilityUserPower UserAdministrator
Notifications (the bell icon in the header)View, create/edit, deleteSame as UserSame as User
Appliance storage (Backup, Restore)——Administer

Notes on specific entries

  • Aggregate metrics vs. attributed metrics: a User can already see aggregate and per-surface figures. Seeing a breakdown by individual member or team needs Administrator-only access. That access is coarse: whoever holds it can view every team’s data, not just their own.
  • Governance records and drift data default to administrator-only because governance records carry raw prompts and completions, and drift series can expose a surface’s refusal or safety-rate behaviour.
  • Building and running LLM and IDE Surfaces stays open to every account (view, create/edit, delete, run) since a surface is the one thing every authenticated caller needs to work with day to day.
  • Anyone can view integrations, but only an Administrator can create, edit, or delete one, since an installed integration is a platform-wide webhook that can observe every user’s PII. Integrations in the Governance Audit category are visible only to accounts with audit-log access, Administrator by default.
  • Connection points and mediators are the two areas where Power User gets write access beyond the base User role. Other write access beyond the User role stays with Administrator.