AutoCore Secret Management
Defines secret classes, server-only handling, and configuration boundaries.
Secrets are runtime inputs, not documentation content. The source review identified access-token, database, search, storage, mail, OAuth, payment, and webhook secret classes; public examples must contain placeholders only.
Release candidate source
This article reflects the audited AutoCore source revision 7a504f6e430c16d4fcb03ebdea3cc3fb7816df60 and immutable release-candidate tag v1.0.0-rc.1 at 9edfb109f44cc80385784c694b96392cfc04e70f. Configuration and external provider behavior remain deployment-dependent.
Source boundary
| Control | Source-verified behavior |
|---|---|
| Server-only | JWT, database, Redis, Meilisearch, R2, Resend, OAuth, payment, and webhook credentials stay in server configuration. |
| Client-visible | Only explicitly public URLs, publishable values, and feature flags may cross into browser configuration. |
| Fail-fast | Production validation rejects missing required secrets and unsafe development fallbacks. |
| Edition | Edition is explicit and unknown or unset values fail rather than selecting a default. |
| Evidence | Record presence, source, rotation date, and verification outcome without printing values. |
High-risk operation
Use explicit authorization, a written reason, a confirmation gate, and post-action verification. Documentation does not grant permission to change a deployment.
Operational controls
Use the smallest verified control for the task. Keep provider, host, legal, and operator responsibilities separate from application behavior. When a control is not implemented or not verified, leave it disabled or mark it as a limitation.
Verification
Verify the route, relevant API or configuration state, negative path, audit/evidence result, and public effect before closing the task. Record unknown or configuration-dependent behavior as a limitation.