Operator Security
Local auth, local API keys, support grants, setup tokens, secret handling, and public data boundaries for B3IQ operators.
B3IQ security starts with local boundaries. A node operator controls local setup, owner auth, support access, local keys, runtime state, and the decision to enroll into managed or network workflows.
Credential Classes
| Credential | Prefix or form | Purpose | Handling |
|---|---|---|---|
| Setup token | tokenized setup URL | Bootstrap or recovery | Do not log or send. Use only for initial local setup or recovery. |
| Owner session | HttpOnly cookie | Normal local operator UI | Created after owner login, not copied into CLI examples. |
| Local API key | b3iq_local_ | Local inference clients | Shown once, stored hashed, revocable, scoped. |
| Support grant | b3iq_support_ | Temporary diagnostics | Expiring, revocable, diagnostics-only, redacted support bundles. |
| Hosted gateway key | b3iq_gateway_ | Hosted developer API access | Separate from local keys, carries account ownership and usage attribution. |
| Personal access token | b3iq_pat_ | b3iq CLI and automation auth | Shown once, stored hashed, revocable from Settings → CLI tokens. Pass via the B3IQ_TOKEN env var, never argv. |
Secret Handling Rules
Use files and stdin
Store one-time keys in restrictive files and pass them through config files, stdin, or environment variables.
Put secrets in process argv
Shell history, process listings, logs, and copied snippets can leak values passed directly as command arguments.
Safe Local Key Pattern
bashumask 077mkdir -p .secretscat > .secrets/b3iq-local-keyB3IQ_LOCAL_KEY_FILE=.secrets/b3iq-local-key
Then build short-lived request config files instead of writing the bearer token in the command line.
Public Surface Boundary
Public node, model, receipt, settlement, and route-readiness payloads may expose:
- Public node and model IDs.
- Public-safe readiness status and blockers.
- Benchmark summaries and observed benchmark freshness.
- Receipt hashes, roots, counts, and totals.
- Public settlement transaction hashes and settlement status.
They must not expose:
- Raw prompts or outputs.
- API keys, customer tokens, setup tokens, local API keys, support secrets, or token hashes.
- Customer identity.
- Exact private routes or private request logs.
- Local runtime URLs, filesystem paths, tunnel IDs, tunnel tokens, or connector details.
- Raw TEE quotes or certificate chains.
SSH Access
SSH keys live at two levels. Fleet SSH keys are set once at the org level, in Settings, and are reconciled onto every machine your org owns — add a key there and it lands on the whole fleet without touching each machine. Each machine also has its own SSH lane, which you can enable or disable from the machine's dashboard page; a disabled lane refuses inbound SSH even if your fleet key is trusted elsewhere.
Switching a machine to earn mode force-disables its SSH lane along with all b3iq serving. Your stored keys are kept, not deleted, so switching the machine back to its dedicated mode only requires re-enabling the lane, not a re-setup.
Remote Support
Support grants are scoped to diagnostics. They should not authorize API-key management, owner recovery, payout account credential reveal, command execution outside allowed diagnostics, or raw prompt/output access.