What we can see
What we can open in your workspace, what a database reader gets, what we never store, and the limits that remain.
We can open every value in your workspace. The encryption model, and why it is not zero-knowledge, is on encryption in the cloud. This page lists what that access reaches.
What we can open
| Fact | Detail |
|---|---|
| Scope | Any value in your workspace. Your machines need values delivered, and our console shows one in an audited reveal. |
| Access path | An explicit read is the only way through, and every read lands an audit entry naming the actor and the address. |
What a copy of our database gets
Each stored version holds the sealed bytes, the parameters needed to open them, the data key in wrapped form, and the id of the key that wrapped it. The wrapping key lives in a key management service, never in our database.
| Readable from our database | Not readable |
|---|---|
| Sealed value bytes, the wrapped data key, the wrapping key id | Any value, any unwrapped data key |
| Key names, paths, project and environment names, timestamps | The wrapping key |
| One-way password hashes | Any password |
| One-way hashes of machine credentials | Any machine credential that still authenticates |
Each sealed value is bound to its full address, so bytes moved to another environment or workspace do not open. See where a value lives.
Never stored
- A dynamic value's minted credential. We keep only the handle the provider needs to revoke it.
- Your local value files after
penv push. The command deletes each file it read once the values land. - A value, a key's contents, or a third party's response body inside an audit entry.
Customer-held wrapping key
On Enterprise, or on Pro with the customer-managed keys add-on, you can wrap with your own key in AWS KMS, Google Cloud KMS, Azure Key Vault, or HashiCorp Vault Transit.
If you disable it, we can no longer open your values; there is no fallback key. See encryption in the cloud and encryption and BYOK.
Plaintext at a subprocessor
Our hosting provider runs the compute that decrypts a value to serve it, so plaintext exists there in memory for one request. The subprocessor register names it.
Limits
Anything inside the process that received a value can read it. penv run puts values in one child process, and a malicious dependency in that child, or a malicious step in the same CI job, is inside the boundary. See values in a CI build.
| Case | Outcome |
|---|---|
| Valid credential with a read role | Gets the value; your audit log records the read. You detect it after the read. |
| Copied host key on a plain VPS | Authenticates once before both sides lock out. Detection, not prevention. See a host that proves nothing. |