A Defensible Answer to Every AI Email Security Question

MultiMail gives security teams cryptographic agent identity, formally verified oversight policies, and a complete audit trail — built for AI email risk, not retrofitted from generic ESPs.

The problem

Why this matters

When an AI agent sends email on behalf of your organization, security teams face four hard questions: Who authorized it? What controls prevented unauthorized sends? Can you prove the sending agent is who it claims to be? And if something goes wrong, can you reconstruct exactly what happened and why? Generic ESPs were built for human senders. They have no concept of agent identity, policy-enforced oversight, or action-level auditability. AI agents operating through conventional email infrastructure create an accountability gap that regulators — including under the EU AI Act — increasingly expect to be closed before deployment.

The solution

How MultiMail solves this

MultiMail addresses the CISO evaluation checklist with four concrete controls. Cryptographic identity: Every outbound message carries ECDSA-signed headers identifying the sending agent, tenant, and oversight policy in effect at send time. Recipients and auditors can verify these headers without contacting MultiMail. Formally verified oversight: Oversight mode policies are specified and verified in Lean 4. The gated_send guarantee — that no message is delivered without human approval — is not a test result; it is a machine-checked proof that holds for all possible API call sequences. Pre-send domain intelligence: Before any email leaves the system, MultiMail scores the recipient domain against reputation signals, DMARC alignment, and threat indicators. High-risk sends are blocked before reaching the approver queue. Immutable audit trail: Every action — read, compose, send request, approval, rejection, cancellation — is logged with agent ID, policy state, and timestamp. Each entry is tied to the cryptographic identity of the actor.

1

Inspect Identity Headers

Every outbound message includes X-MultiMail-Agent-Id, X-MultiMail-Tenant, X-MultiMail-Oversight-Mode, and X-MultiMail-Signature headers. The signature is an ECDSA signature over message content and metadata. Any recipient or auditor can verify the signature using the tenant's published public key — no round-trip to MultiMail required.

2

Review Policy Controls

Oversight modes are configured per mailbox and enforced at the API layer, not in application code. Under gated_send, the send_email endpoint queues messages for human approval rather than delivering them, regardless of how the API call is constructed. The agent has no code path to force delivery — the enforcement is in MultiMail's infrastructure.

3

Trace Audit Events

The audit trail captures every action the agent takes: emails read, drafts composed, sends requested, approvals granted or denied, and messages cancelled. Each event is linked to the agent's cryptographic identity and the oversight policy active at the time. Events are queryable via the REST API and streamable to a SIEM via webhooks.

4

Validate Domain Intelligence

Pre-send checks run before every outbound message, scoring recipient domains against DMARC alignment, domain age, known blocklists, and delivery reputation signals. Risk scores appear in the approval queue so human approvers have the context needed to evaluate each send request. Your policy can set a risk threshold above which sends are automatically blocked.

5

Approve Deployment

The CISO evaluation package includes: identity signing configuration and public key publication details, Lean 4 proof artifacts for the oversight model, audit log schema and retention policy documentation, and domain intelligence coverage summary. This provides a documented, attestable evidence set for internal governance and regulatory reporting under the EU AI Act.

Code examples

Implementation

Create a Mailbox with Enforced Oversight and Identity Signing
python
import multimail

client = multimail.Client(api_key="mm_live_...")

mailbox = client.create_mailbox(
    address="[email protected]",
    oversight_mode="gated_send",
    approver_email="[email protected]",
    identity_signing=True
)

print(f"Mailbox:          {mailbox.address}")
print(f"Oversight mode:   {mailbox.oversight_mode}")
print(f"Identity signing: {mailbox.identity_signing}")
print(f"Approver:         {mailbox.approver_email}")
"cm"># Mailbox:          [email protected]
"cm"># Oversight mode:   gated_send
"cm"># Identity signing: True
"cm"># Approver:         [email protected]

Provisioning a mailbox with gated_send sets the oversight policy at the infrastructure level. The agent cannot deliver any message without prior human approval — this is enforced server-side regardless of how the agent constructs API calls.

Verify Agent Identity on a Received Email
python
import multimail

client = multimail.Client(api_key="mm_live_...")

email = client.read_email(email_id="em_01HXYZ4K8MNGP3QRS7T")

