Who holds the key
What the Encryption page states on every plan, and how an Enterprise owner points penv at a key they own.
Encryption is its own row in the sidebar rather than a preference filed under Settings, because who holds the key that wraps your values is a claim about the whole workspace.
Encrypted, each value under its own key, on every plan.
What the page states
Every plan gets the same envelope and a real key management service. What changes with the plan is who owns the wrapping key. Whether there is one is settled on every plan. The page names the current holder and the region the key lives in.
Encryption in the cloud has the shape of the envelope, what the seal is bound to, and the honest limit on what a hosted store can promise.
Your own key, on Enterprise
An Enterprise owner can point penv at a key they own in one of four places.
| Backend | What penv needs |
|---|---|
| AWS KMS | The key reference and a policy allowing penv to wrap and unwrap |
| Google Cloud KMS | The key reference and a workload identity federation grant |
| Azure Key Vault | The key reference and an admin consent round trip |
| HashiCorp Vault Transit | The key reference and a federation grant |
The page renders the issuer, subject and audience your side needs to trust, so nothing has to be assembled by hand.
Connecting starts a re-wrap. Every stored data key is unwrapped under the current key and re-wrapped under yours. The sealed bytes are never touched and no plaintext value is involved.
The states a key moves through
| State | What it means |
|---|---|
pending | Connected and waiting on its first check |
rewrapping | The re-wrap is running |
active | Yours is the wrapping key |
disabling | Standing yours down is running |
revoked | Yours refused, so nothing opens under it |
failed | The connect did not complete |
retired | Superseded by a later key |
A half-finished connect can be resumed, re-checked, or abandoned. Azure's consent round trip reports back on the page with consented, declined, expired, unverified or not_configured.
Standing your key down is never gated on your plan. A lapsed plan must never leave you unable to take your own key back.
There is no fallback. A key id penv cannot place is refused outright, and "the customer key failed, use the platform key" is not something the system can express.
What each action needs
| Action | Needs | Confirm it is you | Recorded as |
|---|---|---|---|
| Read the page | org:read | No | not recorded |
| Connect your own key | Owner, on Enterprise | Yes | org.byok_rewrap_started |
| Resume a half-finished connect | Owner | No | org.byok_rewrap_started |
| Finish the Azure consent round trip | Owner | No | org.byok_rewrap_started |
| Re-check a key | Owner | Yes | org.byok_rechecked |
| Cancel a pending grant | Owner | Yes | org.byok_connect_canceled |
| Abandon a pending key | Owner | Yes | org.byok_abandoned |
| Stand your key down | Owner | Yes | org.byok_disable_requested |
None of these carries a permission slug. Being the workspace owner is the gate, and only the connect itself checks the plan.
The re-wrap lands its own entries as it runs: org.byok_activated when yours takes over, org.byok_disabled when it stands down, org.byok_revoked when your key refuses, and org.byok_rewrap_failed when it does not complete.
None of the org.byok_* entries appears in the action picker on the Audit Log page. Narrow by actor and date, then export. See browsing the record.
Next: plans, seats and invoices.