# 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](https://yellowandblack.dev/docs/python-sdk.md)), 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](https://modal.com/docs/guide/security#data-retention).
  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](https://yellowandblack.dev/.well-known/security.txt). Include the
steps to reproduce the problem. Don't access other customers' data or disrupt the service
while testing.