headers = email.identity_headers
print(f"Agent ID:          {headers[&"cm">#039;x-multimail-agent-id']}")
print(f"Tenant:            {headers[&"cm">#039;x-multimail-tenant']}")
print(f"Oversight mode:    {headers[&"cm">#039;x-multimail-oversight-mode']}")
print(f"Signature:         {headers[&"cm">#039;x-multimail-signature'][:40]}...")
print(f"Signature valid:   {email.identity_verified}")
print(f"Domain risk score: {email.domain_intelligence.risk_score}")
print(f"DMARC policy:      {email.domain_intelligence.dmarc_policy}")
"cm"># Agent ID:          agent_01HABC9ZDEF...
"cm"># Tenant:            ten_01HDEFGHI...
"cm"># Oversight mode:    gated_send
"cm"># Signature:         3045022100a8b4f2c91d3e...
"cm"># Signature valid:   True
"cm"># Domain risk score: 0.04
"cm"># DMARC policy:      reject

Read an email and inspect the identity headers to confirm the sending agent's cryptographic identity. The identity_verified field indicates whether the ECDSA signature validates against the claimed agent ID and message content.

Audit the Pending Approvals Queue
python
import multimail

client = multimail.Client(api_key="mm_live_...")

pending = client.list_pending(
    mailbox="[email protected]"
)

print(f"Pending approvals: {pending.total}")
for item in pending.items:
    print(f"\n  ID:             {item.id}")
    print(f"  To:             {item.to}")
    print(f"  Subject:        {item.subject}")
    print(f"  Queued:         {item.created_at}")
    print(f"  Agent ID:       {item.agent_id}")
    print(f"  Domain risk:    {item.domain_intelligence.risk_score}")
    print(f"  DMARC:          {item.domain_intelligence.dmarc_policy}")
"cm"># Pending approvals: 2
"cm">#   ID:             pend_01HPQR7M...
"cm">#   To:             [email protected]
"cm">#   Subject:        Security review findings for AI email controls
"cm">#   Queued:         2026-04-19T14:32:11Z
"cm">#   Agent ID:       agent_01HABC9Z...
"cm">#   Domain risk:    0.07
"cm">#   DMARC:          reject

List all messages awaiting human approval. Each item includes recipient domain intelligence so approvers and auditors can evaluate send risk before acting. This endpoint is suitable for compliance snapshots and SIEM ingestion.

Approve or Cancel a Queued Send via REST API
bash
"cm"># Approve a queued send (audit event records approver identity and timestamp)
curl -X POST https://api.multimail.dev/decide_email \
  -H "Authorization: Bearer $MULTIMAIL_API_KEY..." \
  -H "Content-Type: application/json" \
  -d &"cm">#039;{
    "message_id": "pend_01HPQR7M...",
    "decision": "approve",
    "approver_note": "Verified recipient domain and content — cleared for delivery"
  }&"cm">#039;

"cm"># Cancel a queued send (blocked on domain risk threshold failure)
curl -X POST https://api.multimail.dev/cancel_message \
  -H "Authorization: Bearer $MULTIMAIL_API_KEY..." \
  -H "Content-Type: application/json" \
  -d &"cm">#039;{
    "message_id": "pend_01HSTU9N...",
    "reason": "Domain risk score 0.82 exceeds CISO-configured threshold of 0.30"
  }&"cm">#039;

The decide_email and cancel_message endpoints let approvers act on queued messages programmatically. Both actions are recorded in the audit trail with the approver's identity and a reason field that appears in compliance reports.

Benefits

What you get

Cryptographic Agent Identity

ECDSA-signed headers on every outbound message prove which agent sent it, under which tenant, and which oversight policy applied. Verification is offline — recipients and auditors use the tenant's published public key and do not need to call MultiMail. This provides non-repudiation suitable for legal and regulatory proceedings.

Mathematically Verified Oversight

Oversight mode policies are specified in Lean 4 and formally verified. The gated_send guarantee — no message delivered without human approval — holds for all possible API call sequences, not just tested ones. Proof artifacts are available for independent review as part of the CISO evaluation package.

Pre-Send Domain Intelligence

Every recipient domain is evaluated before delivery against DMARC alignment, domain age and registration signals, and known threat indicators. High-risk sends are blocked or flagged before they reach the approver, reducing the blast radius of a compromised or misbehaving agent.

Action-Level Audit Trail

Every read, compose, approval request, approval decision, and cancellation is logged with agent ID, oversight mode, and timestamp. The log is append-only and each entry is cryptographically attributed to the acting agent. Webhook streaming delivers events to your SIEM in real time.

EU AI Act Readiness

The EU AI Act requires traceability (Article 13), human oversight (Article 14), and transparency for systems interacting with humans (Article 52). MultiMail's audit trail, gated_send enforcement, and ECDSA identity signing address these requirements directly for AI systems that send email on behalf of organizations.

Oversight

Recommended oversight mode

