Skip to main content
AtlaSent supports two authentication methods. Both are fail-closed — no anonymous access.

​
JWT Bearer (user sessions)

Issued by Supabase Auth. Include on every request:
The JWT is validated server-side on every request. Permissions derive from the caller’s org role:

​
API Key (service / agent auth)

Create in Console → Settings → API Keys. Include on every request using the Authorization: Bearer header:
API keys are stored server-side as SHA-256 hashes. The plaintext is never persisted; a lost key cannot be recovered — it must be rotated.
The X-AtlaSent-Key header is deprecated and will be removed in a future version. Migrate all service integrations to Authorization: Bearer <api_key>.

​
Scopes

API keys get a scope set at creation time. Scopes use the resource:action form — bare names such as evaluate, audit, or admin are not valid scopes and cannot be assigned to a key.
Give each service the narrowest scope it needs. A runtime agent typically needs only evaluate:write and verify:execute. Create separate keys for evaluation vs. audit export, so a compromise is contained.

​
Rotating keys

To rotate an API key without service interruption:
1

Create a new key

In Console → Settings → API Keys, create a new key with the same scopes as the key you are rotating.
2

Deploy the new key

Update the secret your deployment reads (for example ATLASENT_API_KEY) to the new key and redeploy or restart the service.
3

Revoke the old key

Once the new key is confirmed working, revoke the old key in the Console.
Store API keys in a secrets manager rather than in environment files or source control.

​
Fail-closed

If credentials are absent, invalid, or expired, every endpoint returns 401. A valid credential that lacks the scope or role an endpoint requires returns 403, and the action does not proceed. Audit writes are atomic with evaluation — if the audit write fails, the evaluation fails.