Roles + audit log

What it is

A four-tier role model + a complete audit log of every state-changing action in the workspace.

Roles, ascending privilege:

• org_viewer: read-only. Sees everything the workspace owns; changes nothing.
• org_member: same read access + can trigger AI exploit runs, retest findings, request natural-language queries.
• org_admin: same as member + can add/remove targets, invite/remove team members, configure agents / notifications / tickets, change billing, and set per-user module access.
• org_owner: everything an admin can do, plus it’s the one role that can’t be removed by anyone else and is the billing root of trust. One per workspace.

The platform role band is only one of the layers that decide what a teammate can touch. See Module access on top of roles below.

The platform also has a superadmin tier (Umbra staff) orthogonal to org roles, used for the cross-tenant operator console.

What it produces

• An audit_log table: every privileged action recorded with actor_user_id, action, target, detail JSONB, timestamp.
• The audit log is read-only and append-only at the application layer: no UI to edit or delete entries.

Sample actions captured: target.add, target.delete, agent.task.create, agent.proxy_http.create, agent.revoke, ai_run.create, team.invite, replay_share.create, plus platform-admin actions in the cross-tenant feed.

What to use it for

• Compliance audits (SOC 2 / ISO 27001): “show me every change to access control in the last quarter”
• Incident response: “who triggered this AI run?”
• Tenancy invariants: an org_member’s actions are bounded by the role; an org_admin’s are logged for the org_owner to review

Why it matters

The audit log is the difference between “we have RBAC” and “we can answer the auditor’s question.” A security tool that doesn’t log its own privileged actions can’t be the system of record for its customer’s security operations.

Why it’s valuable

• Four-role ladder, low homework. The viewer / member / admin / owner band covers most team shapes out of the box; when you need finer control, per-user module access (below) narrows what a teammate can touch without hand-building a full custom-permission matrix.
• Audit log is the source of truth. Every privileged action, with actor + scope, in one queryable table.
• Same audit table for agent + cloud actions. Agent enrollment / revoke / proxy_http relays land in the same log as user-driven actions.

Module access on top of roles

Roles set the band of what someone can do; per-user module access narrows which modules they do it in. An org_admin can restrict a teammate to specific modules (e.g. “this contractor only sees Deep Audit”) and the restriction is server-enforced, not a UI hint.

Effective access is the intersection of three layers, evaluated on every request:

1. Role band: viewer / member / admin / owner (above).
2. Per-org bundle entitlement: the module bundle your plan sells, with optional super-admin per-org overrides.
3. Per-user module grants: allow-by-default; an org_admin denies specific modules for a specific teammate.

A request succeeds only when all three layers permit it. It fails closed. Full detail: Module access & entitlements.

How to use it

• Settings → Team to invite + role-set.
• Settings → Activity for the workspace audit log.
• Platform admins (Umbra staff): cross-tenant feed at /api/admin/audit (super-admin only).