Application secrets

Secret lifecycle

Fork stores application secrets outside the space. Each generation is envelope-encrypted with a fresh data key, and that key is wrapped with Cloud KMS. The active value is delivered to a memory-backed runtime file rather than saved in /workspace, Git history, snapshots, or a published clone.

• Add: create a new named value without returning it.
• Rotate: replace the active generation with compare-and-swap protection.
• Revoke: remove the value from the runtime while retaining revocation metadata.
• Delete: remove the encrypted binding and runtime value.

Enter values safely

Use the Fork-owned Secrets UI or an explicitly authorized MCP secret tool. In the embedded Agent, typing/secret NAME opens the protected modal. Agent-visible metadata includes names, state, and generation, never the plaintext value.

Names and access

Secret names use uppercase environment-variable form such as STRIPE_API_KEY. Fork rejects reserved platform, interpreter, loader, Git, and SSH variables. Values are injected for registered consumers; the current application consumer is the Node runtime.

Owners, organization administrators, platform administrators, and explicit secrets.manage grantees can manage secrets. Ordinary editors cannot.

Security boundary

Host custody protects values from accidental persistence, publication, snapshots, and cross-space access. It does not hide an active value from trusted root code running inside that space. Use least-privilege provider keys, provider-side quotas, and rotation.