Encryption at rest is a storage guarantee, not a privacy one

"Encrypted at rest" appears on nearly every security page, including ours, and it is usually presented as though it settles the question of whether your credentials are safe. It does not. It answers one specific question well and several adjacent ones not at all, and knowing which is which makes you a better judge of every vendor you evaluate, us included.

The threat it addresses

Encryption at rest is aimed at a copy of the data leaving the building. Not an attacker inside your running system: a copy.

The realistic list is duller than the phrase suggests. A database dump taken for debugging and left on someone's laptop. A volume snapshot restored into a staging environment with looser access. A backup bucket whose permissions drifted. A decommissioned disk that was not wiped. An analytics replica that half the company can read because nobody thought of it as production.

In every one of those, the data is separated from the system that guards it. Encryption at rest is what makes that copy worthless on its own, and it is genuinely valuable, because those are the incidents that actually happen.

The threat it does not address

It does nothing against anything holding the running system. A service that can decrypt a value in order to do its job can decrypt that value for whoever controls the service. If an attacker has the application, or the key, or both, encryption at rest is not in their way at all.

So a vendor saying "your secrets are encrypted, we cannot see them" has said two things, and only the first is a property of encryption at rest. The second is a claim about their own access controls, and it deserves its own answer.

Why the key has a name

One implementation detail is worth understanding because it tells you whether a system can ever rotate its keys. If every value is encrypted with one key and nothing records which, then changing the key means re-encrypting every row in one operation, which nobody wants to run against a live database.

The fix is to make the ciphertext self-describing: store the key's identifier alongside it. Values written after a rotation use the new key, values written before keep decrypting under theirs, and each migrates the next time it is written. Rotation becomes a gradual process rather than an outage, which is the difference between a key that gets rotated and one that never does.

What Kaja does, stated exactly

Values inside a project secret are encrypted with AES-256-GCM before they are written to the database, under a named key that allows rotation without re-encrypting everything at once. Plaintext exists in the process that needs it and on the TLS connection to the agent in your cluster, and nowhere else that persists.

Secret values are not displayed in the console by default. It lists names. Revealing an actual value is a separate permission, and doing so is recorded.

What we do not claim is the second half that vendors tend to imply: this is not a statement that nobody at Kaja could ever see a decrypted value. It is a statement that a stolen copy of the database is not a list of your credentials. Our security page says it in those terms deliberately, because the stronger claim would be the kind of thing you only find out was untrue at the worst possible time.