Docs · Getting started

Authentication

API keys for machines, sessions for people, and why they never cross.

Two credentials, deliberately separate

	API key	Console session
Who holds it	Your backend	A person's browser
Scope	One project	The projects they are a member of
Sent as	`authorization: Bearer bk_…`	An HttpOnly cookie plus a CSRF token
Can it approve?	No	Only with the APPROVER role and a passkey
Can it authorize an agent?	Yes	No

A key cannot sign a person in, and a session cannot authorize an agent. The separation is the point: one is a machine's standing credential, the other is evidence a human is present.

Getting a key

Console → API Keys → name it → Create key. The secret is shown once. Store it where your backend reads secrets; never in a browser bundle, a repository or a client component.

AVAILABLE Create, list and revoke API keys — /projects/:id/api-keys

Where: API Keys

Requires: ADMIN

Using it

curl -sX POST https://gateway.example.com/v1/authorize \
  -H "authorization: Bearer $BENGAR_API_KEY" \
  -H "content-type: application/json" \
  -d '{ "agent": "did:key:…", "permit": "…", "action": "purchase",
        "resource": "resource://company/procurement/laptop" }'

@bengar/sdk is server-only. It holds a tenant API key: importing it into a browser bundle ships that key to every visitor.

Revoking

Revocation is immediate and one-way. A revoked key stops being authorized on the next request, not at the end of a cache window.