RBAC

Administration of Agent Stream itself, including its dashboard and management API, 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:

Any feature not listed in the map below is denied by default to Power User and User accounts: access has to be explicitly granted, nothing is allowed just because it’s missing from the list. Administrator is the exception: as noted above, it passes every check regardless of the map.

How the permission map is loaded

The permission map that decides which role a feature requires is a fixed set of hardened defaults. It is not configurable by you; every feature keeps its default requirement unless Affinidi has overridden it for your appliance.

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

Teams & members

Secrets & credentials

Surfaces, prompts & policies

The canvas-builder row and the “outside the canvas builder” row aren’t a contradiction: day-to-day surface building stays open to every account, while a narrower, administrator-only set of actions covers what falls outside the regular canvas flow (see the note below).

Trust Fabric

Observability & governance

Departments, notifications, payments & appliance operations

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 surfaces stays open to every account (view/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.
• Connection points and mediators are the two areas where Power User gets write access beyond the base User role; everything else write-level stays Administrator-only.

Related

• Security and access control: the conceptual grounding for this role ladder.
• Secrets and API keys: the two credential stores that Administrator-only access protects.
• Teams and attribution: what attributed-metrics access unlocks.
• Governance records: restricted to Administrator accounts.
• Source authentication and OPA policies: what actually governs a surface’s runtime behaviour, separate from this administrative role ladder.