Recommended
gated_send
gated_send is the appropriate starting point for enterprise AI email deployments under CISO review. The agent can read inbox and gather context autonomously — reducing friction on non-risky operations — but no message is delivered without a designated human approver acting first. This gives security teams full visibility into outbound send patterns during initial deployment without blocking the agent from functioning. The enforcement is server-side: the agent cannot bypass it through any API call sequence, and this property is formally verified in Lean 4. For environments subject to EU AI Act Article 14 human oversight requirements, gated_send provides the clearest compliance posture. Once the agent's send behavior is well-characterized through the audit trail, organizations can evaluate whether monitored or autonomous mode is appropriate for specific mailboxes.
FAQ

Common questions

How does MultiMail prove which agent sent a given email?
Every outbound message includes X-MultiMail-Agent-Id, X-MultiMail-Tenant, X-MultiMail-Oversight-Mode, and X-MultiMail-Signature headers. The signature is an ECDSA signature over message content and metadata, generated using the tenant's private key. Any recipient can verify the signature using the corresponding public key, which is published at a well-known endpoint for the tenant. Verification is fully offline — no round-trip to MultiMail is required. This provides non-repudiation: a verified signature is evidence that the identified agent sent the message under the stated oversight policy.
What prevents an agent from bypassing gated_send and delivering a message directly?
Oversight mode is enforced at the API layer, not in the agent's code. When a mailbox is configured with gated_send, the send_email endpoint queues the message for approval rather than delivering it, regardless of how the agent constructs the request. There is no parameter the agent can pass to force immediate delivery. This enforcement is also what the Lean 4 formal proof covers: the proof verifies that no sequence of valid API calls can transition a gated_send mailbox to delivery without a prior approval event from a credentialed approver.
What does the Lean 4 formal verification actually prove, and how can we review the proofs?
The Lean 4 proofs verify the formal model of MultiMail's oversight and identity systems. Specifically: (1) under gated_send, the system cannot deliver a message without a prior approval event — proven for all possible API call sequences; (2) identity header generation is deterministic given the agent credentials — no two distinct agents can produce the same valid signature for the same message; (3) oversight mode transitions require explicit tenant-level authorization and are recorded in the audit trail. Proof source files are available in the MultiMail repository under Proofs/ and can be independently checked using a standard Lean 4 toolchain. The CISO evaluation package includes compiled proof artifacts and a walkthrough of the theorem statements.
Can we audit which humans approved or rejected sends, and when?
Yes. Every approval and rejection event is recorded in the audit trail with the approver's identity, the decision timestamp, and the message ID. Human approvals via the approval UI or email are attributed to the approver's email address. Programmatic approvals via the decide_email endpoint are attributed to the API key used. The audit log is append-only and queryable via the list_pending and read_email endpoints. All events are also available via webhook for real-time SIEM ingestion.
How does pre-send domain intelligence work, and what signals does it evaluate?
Before any message is queued for delivery, MultiMail evaluates the recipient domain against: DMARC policy alignment and DKIM configuration, domain registration age and registrar reputation, presence on known spam and phishing blocklists, and historical delivery reputation signals. The result is a risk score (0.0–1.0) attached to every send request and visible in the approval queue. Your mailbox policy can set a risk threshold above which sends are automatically blocked without reaching the approver. Domain intelligence runs at the infrastructure level on every send attempt — it is not dependent on the agent's implementation.
How does MultiMail handle EU AI Act Article 14 human oversight requirements?
EU AI Act Article 14 requires that high-risk AI systems allow humans to intervene and override automated decisions with appropriate tools and understanding. MultiMail's gated_send mode implements this directly for email: no outbound message is delivered without a human decision, and the approver receives domain risk context alongside message content to make an informed choice. The audit trail addresses Article 13 traceability requirements. ECDSA identity signing supports Article 52 transparency requirements for AI systems interacting with humans. If your AI system is classified high-risk under Annex III and email is part of its operation, gated_send with audit logging and identity signing provides a defensible compliance posture for regulatory review.
Can audit events be streamed to our SIEM in real time?
Yes. Configure a webhook endpoint to receive all audit events — send requests, approval decisions, rejections, cancellations, and reads — as they occur. Each webhook payload includes the full event record: agent ID, oversight mode, message ID, decision, reason, and timestamp. The payload structure is stable and documented, making it suitable for ingestion into Splunk, Datadog Security, or any SIEM that accepts JSON webhooks. Webhook delivery is retried on failure with exponential backoff, and a delivery log is queryable via the API.
Related

Explore more use cases

EU AI Act Article 50 Email Compliance

legal

View guide →

Agent Insurability

legal

View guide →

Agent Identity Standards (NIST)

legal

View guide →
Get started

The only agent email with a verifiable sender

Email infrastructure built for AI agents. Verifiable identity, graduated oversight, and a 50-tool MCP server. Formally verified in Lean 4.

Read the Docs →See Pricing