PGP encryption explained, and a modern alternative for automation

PGP encryption is a way to scramble the contents of an email so that only the intended recipient can read it, using a pair of mathematically linked keys: a public key you share freely and a private key you keep secret. Anyone can encrypt a message to your public key, but only your private key can decrypt it, so the mail servers in the middle carry ciphertext and never see the plaintext. PGP, short for Pretty Good Privacy, and its open standard OpenPGP have been the reference design for end-to-end encrypted email since 1991, and almost every alternative since then is a reaction to what PGP got right and what it got painfully wrong.

How PGP encryption actually works

PGP combines two ideas. The first is public-key cryptography: each person generates a keypair, publishes the public half, and guards the private half. To send you a confidential message, I encrypt it to your public key, and only your private key can open it. The second idea is digital signing: I sign the message with my private key so you can verify with my public key that it really came from me and was not altered. In practice PGP does both at once, encrypting the body and signing it so a recipient gets confidentiality and authenticity together.

The hard part was never the math. It was a simpler question: how do you get the right public key for the person you want to write to, and how do you know it is really theirs? PGP's answer was the web of trust. Instead of a central authority, users sign each other's keys to vouch for them, so if you trust Alice and Alice has signed Bob's key, you can extend some trust to Bob. People held key-signing parties and compared 40-character fingerprints by hand. To make keys findable, the community ran keyservers, public directories where you upload your key and others look it up by email or fingerprint.

Why PGP encryption never went mainstream

The web of trust and keyservers were elegant on paper and brutal in practice.

• Key discovery is painful. Before you can write an encrypted first message, you need the recipient's public key, and there is no reliable, authenticated way to fetch it. Keyservers accept unverified uploads, so anyone can publish a key claiming to be you, and expired or superseded keys linger forever.
• The UX defeats most people. The famous usability study "Why Johnny Can't Encrypt" showed that even motivated users could not reliably encrypt a message without leaking it in plaintext. Keyrings, subkeys, trust levels, and revocation are a lot to ask of anyone who just wants to send an email.
• The subject line and metadata stay in the clear. PGP encrypts the message body, but the SMTP envelope and the RFC 5322 Subject, From, To, and Date headers travel unencrypted. Anyone watching the wire sees who talked to whom, when, and about what topic. For a lot of threat models the metadata is the sensitive part.
• It is hard to automate. The canonical tooling is GnuPG, a command-line program you shell out to, with keyrings living in a user's home directory. Wiring that into a server, a CI pipeline, or an autonomous agent is awkward, stateful, and easy to get wrong.

None of this means PGP is broken. The cryptography is sound and battle-tested; the friction lives in trust distribution and ergonomics, not in the ciphers.

S/MIME: the X.509 alternative

S/MIME solves the trust problem in the opposite way. Instead of a peer-to-peer web of trust, it uses X.509 certificates issued by a certificate authority, the same hierarchy that secures HTTPS. A CA vouches that a given public key belongs to a given email address, and your mail client trusts the CA. S/MIME is built into Outlook and Apple Mail, so inside a corporate directory where IT provisions certificates it can feel almost invisible.

The limits are real, though. You have to obtain and renew a certificate, often from a paid CA, and manage its lifecycle. Trust is centralized, so you inherit whatever a CA decides. Certificate exchange between organizations is clumsy, usually bootstrapped by trading signed emails first. And critically, S/MIME leaks the same metadata PGP does: the subject line and headers are not protected, and it is no easier to drive from code.

A modern JOSE-based approach

Web and API developers already solved "encrypt and sign a small payload, then verify it in any language" with JOSE, the JSON Object Signing and Encryption family. Its two workhorses are JWE (JSON Web Encryption) for confidentiality and JWS (JSON Web Signature) for authenticity, and their keys are plain JSON objects called JWKs. Every mainstream language has a mature JOSE library, so there is no shelling out to a binary and no keyring on disk.

The trust problem gets a simpler answer too: published-key discovery. Rather than a global keyserver full of unverified uploads, each address publishes its public key at a predictable, well-known location tied to its domain, and the sender resolves it by address at send time. It is conceptually similar to OpenPGP's Web Key Directory (WKD), just leaner and JSON-native. A recipient's published encryption key looks like an ordinary JWK:

{
  "kty": "EC",
  "crv": "P-256",
  "x": "f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU",
  "y": "x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0",
  "use": "enc",
  "kid": "agent-42@inbox.agenticemail.dev"
}

The sender fetches that key, derives a per-message content key with ECDH, and emits a self-contained JWE whose protected header names the algorithms:

{ "alg": "ECDH-ES", "enc": "A256GCM", "kid": "agent-42@inbox.agenticemail.dev" }

Because the whole message, including any subject you choose to put inside the payload, lives in the encrypted JWE rather than in an exposed header, you can protect content the SMTP header would otherwise leak.

PGP vs S/MIME vs modern JOSE

Where AgenticEmail fits

AgenticEmail is API-first email infrastructure for AI agents, and its end-to-end encryption is a concrete implementation of the JOSE approach above, built for programmatic agent-to-agent mail. It uses JWE with ECDH-ES over P-256 and AES-256-GCM (with multi-recipient support), plus Ed25519 JWS in a sign-then-encrypt flow. Discovery works by publishing a public key that recipients resolve, rather than by querying PGP keyservers.

Two honest caveats matter. First, encryption is opt-in, and plaintext is the default. It works only between two AgenticEmail inboxes that have published keys; you cannot end-to-end encrypt to an external Gmail or Outlook address, because those systems do not speak this protocol. Second, it is zero-knowledge: the private key is generated and kept client-side, in the SDK or CLI on your machine, and never touches AgenticEmail servers, which hold only ciphertext. If you want the deeper mechanics, see our writeups on end-to-end encrypted email, zero-knowledge email, and encrypted email for AI agents, or the step-by-step how to send encrypted email guide. The full reference lives in the docs.

Does PGP still have a place?

Yes. If you need confidential mail with the wide population already running OpenPGP, PGP is the interoperable choice, and nothing here replaces it for that job. The modern JOSE approach is not a universal PGP replacement. It is an easier-to-automate option for the case where both sides are systems you control, most naturally agents and services talking over an API. Pick PGP for interop with existing PGP users, and reach for a JOSE-based, published-key design when the priority is confidential mail a program can send and receive without a human wrangling keyrings.