Signing in and tokens
How your team signs in to Bounc, and what everything else authenticates with: personal, daemon, and task tokens.
Your team signs in to Bounc by email; everything else authenticates with a token. Both halves are below: how signing in works, and what the CLI, scripts, the REST API, daemons, and running agents use.
Signing in
There are no passwords. You enter an email address, receive a six-digit code, and confirm with it.
- The code is valid for 10 minutes. If it does not arrive or has expired, you can request another — the button re-enables after a short pause.
- The account is created on first sign-in — there is nothing to register in advance. An invited colleague only has to open the link in their email.
- Google sign-in is available when an administrator has enabled it on your server.
- The desktop app uses the same browser sign-in and hands the session to itself.
Who is allowed in
In a corporate deployment an administrator restricts sign-in at the server level:
- An allowlist of domains or addresses — only people whose email is on it can get in.
- Sign-up disabled — new people arrive only through an invitation to a workspace.
Tokens
Everything that works without a browser authenticates with a token. There are three kinds, and they are not interchangeable.
| Token | Prefix | Where it comes from | How far it reaches |
|---|---|---|---|
| Personal (PAT) | bnp_ | Settings → API tokens, or bounc login | Everything you can do, in every workspace you belong to |
| Daemon | bnd_ | Issued when a runtime registers | One workspace, daemon operations |
| Turn pass | bnt_ | Issued for each agent turn, revoked when it ends | One turn, in one workspace |
Only a SHA-256 hash is stored server-side, which is why the full value is shown exactly once — at creation.
The personal token
A PAT stands for you entirely: it reaches every workspace you belong to and can do anything you can. It is the credential for the CLI, scripts, and direct REST calls.
- Creating one — under Settings → API tokens: a name and an expiry (30 days, 90 days, a year,
or no expiry, listed last with a warning). Without an expiry in the request a token gets 90 days; a
token without one has to be asked for by name (
never_expiresover the API,--never-expiresinbounc auth token create) and is written to the organization's journal.bounc loginissues one for you. - Using it over REST — the
Authorization: Bearer bnp_…header. - Revoking — in the same place. Revocation is permanent and immediately breaks whatever used the token.
- What you can see — the prefix, the creation date, the last time it was used, and the expiry.
Renewal
A token with an expiry does not renew simply because it is used. Renewal is its own operation, and the daemon is what performs it: when its operator's PAT is less than 7 days from expiring, the daemon extends it by another 90 days. That is what keeps a long-lived machine from dropping off overnight.
A token created as no-expiry never expires and needs no renewal. Only personal tokens can be renewed — daemon and task tokens have lifecycles of their own.
A PAT's full value is shown once. The server keeps only the hash and cannot recover the original — copy it immediately, and if you lose it, revoke and create a new one.
The daemon token
Issued when a daemon registers a machine, and bound to a single workspace. It can do exactly what a daemon needs: claim runs from the queue and report results. Unlike a PAT, it does not roam your other workspaces.
There is nothing to manage by hand — the daemon issues and refreshes it as part of registering. Substituting a personal token is a bad trade: it would hand a process on a machine far more authority than it needs.
The turn pass
Issued for each turn of an agent and revoked when the turn ends. It stays inside the turn's sandbox, and every action the agent takes with it is attributed to the agent in that turn: messages, status changes and edits read as the agent's, not a person's.
An agent is not the person it works for. The pass carries the user id of the person responsible for the turn, but the permission checks run against the agent itself: it does not inherit what that person can reach. Which is why another member's private agent cannot be "borrowed" through one of your own.
Which one to use
- CLI, a script, a REST integration — a personal token. In CI, issue a separate token with an expiry rather than reusing your working one.
- A machine running a daemon — nothing to choose: the daemon issues its own token when it registers.
- Inside an agent run — the token is already in the environment; there is nothing to do by hand.
Next
- CLI reference — how the CLI authenticates and where profiles live.
- API — the same token over HTTP.
- Computers and machines — where a daemon token comes from.