The short version
- Your browser connects using the same strong encryption used by banks and Fortune 500 companies.
- Every session is protected by a one-time credential that expires after five minutes and is locked to that exact session, which blocks impersonation attacks.
- We only route your live session data and show it to you. We do not store it, sell it, or use it to train models. (Hosted accounts still need the usual account, billing, and support data — see our Privacy Policy.)
- Secrets stay on your machine, in your operating system's secure credential store.
- For privacy and questions, contact support@bossanova.dev.
Common questions
Can someone hijack my agent and take over my session remotely? No. Two independent are required: the request must be authenticated as you — through our identity provider, and it must carry a short-lived token that our servers cryptographically signed. The token expires in five minutes and is bound to one specific session. Our servers only ever look up sessions your account owns, and they re-verify that ownership at the instant the live connection opens. The connection runs over TLS. If your local daemon goes offline or is replaced, every live view is cut immediately.
Can a malicious website open my session in the background? No. The access token is carried inside the WebSocket protocol, not a browser cookie, so a malicious page cannot ride your logged-in session.
Do you read my code, prompts, or terminal output? No. We only process live session data to route it and display it back to you. We do not read it, inspect it, store it, sell it, use it for analytics, use it to train models, or store any session transcripts in any way. See our Privacy Policy for more details.
Where does my data live? Hosted Bossanova services run in the European Union, and service data is stored in the European Union. In the default local mode, your data lives entirely on your machine and never leaves it.
How do I report a security problem? Privately, through the process described in oursecurity policy. We acknowledge reports within three business days.
For security teams
The boss daemon and cli are 100% open source. We encourage you to assign an agent to examine the code yourself if you need information about security boundaries and related decisions. Also see thedocumentation.
Authentication
Web requests authenticate with OIDC JWTs issued by WorkOS. Bossanova validates the issuer, the bosso audience, and expiry, and verifies the RSA signature against a rotating JWKS. Bossanova never stores your password. Card payments are processed by Stripe; we never store card details.
Attaching to a live session
To attach a browser to a session, the client first calls an authenticated endpoint that issues a short-lived (five-minute) signed token scoped to a single(user, session, chat) tuple. Issuing that token runs a three-axis authorization check: the chat must belong to the session, the session to the daemon, and the daemon to your user. The WebSocket upgrade then carries that token in theSec-WebSocket-Protocol header (not a cookie, which removes cross-site request forgery as a vector), verifies the signature again, and re-runs the ownership check at connect time as defense in depth. Authorization lookups only ever traverse daemons owned by the requesting user, so there is no code path that resolves another user's session.
Transport and our honest limits
Browser-to-Bossanova traffic uses TLS (HTTPS and WSS). Our hosted relay is atrusted intermediary: it terminates TLS and processes the live stream in memory to route and display it. It is not end-to-end encrypted today, which means the relay can see the stream in transit while it is being shown to you. We do not persist it as application data, and we do not use it for analytics or model training. End-to-end encryption, where the relay never sees plaintext, is not a guarantee we make yet. When you run Bossanova locally, the daemon, TUI, and plugins run as your own operating system user and trust each other through filesystem ownership.
Secrets and error reporting
Credentials are stored in your operating system's native credential store (macOS Keychain, Windows Credential Store) or, on Linux, in an encrypted file backend protected by a per-install passphrase. The insecure plaintext fallback requires an explicit--allow-insecure-keyring flag. Crash and error reports are entirely voluntary. They are scrubbed before they leave the machine: tokens, JWTs, authorization headers, and email addresses are redacted.
Scanning and disclosure
Code is scanned for known vulnerabilities and leaked secrets across several tools. Secret scanning runs on every change; the heavier static analysis (gosec), Go and JavaScript dependency and vulnerability scanning (govulncheck, pnpm audit), and semantic analysis (CodeQL) run on release-branch pull requests and pushes plus a weekly sweep of main. Report a vulnerability privately through oursecurity policy; we acknowledge within three business days.