Back Up Keys That Decrypt, Regenerate Keys That Sign

GPG key management lessons from running a small infrastructure team — with AI agents in the commit history.

Our team keeps shared secrets as GPG-encrypted files in a private git repo. It’s an old pattern, it works, and it recently forced us to think clearly about something most GPG guides gloss over: not all keys deserve the same treatment. Some keys must be backed up like your life depends on it. Others should never be backed up at all — and backing them up actively makes you less secure.

Here’s the model we landed on.

Two kinds of keys, opposite rules

Once we wrote down every GPG key in use, they fell cleanly into two classes:

Encryption keys — the personal keys each teammate holds, which the secrets repo encrypts to. Files encrypted to these keys can only be read by these keys. Lose the private key and the data encrypted to it is gone forever. There is no recovery path, no support ticket, no re-generate button.

Signing keys — keys that only ever produce signatures: commit signing, tag signing. Nothing is ever encrypted to them. If one vanishes, you generate a replacement, register it with your git host, and carry on. Old commits stay verified, because verification checks the key that was registered at signing time.

That asymmetry gives you the whole policy in one sentence:

Back up keys that can decrypt. Regenerate keys…