Authentication

Arbiter uses long-lived API keys for programmatic access. The wire prefix is arb_. The same key works against the REST API and the MCP server.

Who can read or act, and how dashboard / REST / MCP share RBAC: Access Model.

Key format

arb_<43 url-safe-base64 characters>

Always starts with arb_.
48 characters total. 256 bits of entropy.
Stored server-side only as a SHA-256 hash. The raw value is returned exactly once at creation.

The first 8 characters (e.g. arb_aB3) are stored unhashed as a key prefix for UI and audit display. The prefix alone cannot authenticate.

Lifecycle

mint  →  store securely  →  use on every request  →  rotate or revoke

Action	Where
Mint	Settings or `POST /api/api-keys`
List	`GET /api/api-keys`
Revoke	`DELETE /api/api-keys/{id}`

Keys are scoped to the user × org pair that minted them. Removing the user from the org invalidates those keys on next use.

Mint request

POST /api/api-keys
Authorization: Bearer arb_…
Content-Type: application/json

{ "label": "ci-pipeline" }

Response — 201 (raw secret appears only here)

{
  "id": "EpJ…",
  "rawKey": "arb_aB3xYz…",
  "label": "ci-pipeline",
  "keyPrefix": "arb_aB3",
  "createdAt": "2026-05-19T14:02:17.421Z"
}

Sending the key

Authorization: Bearer arb_…

Bearer prefix required; case-insensitive.
Do not put the key in query parameters.
TLS is mandatory.

curl -H "Authorization: Bearer $ARBITER_API_KEY" \
  https://arbiter.blockskunk.com/api/risks

curl -H "Authorization: Bearer $ARBITER_API_KEY" \
  "https://arbiter.blockskunk.com/api/v1/assets?limit=50"

Mint partner machine keys under a read-only RBAC role when using Partner Read.

Permission model

The key inherits the user's current RBAC permissions, resolved at request time:

Permissions recomputed per request (short role-set cache).
Role removal applies on subsequent calls — no client refresh.
Row-level filters apply identically to UI and API traffic.

There is no separate per-key scope beyond the user's permissions. Broader actor boundaries (operators, external reviewers, partners): Access Model.

Common errors

Status	Meaning
`401`	Missing, malformed, revoked, or org-detached key
`403`	Valid key; RBAC lacks permission on the resource
`429`	Rate limit — honor `Retry-After`

Security checklist

Store keys in a secret manager. Never commit them.
One key per workload.
Rotate on a schedule; revoke immediately on leak.
Least-privilege RBAC for the minting user.

Open the API reference