Security and Privacy
Version: 2.9 | Last updated: 2026-09-16
Bluebox reads live telemetry and code to investigate production issues. This page explains what it accesses, what it stores, who can see it, the boundaries it never crosses, and how to remove your data.
What Bluebox reads
| Data source | What Bluebox reads | Purpose |
|---|---|---|
| GitHub | Repository code, file trees, commits, pull requests, issues | Investigation context and publishing investigation results |
| Observability platform | Traces, logs, metrics, events, service topology, problem records | Detecting findings and diagnosing root causes |
| Your workspace | Investigations you create, chat messages you send | Running investigations and conversations |
| Your CLI | Which commands the bluebox CLI calls, the CLI version, whether a coding agent drove it and which, a random journey id that ties one run's calls together, and how a run's question ended — completed, failed, timed out, cancelled, out of quota, parked awaiting a response, or the connection closing early | Knowing whether a multi-step run such as instrumentation completed, stalled, or failed, and how long it took |
Bluebox does not read:
- Secrets, environment variables, or
.envfiles in your repositories. - Files outside the repository you have explicitly connected.
- Your prompts, file paths, or output through the journey record: the journey id is random, and the per-call journey record carries the command's route pattern, not its arguments. On an instrumentation run the CLI also sends the address of the repository's
originremote in a reduced form (host and path only - never credentials, branches, or file paths), and the record keeps only a keyed one-way hash of it, scoped to your workspace, so a run can later be matched to the telemetry that repository emits and to nothing else. Nothing in the repository is read for this. - Observability data outside the environment you have connected.
What Bluebox stores
All stored data is encrypted, scoped to your workspace, and never visible to other workspaces.
| Data type | Retention |
|---|---|
| Investigations and their timelines | Until you delete your workspace |
| Chat conversations | Until you delete your workspace |
| Observability runtime token | Until you disconnect or delete the connection |
| OTLP ingest token | Until you disconnect or delete the connection |
| Observability service-user OAuth client, when your workspace was set up with one | Until you disconnect or delete the connection |
| GitHub identity link (your GitHub user ID, not your OAuth token) | Until your account is deleted |
Bluebox never stores:
- Your GitHub OAuth token beyond the initial repository discovery step. It is discarded after repository selection. GitHub access during investigations uses short-lived tokens that expire automatically.
- Agent reasoning beyond what appears in the investigation timeline.
What Bluebox will never do
- Never merges code changes — every proposed fix requires your explicit review and approval.
- Never pushes to your branches — investigation results arrive as GitHub issues you control.
- Never stores credentials in your repository — connection credentials are used only while Bluebox is working for your workspace.
- Never accesses another workspace's data — all data access is scoped to your workspace.
- Never runs without safety controls — Bluebox limits what investigations can access and run.
- Never shows raw log lines, trace content, or query results in
askanswers — the Evidence section reports only service names, data types, time windows, and counts.
Who can see your data
- Workspace members can see their own investigations and conversations, plus any that are shared with the workspace. A new investigation you start is private to you by default, unless your workspace sets sharing as the default; investigations Bluebox starts automatically are shared with the workspace. A chat is private to you until you share it. Anything shared (an investigation or a chat) is read-only for other members: only its creator can reply to or change it.
- Workspace owners can additionally manage the workspace (members, connections, and tokens) and can access any investigation in the workspace when needed.
- Bluebox support staff can see operational metadata needed to support the service: not investigation content, not conversation content, not credentials.
Tokens and credentials
- Runtime token — used to query your observability platform during investigations. It is never shown back to you after you save it.
- OTLP ingest token — used for service instrumentation. Revealed once in Setup via Reveal token; after that, only its presence is shown.
- Service-user OAuth client — created for you during signup, if your workspace was set up that way. It is what lets Bluebox issue a replacement token when one expires, so it is kept for as long as the connection exists and is never shown to you. A workspace that was only ever connected by pasting a token of your own does not have one, and Bluebox cannot create one later. If your workspace was set up with one, it is kept when you re-connect to the same environment; connecting to a different environment starts without it, because the credential belongs to the environment it was created in.
To rotate either token, save a new one on the Setup page.
Bluebox uses layered security controls to limit what investigations can access or run. It also applies safeguards when reading external content such as logs and GitHub issues.
Removing your data
- Disconnect a connection — remove the GitHub or observability connection on the Setup page. This removes the stored credentials but preserves your investigation and conversation history.
- Delete your workspace — contact your workspace owner or Bluebox support. Deletion removes all investigations, conversations, connections, and stored credentials. Signing in again afterwards is treated as a new signup.
Questions?
Contact your workspace owner or Bluebox support for questions or concerns.