Two promises, not one
AES-256-GCM is an authenticated cipher. It makes two promises at once: nobody without the key can read the value, and nobody without the key can change it undetected. The second promise is the one people forget, and it is the reason to prefer GCM over older modes that only hide data.
When a GCM value is decrypted, an authentication tag is checked first. A single flipped bit anywhere in the ciphertext fails that check, and decryption stops instead of returning something subtly wrong.
Binding a value to where it lives
GCM can also authenticate data that is not encrypted — "additional authenticated data". If the name of the row a value belongs to is fed in as that data, the ciphertext only decrypts in that row.
This closes a quiet attack: someone with write access to the database, but not the key, copying one encrypted value over another. Without binding, the swap decrypts cleanly. With it, the value refuses to open anywhere but where it was written.
What encryption at rest does not cover
At rest means in storage. If a database backup leaks, the attacker holds ciphertext. But the application that serves your values has to decrypt them, so it holds the key — and anyone who compromises the running application, not just its database, is past this protection.
That is the difference between server-side encryption and end-to-end encryption, where only your own devices hold the key. Both are legitimate designs with different trade-offs. What matters is that a product says which one it is.
Questions worth asking any secrets tool
Where is the key, and who can reach it? Is each value encrypted with a fresh random nonce? Are values authenticated, and bound to their location? Can the key be rotated without downtime? Are access tokens stored as hashes?
A tool that answers these plainly — including the ones where the answer is "no, not yet" — is telling you something useful about how it handles the rest.