Security and data

How your keys and data are protected, what we keep, and how to report a problem.

Keys and session passes

Keys let code act for one project. We store only a hash of each key, so no one can show it to you again after it's created. You can revoke a key in the API keys tab at any time.
yb setup verifies a key entered at a hidden interactive prompt. When the optional keyring dependency and an allowed OS store are available, it offers to save the key for that platform URL after your confirmation and checks that it can read it back. It writes only this service's entry and does not delete other saved passwords. Native credential-store integrations have not yet been qualified.
Headless setup: the SDK and subsequent commands can use YB_API_KEY. yb setup --json reads that variable or one key piped on standard input; it never prompts or saves the key. Without --json, noninteractive setup reads one line from standard input. Interactive --no-keyring skips the storage offer. Setup does not write a plaintext credential file or fall back to file-based keyrings.
Session passes let the SDK use one session on one model server, for about 15 minutes. The API calls a pass a grant. A pass can't read, change or close any other session, and it stops working when its server is replaced. The SDK gets and renews passes for you.
Only people can accept terms or change the account. A key can't. A leaked key can still spend credit, up to each session's cap, so revoke it quickly.

Data in transit

Camera images go to the worker address assigned to your session. For Modal-backed models, a Yellow and Black gateway handles the connection and forwards observations to a private Modal GPU function. The production layout uses a separate gateway container for each model generation. The development sandbox runs inside the platform.
The hosted service uses only HTTPS and secure WebSockets. A copy you run on your own machine for development may use plain http.
The SDK won't send a key over plain http, except to your own machine, or when you set YB_ALLOW_INSECURE_HTTP=1 for a private network you control.
Before it sends anything, the SDK checks that the model server runs the exact model version the platform promised.
When a session uses UDP (see udp in the Python SDK), each observation and each answer is encrypted with ChaCha20-Poly1305, the cipher TLS 1.3 and WireGuard use. The key is new for every session and reaches your code only over the session's secure WebSocket. Every packet also carries a check value made with that key. The model server checks it first, and silently drops packets that fail it, repeat an old packet, or name an unknown session.

Data we keep

Camera images and robot state: our gateway does not deliberately save observation payloads. For Modal-backed inference, Modal Function inputs and outputs can be retained by Modal for up to seven days; see Modal's data retention policy. Account deletion does not erase these provider copies immediately. Any separately enabled diagnostic capture must be disclosed before use.
Session records keep counts, timings, costs, and why each session ended. The task text and label of a closed session are scheduled for redaction after 30 days. Worker reports and copied snapshots are included; unavailable workers can delay confirmation.
Money records, such as payments and the ledger, are kept for accounting.
Trial eligibility keeps a minimal keyed identity record after deletion to prevent repeated promotional claims. Raw reset/verification links are not stored.
Export and deletion: in the Project settings tab, Export my data downloads your stored account and usage history, without credentials or internal support notes. Account export requires a dashboard login. Deletion disables access immediately and continues cleanup if you close the tab. Keep the deletion receipt to check whether cleanup is pending or complete. Unused nonrefundable credit requires acknowledgment; financial and minimal security records remain. Encrypted backups age out under the deployed backup retention policy; restoring one requires security/deletion review before account access can be restored.

Dashboard sign-out does not stop a running robot session. Revoke a compromised key and close affected sessions separately. Worker grants have bounded lifetimes; network cleanup is not a substitute for the robot's local safety controls. A lost key cannot be shown again: revoke it and create another.

Model integrity

Each model runs from checkpoint files, which hold its learned weights, pinned by a hash of their bytes. A model server refuses to start if its files don't match, so a session never runs a silently changed model.

Isolation

In the Docker deployment, each real model server uses a pinned image, an unprivileged container user and a private network. A separate launcher starts those containers.
In the Modal deployment, the platform invokes a private, version-pinned GPU class using server-side Modal credentials. Customers receive scoped Yellow and Black session passes. Several customers can share that model through the gateway; this is not a dedicated GPU or operating-system sandbox for each customer.
Model servers answer on their own address (w. in front of our domain), apart from the dashboard, so their answers never share the dashboard's cookies or storage.
The dashboard loads its fonts from our own server, so opening it sends nothing to a font provider.

Report a problem

Email the contact in /.well-known/security.txt. Include the steps to reproduce the problem. Don't access other customers' data or disrupt the service while testing.