Encrypted secret storage for SecretProxy
The secrets API now encrypts new credential values with AES-256-GCM, while the proxy recovers them only when preparing the outbound request.
Protect the stored credential value
We have added per-secret AES-256-GCM encryption and made encryption part of the secrets API’s write path. The stored record carries ciphertext together with the initialization vector and authentication tag needed to validate and recover the value.
This adds a storage boundary to the credential-injection design. A database record contains the encrypted representation; the request path supplies the key material needed to recover the credential for use.
Decrypt where the credential is used
The proxy resolves the binding, recovers the credential, and inserts it into the permitted part of the outbound request. Authenticated encryption allows decryption to fail when the ciphertext, associated cryptographic data, or key is unsuitable, rather than forwarding an unverified value.
The implementation includes generated-key and bring-your-own-key paths. Key handling remains part of the integration: the application may avoid carrying the upstream credential while still holding material that authorizes its use through SecretProxy.
Treat encryption as a lifecycle responsibility
Operators need a recovery and rotation plan for the key material as well as the upstream credential. Losing a required key can make an encrypted value unusable; exposing it can undermine the boundary the encryption is intended to provide.
The API now encrypts new writes. Existing records and older formats still require migration attention. The proxy also necessarily handles plaintext during authorized forwarding, so this design protects stored values without making the proxy blind to the credentials it uses.