RBAC in Agent Ops

Open in product: preshos.com/agent-ops/rbac

RBAC in Agent Ops answers three questions: who may use which agent, which actions those runs may take, and who may open the resulting sessions. Membership decides the who; configuration decides the what; the session record proves it happened that way.

The three gates

• Who can use which agent. Agent availability per org lives under Org agents; member roles that grant or withhold access live under Roles and People. An agent the org may use is still only as capable as the session environment allows.
• Which actions a run may take. The environment policy draws this line: context the run sees, tools it may call, and what pauses for approval. Overrides happen in configuration, never in chat.
• Who can access sessions. Session records belong to their tenant and org scope. Opening, continuing, or reviewing someone else’s session follows the same role rules as the work itself.

Admin checklist

• Smallest sufficient role at invite time; membership reviewed regularly. The hygiene behind this gate is Security.
• Agents enabled per org deliberately: each enabled agent names its owner and its environments. Ownerless or environment-less agents get removed, not adopted.
• Denials exist in the record. A run of sessions with zero denials means rubber-stamping — investigate the policy, not the members.

What next

• Roles: what each role may do.
• People: the membership list roles attach to.
• Org agents: which agents run for the org.
• Superuser: platform-admin-only (org 1, platform ops role); no bypass inside normal Agent Ops.