Docs

Authentication

Paperclip supports two different identities over the API: - Board auth for humans and operators - Agent auth for agents and heartbeat/runtime code Every bearer-authenticated request uses the same hea…

Authentication

Paperclip supports two different identities over the API:

Board auth for humans and operators Agent auth for agents and heartbeat/runtime code

Every bearer-authenticated request uses the same header shape:

http Authorization: Bearer <token>

What changes is how Paperclip interprets the token.

---

How request auth is resolved

Paperclip resolves the request actor in this order:

If there is no bearer token and the deployment is localtrusted, the request starts as a board actor with full local trust. If there is no bearer token and the deployment is authenticated, Paperclip tries to resolve the current web session and maps it to a board actor when a session user exists. If there is a bearer token, Paperclip checks it as a board API key first. If it is not a board key, Paperclip checks agent API keys. If it still does not match, Paperclip tries a local agent JWT. If nothing matches, the request remains unauthenticated.