Secrets and Environment Variables
Secrets make systems useful and dangerous. Rocky should configure and verify secret-backed workflows without displaying credentials in chat or screenshots.
When this matters
This page is for operators who want Rocky to produce usable work without turning the system into a mystery box. Use it when you need a practical path, a clear verification step, and a boundary between suggestion and action.
The operating pattern
- Identify secret type. Token, API key, password, signing secret, OAuth file, or webhook secret.
- Store in the right place. Use Secret Manager, local env files, keychains, or provider vaults.
- Pass by reference. Cloud services should mount secret names or env vars, not hard-coded values.
- Verify without printing. Test status codes, hashes, or success flags without exposing the value.
- Rotate if exposed. Treat accidental display as a rotation event.
Pre-flight checklist
- No secret in chat
- No secret in screenshots
- No secret committed to public assets
- Runtime can access only what it needs
- Verification output is redacted
Common failure modes
- Helpful leaks: Printing a token to prove it exists is still a leak.
- Hard-coded credentials: Code and public repos are not secret stores.
- Over-broad access: One service should not inherit every credential.
Verification
A page is not done because it was drafted. Verify the source, run the workflow, inspect the output, and record what changed. If a step touches money, customers, accounts, permissions, or private data, keep it behind an explicit human approval gate.