Synsci CLI moves a lot of high-value credentials around. Hugging Face tokens, AWS keys, Modal secrets, plus model API access through the proxy, so the security boundary is worth understanding in detail. The model is: credentials live in the dashboard, get pulled into CLI memory at session start, are filtered into specific subprocess envs only, and are redacted from any output the CLI displays.

​
Credential lifecycle

1

Persistence: dashboard only

Credentials live in your account at cli.syntheticsciences.ai, encrypted at rest. The CLI never writes them to disk. There is no ~/.synsc/credentials file, no entry in ~/.aws/credentials, no HF_TOKEN in your shell profile. The dashboard is the only persistent layer.
2

Sync: in-memory at session start

Each synsc launch fetches credentials over an authenticated TLS channel and holds them in process memory. When the process exits, the credentials are gone, there’s no long-lived daemon retaining them.
3

Subprocess injection: filtered env

When the agent runs a shell command, the CLI builds a custom environment for that subprocess. Provider keys that aren’t relevant to the command are stripped, see the filtering policy below.
4

Output redaction: replaced before display

Any subprocess output that contains a known credential value is replaced with [REDACTED] before reaching your terminal scrollback or being saved in session logs.

​
Subprocess env filtering

Not every subprocess needs every credential. The CLI filters the env it passes based on what the command is doing:
SubprocessCredentials passed
Python training scriptHF, W&B (if used), and any cloud creds (AWS/GCP) the script imports
gitNone of the synced provider keys; git doesn’t need them
curl to a third-party APINone, curl gets a clean env unless the prompt explicitly authorized otherwise
modal CLIModal token only
lambda-cloud CLILambda key only
aws CLIAWS keys only
The filter is conservative by default. If you ask the agent to run an unfamiliar command, fewer credentials reach it than reach a known framework command. This protects against an unexpected program exfiltrating secrets, even if the agent is talked into running it, the env is empty. You can override filtering for a specific command by being explicit in your prompt: “Run printenv with HF_TOKEN exposed so I can verify the value.” The agent treats this as an authorization and unmasks for that single call.

​
Output redaction

Even though credentials only enter subprocess envs, sometimes a command echoes one back. Common cases: printenv, debug logs from cloud SDKs, or a misconfigured curl command with -v. The CLI runs an output filter that scans subprocess stdout and stderr for any synced credential value and replaces it with [REDACTED] before display: 
> @build run env | grep KEY
AWS_ACCESS_KEY_ID=[REDACTED]
AWS_SECRET_ACCESS_KEY=[REDACTED]
WANDB_API_KEY=[REDACTED]
The redaction is purely client-side. The subprocess saw the real values; only your terminal sees the masked version. This prevents accidental disclosure when you screenshot a session, share a recording, or paste output into a chat.
Redaction matches exact substring values. If you obfuscate or partial-print a credential (e.g. ${HF_TOKEN:0:8}), only the matching portion is redacted. Be careful in your own scripts that print secrets.

​
Authentication: device flow

The CLI uses a device-code OAuth flow to authenticate against the dashboard. The flow:
  1. CLI requests a device code from the dashboard.
  2. Dashboard returns the code and a short-lived (15-minute) verification URL.
  3. CLI prints the URL and code; opens your browser.
  4. You confirm the code in the browser.
  5. CLI polls until the dashboard issues a Bearer token, then stops polling.
Why device flow:
  • No localhost callback server. The CLI doesn’t open a port for the OAuth callback, there’s nothing to attack on the local machine.
  • Works headless. SSH and remote-tunnel sessions can complete login by visiting the URL on any device.
  • Codes expire fast. A 15-minute window means a stolen device code is useless after the timeout.
To rotate the Bearer token, run synsc connect logout and synsc connect login again.

​
Per-user isolation

Even on shared infrastructure, your credentials and sessions are isolated:
  • Supabase Row-Level Security scopes credential rows to your user ID at the database level. Even an admin without explicit permissions cannot read your row.
  • Bearer-token auth means each session presents a token bound to your user ID. The dashboard rejects any request not matching the issuing user.
  • Process memory is per-CLI-process. Two CLI sessions on the same machine each pull their own credentials from the dashboard, they don’t share state.
If you’re on a shared workstation, run synsc connect logout when you step away. The Bearer token becomes unusable immediately.

​
Network surface

The CLI talks to:
  • The Synsci dashboard at cli.syntheticsciences.ai for credential sync and usage reporting.
  • The Synsci model proxy for Anthropic, OpenAI, and Google routing.
  • Whatever the agent decides to call, git remotes, cloud APIs, package registries, etc.
The first two are mandatory and use TLS. The third is whatever your prompt produces. If you’re in a sensitive environment, run the CLI behind your usual outbound firewall and policy controls.

​
Reporting issues

If you find a security issue in Synsci CLI, please email security@syntheticsciences.ai with a description and reproduction steps. Critical issues are acknowledged within 24 hours.

​
What’s next

  • Credentials. The user-facing view of how tokens enter and leave subprocesses.
  • Dashboard. The persistent layer where credentials and sessions live.