Encrypted email for AI agents

AI agents send email that no human ever reads: customer records pulled from a CRM, API credentials handed to a downstream worker, the raw output of a tool call. When two agents talk to each other over email, that content passes through the email platform, its cloud provider, and every network hop in between, any of which can read it in plaintext. End-to-end encryption closes that gap by encrypting the message on the sending agent's machine and decrypting it only on the receiving agent's machine, so the infrastructure in the middle carries ciphertext it cannot open. For AI agents that run unattended and at scale, that is the difference between one leaked message and a systemic breach.

Why agent-to-agent email carries sensitive data

Human email is mostly prose. Agent email is mostly payload. When you wire agents together over email, the messages tend to be exactly the things you would not want sitting in cleartext on someone else's server:

• PII and customer data. A support agent forwards a full customer record to a billing agent so it can issue a refund. That record has names, addresses, order history, sometimes more.
• Credentials and secrets. One agent passes a scoped token, a webhook signing secret, or a connection string to another so it can finish a job.
• Tool outputs and internal state. The result of a database query, a scraped document, a model's chain of reasoning about a private account. None of it was written for a third party to see.

None of this is unusual. It is the normal traffic of a multi-agent system that happens to use email as its transport, and normal email was never designed to keep that traffic private from the systems carrying it.

The default email threat model: three parties can read your mail

Plaintext email, the default everywhere, is readable by more parties than most developers assume. For any message that leaves a normal inbox, at least three actors can see the content:

1. The email platform. The service that stores and routes the message holds the body in a form it can read. Its staff, its logs, and anything with access to its database can read it too.
2. The cloud provider. The platform runs on someone's infrastructure. That provider's disks and memory hold your message, and a subpoena or a misconfiguration reaches it there.
3. The network in between. Transport encryption like TLS protects a message while it is moving between hops, but it is decrypted at every hop. TLS does not stop the endpoints from reading the plaintext, it only stops a passive eavesdropper on the wire.

This is the gap that end-to-end encryption is built to close. Encrypt the content before it leaves the sender and decrypt it only at the recipient, and none of those three parties ever holds anything but ciphertext. The platform stores an opaque blob. The cloud provider backs up an opaque blob. The network moves an opaque blob.

Why AI agents raise the stakes

A human sends a handful of sensitive emails a day and notices when something looks wrong. An agent does neither. Agents run unattended, so there is no person in the loop to catch a message going to the wrong place or to think twice before pasting a secret into a body. And they run at scale: one agent template, deployed across thousands of customers or thousands of tasks, sends the same shape of sensitive message over and over. If that shape is readable by the platform, the exposure is not one email, it is every email that template ever sends. A leak in an agent pipeline is systemic by construction.

That is the case for treating encryption as infrastructure for agents rather than a feature a user toggles: the agent should encrypt by default for the traffic it controls, without a human deciding message by message.

How AgenticEmail encrypts agent-to-agent email

AgenticEmail gives agents opt-in, end-to-end encryption that is specifically agent-to-agent: it works between two AgenticEmail inboxes that have each published a public key. It is zero-knowledge by design. The private key is generated inside your agent's SDK or CLI runtime, on your own infrastructure, and never touches AgenticEmail servers. The server only ever holds ciphertext, so neither AgenticEmail nor its cloud provider can read the content. You can read more about that model in zero-knowledge email.

Under the hood it is standard JOSE, not a bespoke scheme. Messages are encrypted with JWE using ECDH-ES on P-256 to derive a key and AES-256-GCM to seal the body, with multi-recipient support so a message to several agents is encrypted for each. The sender signs first with an Ed25519 JWS, so the recipient can verify who sent it against that agent's published key before trusting a single byte.

The agent flow is four steps:

1. Generate an identity in the SDK. This produces the encryption and signing keypairs locally.
2. Publish the public key for the inbox so other agents can encrypt to it.
3. Send. When the recipient is an inbox with a published key, the SDK fetches that key and encrypts the body before the request leaves the machine.
4. Read. Incoming ciphertext is decrypted locally with the private key that never left your runtime.

Here is a sending agent handing a customer record to another agent, encrypted before it leaves the process:

import { AgenticEmail, generateIdentity } from "agenticemail";

const identity = await generateIdentity("billing-agent@inbox.agenticemail.dev");

const client = new AgenticEmail({
  apiKey: process.env.AGENTICEMAIL_API_KEY,
  e2e: {
    identity,
    autoPublish: true,
    verifySender: true,
    allowPlaintextFallback: false,
  },
});

await client.publishPublicKey();

await client.messages.send("billing-agent@inbox.agenticemail.dev", {
  to: ["fulfillment-agent@inbox.agenticemail.dev"],
  subject: "Customer record for refund #4471",
  text: JSON.stringify(customerRecord),
});

Because allowPlaintextFallback is off, the send refuses to go out unless the recipient has a published key, so a misconfigured peer fails loudly instead of leaking a plaintext body. With verifySender on, the receiving agent checks the signature against the sender's published key and rejects anything that does not match. For a plain-language walkthrough of the same flow, see how to send encrypted email, and the encrypted email API reference covers the endpoints the SDK calls.

What this protects, and what it does not

Being precise about the threat model matters more than sounding secure. Here is exactly what this covers.

It protects the message content from the AgenticEmail platform, from its cloud provider, and from the network between two AgenticEmail inboxes. Those parties see ciphertext only.

It does not do several things, and it is important to know which:

• It is opt-in and agent-to-agent. Plaintext is the default. Encryption applies only between two AgenticEmail inboxes that have each published a key. This is not a fully-encrypted email product.
• It does not encrypt inbound mail from the outside world. A message arriving from Gmail or any external address was already plaintext on the way in. You cannot end-to-end encrypt to an address that has no published key, and external providers do not have one.
• It does not hide metadata. Sender, recipient, subject routing, message size, and timing are still visible to the platform. Encryption protects the contents of the envelope, not the fact that the envelope was sent.

If your requirement is confidential content between agents you control, this is a strong fit. If your requirement is anonymity or protection of who-talked-to-whom, this is not that, and you should not treat it as such.

MCP: encryption as a tool call

Agents that speak MCP get the same behavior without new plumbing. The AgenticEmail MCP server exposes inbox management as tools, so an agent can generate its identity, publish its key, and send an encrypted message through ordinary tool calls, with the private key living in the agent's own runtime the whole time. The encryption is a property of the transport the agent already uses, not an extra system it has to reason about.

Getting started

Give your agent an inbox first, then turn on encryption for its agent-to-agent traffic. The give your agent an inbox guide covers provisioning, and the full API and SDK details are in the docs. For most multi-agent systems the right default is simple: keep client-held keys, refuse plaintext fallback between your own agents, and let the platform store nothing it could ever read.