Spark's launcher and starter bundle should keep secrets out of tracked files, generated config, terminal output, and model-visible context.
- Use
spark setuporspark secrets setfor sensitive values. - Module manifests declare secrets in
[needs].secretsand[secrets.*]. storage = "keychain"secrets are stored in the OS keychain when available.- If no keychain is available, Spark falls back to
~/.spark/config/secrets.local.json. - Generated module env files must not contain raw cloud API keys when the module declares the matching keychain-backed secret.
.env,.env.*, except placeholder-only.env.examplesecrets.local.json- local state under
~/.spark/state,~/.spark/config,~/.spark/logs - local runtime databases, token files, gateway state, and process logs
Before a launch or demo:
- Run
git status --shortin every touched repo. - Run a tracked-file secret scan for API-key and Telegram-token patterns.
- Run a sandbox
spark setupwith fake tokens and verify generated env files do not contain the fake cloud API key. - Confirm the real Telegram bot has exactly one polling owner and no Telegram webhook env is configured.
- Rotate any real token that was pasted into a chat, log, or terminal transcript.
If you suspect local Spark credentials or control-plane keys leaked, run:
spark security revoke-allThis stops tracked Spark processes, disables login autostart, rotates generated local bridge/API keys, disables custom MCP configs, clears Telegram webhook state where a bot token is available, removes Spark-managed local secrets, pauses local mission state, and writes a redacted support bundle. Provider-side tokens still need revocation in BotFather, GitHub, Scanner, or the relevant API console when applicable.
Spark installs and runs local agent tooling. Treat every connected LLM, browser, Telegram message, web page, plugin, and repo as potentially untrusted input. Secrets should be available only to the subprocess that needs them, at runtime, and never written into prompts, public config, committed files, or launch docs.