Appearance
Encryption & credentials
To do its job, Liddr holds the credentials it needs to reach your connected systems — API tokens, passwords, and similar secrets. Those credentials are encrypted at rest using cloud-managed keys, are never shown back to you after you enter them, and are never written to logs. This page explains the assurances around how Liddr handles your secrets.
Encrypted at rest with cloud-managed keys
Every secret Liddr stores is encrypted before it is written to disk. Liddr uses envelope encryption backed by AWS Key Management Service (KMS):
- Each secret is encrypted with its own unique key.
- That unique key is itself protected by a master key that is held in AWS KMS.
- The master key never leaves the key-management hardware. Even with direct access to stored data, an attacker would hold only protected keys they cannot unwrap.
This model is the cloud-industry standard for protecting sensitive data at rest, and it comes with the assurances that follow from it:
- The master key stays in managed key hardware — it is never exported, copied, or stored alongside your data.
- Key rotation is automatic and requires no migration of your existing data.
- Every use of the key is auditable, with a record of who used it and when.
- Access can be revoked centrally, immediately cutting off the ability to decrypt.
Encryption in transit, too
In addition to encryption at rest, all traffic to and from Liddr — and between Liddr and the systems it connects to — is protected in transit with TLS.
Secrets are never shown back
Once you enter a credential, Liddr never displays it again in plaintext. When you revisit your settings, a saved secret is shown only as a masked placeholder — enough to confirm that a value is set, never enough to read it. This applies to every credential you add, whether it's a built-in field or a credential for a connector you configured yourself.
Secrets are never logged
Liddr does not write secret values to its logs. When it records that a setting was saved or used, it logs the name of the setting — never the value. The encryption layer is deliberately quiet about its internals as well: a failed decryption is reported as a generic error rather than anything that could reveal information about the key or the data.
Only the minimum is kept
Liddr stores only the credentials it actually needs to reach the sources you connect, and nothing more. For shared, organization-wide integrations, that credential is stored once for your organization, encrypted as described above, and scoped entirely to your own workspace.
Personal and record-level sources are handled differently: they are reached live, under each individual user's own credentials, and are never stored in the shared knowledge graph at all. See Access model and MCP connectors for how that works.