Permissions and approvals

RBAC roles

Workspace access is gated by three role tiers. The roles are checked at every dashboard and API entry; cross-tenant requests are refused at the gateway, not at the route.

• Owner — billing, plan changes, and all admin powers; one per workspace.
• Admin — install agents, authorize connectors, manage members, edit approval policies, view audit logs.
• Member — run installed agents, request approvals, read their own runs. Cannot install or revoke connectors.
• Viewer — read-only access to runs, dashboards, and audit logs.

Per-action approval policies

Every external write, send, delete, or charge is gated by a per-tool policy declared on the agent. The choices are auto for low-risk reads, approve for normal writes and sends, and approve-dual for irreversible or high-spend actions. The policy is set per tool, not globally; an email-sender tool can be approve while a search tool stays auto.

Hash-pinned previews

When the agent decides to call a gated tool, the dispatcher canonicalizes the payload and hashes it with SHA-256 before queuing the approval. The approver sees the exact text, structured fields, and recipients — not a summary. At execution time, the dispatcher rehashes the payload and refuses the call if the hash drifts. There is no path to execute an action whose preview the approver did not see.

Fail-closed enforcement

If the policy says approval is required and a fresh, hash-matched, approved row is not present and consumable, the call is refused. There is no default-open mode; if the approval store is misconfigured, the dispatcher refuses every gated call rather than letting them through.

• Approvals expire after a configurable TTL (default 30 minutes).
• One-shot consumption — each approved row drives exactly one execution.
• Per-tenant scope — approvals from one workspace are unreachable from another.
• Dual-approval requires two distinct humans; the requester counts as neither.

Decision events

Every request, decision, expiration, and consumption lands in the audit log with the actor, the resource, the hash, and the outcome. An example event payload looks like:

{
  "event_type": "approval.granted",
  "tenant_id": "org_123",
  "data": {
    "approval_id": "apv_01HZ...",
    "tool": "email.send",
    "payload_sha256": "a1b2c3...",
    "approver_user_id": "usr_456",
    "policy": "approve",
    "expires_at": "2026-05-20T19:30:00Z"
  }
}

See /docs/audit-logs for the chain model and /docs/webhooks for delivery semantics.

Kill switches

Each workspace exposes per-organization and per-tool kill switches. Flipping one freezes every gated call to the affected tool until an admin lifts the switch — useful when an incident lands and you need to stop the bleed without redeploying.