Access Model

Arbiter does not invent a separate permission system per surface — dashboard, REST, and MCP evaluate the same org membership and role checks.

Same RBAC everywhere

Surface	How identity is established	Authorization
Dashboard	Signed-in session	Org role + resource scope
REST	Authorization: Bearer arb_…	Key inherits minting user’s permissions
MCP	Same API key as REST	Same RBAC as the key’s user

If a user cannot see a risk in the UI, a key minted for that user cannot list it via REST or MCP either.

API keys

• Mint under Settings (or POST /api/api-keys with a bootstrap session).
• Wire format: arb_ prefix.
• Keys are scoped to the org and inherit the minting user’s effective permissions.
• Rotate and revoke from Settings; treat keys like passwords.

Details: Authentication.

External reviewers

Scoped external reviewers (assessors) get read-only access in-product for the engagement — not a separate portal SKU and not write access to your register. Full coordination guide: Assessor access.

Role intent	What they can do
Org operator	Create, update, export, mint keys per role
External reviewer	Read scoped records and packages for the engagement
Partner consumer	Read Partner Read envelopes / webhooks — no write to your tenant

Partner read

Partner Read and partner webhooks expose metadata-oriented payloads suitable for downstream systems. They are not a substitute for dashboard RBAC and do not grant write into your org.

See Records for envelope fields and Webhooks for event delivery. Surface maturity: Integration Surfaces.