> ## Documentation Index > Fetch the complete documentation index at: https://trytilde.ai/docs/llms.txt > Use this file to discover all available pages before exploring further. # Secret encryption > Tilde protects connection secrets, API keys, and tokens with envelope encryption, AES-256-GCM, and a key that you control. Tilde uses envelope encryption. Two kinds of key are involved: * The **envelope encryption key** (EEK) is the top-level key. You control it, and Tilde never stores it. * A **data encryption key** (DEK) encrypts your secrets. Tilde generates it, encrypts it with the EEK, and stores only that encrypted copy in PostgreSQL. Tilde uses the DEK to encrypt connection secrets, OAuth tokens, webhook signing keys, and every other secret it stores. Tilde issues a DEK for each registry. Envelope encryption in Tilde: the envelope encryption key from your key provider unwraps the data encryption key, which encrypts each secret with AES-256-GCM before it is stored in PostgreSQL
Click to zoom
A database dump alone is useless to an attacker. Without your EEK, the DEK cannot be unwrapped, and without the DEK, no secret can be read. ## Choose an envelope key provider Tilde generates and manages DEKs for you. You configure the EEK when the gateway starts. Create a KMS key and give the gateway's role permission to use it. Tilde asks KMS to generate the DEK and to unwrap it at startup, so the EEK never leaves the KMS hardware security modules. The gateway needs only two permissions on the key: `kms:GenerateDataKey` and `kms:Decrypt`. Tilde binds every KMS call to an encryption context, and verifies that KMS used the key you configured. Generate a 256-bit key with the Tilde CLI, and supply it to the container as a secret from your secret manager. The value is raw key material, not a password. We can add other key providers to meet your requirements, such as HashiCorp Vault. Use a user-provided key for local development and automated tests. Use AWS KMS, or another managed provider, for every cloud environment, including development and production. Tilde supports envelope key rotation, and we advise rotating your EEK regularly. ## How secrets are encrypted | Property | Value | | - | - | | Cipher | AES-256-GCM, an authenticated cipher. Tampered ciphertext fails to decrypt. | | Keys | 256-bit, from a cryptographically secure random number generator. | | Nonce | Unique for every encryption. | | Context binding | Each ciphertext is bound to the record and field it belongs to. | Context binding stops an attacker who can write to the database from moving a ciphertext to another record or field. A secret copied into the wrong row fails authentication and is rejected. ### What is encrypted and what is hashed Tilde encrypts values it must read back, and hashes values it only needs to verify. | Encrypted, because Tilde must read them back | Hashed, because Tilde only verifies them | | - | - | | Connection credentials and OAuth tokens | Management API keys | | Webhook and token signing keys | Agent deployment tokens | | Connection setup data | Identity verification tokens | Tilde shows a hashed credential once, when you create it. It cannot show it again. ## How secrets are handled in memory Encryption at rest protects the database. Tilde also limits how long a decrypted secret exists in the gateway's memory, and what can read it there. * **Short-lived.** Tilde holds a decrypted credential in memory only briefly, and never longer than the credential itself is valid. * **Wiped, not only freed.** Tilde overwrites keys and decrypted values the moment it releases them. Secrets do not linger in freed memory, where a memory disclosure bug, core dump, or swap file could expose them. * **Never logged.** Secrets are carried in types that redact themselves in debug output and refuse serialization. A stray log line or error report cannot contain a secret. * **Never traced.** Credential headers are marked sensitive, and Tilde's instrumentation does not capture request bodies or authorization headers. * **Constant-time checks.** Tilde verifies signatures without leaking timing information. * **Memory safe.** The gateway is written in Rust, which rules out the buffer overflows and use-after-free bugs behind most memory disclosure attacks. Agents have no access to any of this data. They run in separate containers, across a network boundary, and they receive only short-lived invocation tokens. See [IAM](/docs/iam). ## Standards alignment Tilde's encryption follows published guidance for cryptographic storage. | Guidance | How Tilde follows it | | - | - | | [OWASP Cryptographic Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html) | Authenticated encryption with AES-256. Separate data and key encryption keys. Keys stored apart from the data they protect. Keys generated by a cryptographically secure random number generator. A managed key service for production. | | [OWASP Secrets Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) | Centralised secret storage. Automated rotation of OAuth tokens. Secrets kept out of logs. Least-privilege access to secrets, enforced per agent. | | [NIST SP 800-38D](https://csrc.nist.gov/pubs/sp/800/38/d/final) | Galois/Counter Mode with a unique 96-bit nonce for every encryption under a key. | | [NIST SP 800-57 Part 1](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final) | A key hierarchy that separates key-wrapping keys from data keys, and 256-bit symmetric keys. | | [FIPS 140-3](https://csrc.nist.gov/pubs/fips/140-3/final) | With the AWS KMS provider, the envelope key stays inside AWS KMS hardware security modules, which AWS validates under FIPS 140-3. | | OWASP Top 10, [A02 Cryptographic Failures](https://owasp.org/Top10/A02_2021-Cryptographic_Failures/) | No secrets in plaintext at rest. No deprecated ciphers or modes. No hard-coded keys. |