Permissions and security boundaries

Operade combines workspace roles, request authentication, application checks, and database tenant isolation. These controls define tested product behavior. They are not a compliance certification or an SLA, and this page does not claim an audit, regulatory status, retention guarantee, or uptime commitment.

Role and operation boundaries#

The three workspace roles are owner, admin, and member. Owners control role transfer and can administer other owners. Admins operate most workspace settings but cannot grant or remove elevated roles. Members use ordinary product capabilities and can read workspace Conversations, but cannot manage API keys, Secrets, Usage, channels, deployments, or post-call webhook settings where an elevated role is required.

Every HTTP operation declares a minimum access level and whether API-key authentication is allowed. Dashboard-only mutations require a live human session. An API key is bound to one workspace and cannot create another API key or use session-only operations merely because its creator was an owner. On routes that do allow it, however, the key is authorized at workspace-admin scope and can access every resource exposed by that operation inside its Workspace, including another member's private resource. Per-key roles and per-resource allowlists are not currently available.

Cross-workspace requests deliberately return not found in many paths instead of confirming that another tenant's object exists. For the exact role matrix, read the authentication section on each API Reference operation.

Session and request protections#

Dashboard sessions are stored as revocable server-side records. The session cookie uses HttpOnly, Secure, and SameSite=Lax attributes. Revoking a session makes the next authenticated request fail instead of waiting for a self-contained browser token to expire.

State-changing session requests require the custom CSRF request header used by the dashboard. CSRF means cross-site request forgery: a malicious site trying to submit a change through an already signed-in browser. Read endpoints do not require that mutation header. Sign-in attempts are rate-limited, and login responses avoid revealing whether an email exists.

Removing membership also takes effect on the next request because role membership is checked again; an old open page does not preserve access indefinitely.

Tenant isolation and Secret boundaries#

Tenant-owned data tables enforce PostgreSQL row-level security, usually abbreviated RLS. RLS restricts rows to the workspace context established for the database transaction, and the application database role is tested not to bypass it. Writes without the proper tenant context are rejected or return no tenant rows.

Workspace and membership control tables are reached before a tenant database context exists, so their core functions perform explicit membership checks instead of relying on RLS. Tests cover cross-workspace reads, writes, joins, deployment references, configuration validation, conversation detail, and post-call settings.

Workspace Secrets are encrypted and write-only through public interfaces. Conversation Activity redacts draft configuration, internal Guardrail details, provider bodies, and Secret values. Treat exported transcripts, Analysis results, and API responses according to your organization's own data-handling policy; the product behavior described here does not replace that policy.