Secrets & credential handling
Starfire uses several types of credentials. The safest rule is simple: secrets belong in dedicated credential storage, not in AI context.
Treat these as secrets
- account passwords
- password-reset tokens
- session tokens/cookies
- Starfire API keys
- service-account credentials
- webhook signing secrets
- repository tokens
- model/provider API keys
- database credentials
- Stripe or email-service secrets
- private/signing keys
.env values that grant access
Never store secrets in
- prompts
- custom-agent instructions
- Project instructions
- Knowledge sources
- screenshots
- public documentation
- client-side JavaScript
- mobile app bundles
- ordinary support notes
Use references, not values
Documentation and generated code should describe required secret names and purposes, for example:
Do not include the real value.
If a secret is exposed
- Revoke or rotate the credential.
- Update dependent services.
- Verify the replacement works.
- Review relevant logs/events for misuse where available.
- Remove unnecessary copies, but do not treat deletion as a substitute for rotation.
Least privilege
Scope developer credentials and integration permissions narrowly so exposure has a smaller blast radius.
Build artifacts
Review generated .env examples, configuration files, logs, and packaged artifacts before sharing or deploying them. FORGE should generate placeholders—not real production secrets.
Once a secret has been placed into an AI prompt, screenshot, repository, or artifact, assume the safe response is to rotate it rather than trying to determine whether every copy was successfully removed.
