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.