MAILGENT
Start a project
Mailgent Identity

Give your agent
an identity it can prove.

An email address other systems already trust. A vault for the credentials it needs to act. 2FA codes without a phone in the loop. A calendar. And an optional KYC anchor for the moments when a counterparty asks who is behind this agent.

Create an identity →
Read the docs

Five capabilities, one identity

Everything an agent needs to operate.

How it works

From signup to verifiable identity in four steps.

Identity is more than a name. Mailgent binds an email address, a signing key, a credential vault, a calendar, and an optional human anchor into one entity any system can verify.

01

Create an identity

Open the Mailgent console, click new identity, pick a name. Mailgent provisions a unique email address, an Ed25519 signing keypair, a credential vault, and a calendar — all addressable through one project API key.

02

Bind capabilities to scopes

Each capability (Mail, Vault, 2FA, Calendar, KYC) is gated by an explicit scope. The same project key can sign emails as the agent without granting the right to spend USDC — least-privilege by default.

03

Agent acts; everything traces back

Outbound email carries the agent's DID in the headers and is DKIM-signed by Mailgent. Vault reads write audit entries. Calendar events expose a public ICS URL. The activity log records every action across surfaces.

04

Counterparties verify the identity

Any system that reads a Mailgent-signed receipt, an Agent Card at /.well-known/agents/:id, or a DKIM-signed email can verify the agent's identity without calling Mailgent — the verification material is in the identifier.

Trust on the open internet

Built on standards counterparties already trust.

DKIM + DMARC for email

Every outbound message is DKIM-signed by mailgent.dev with SPF and DMARC configured for maximum deliverability. Receivers trust the sender on the first send.

Ed25519 signing keys

Modern elliptic-curve signatures over RSA. Compact, fast, and verifiable offline. The public identifier itself is the verification key — no registry lookup.

W3C DID + A2A Agent Cards

Every identity is addressable as did:web:mailgent.dev:agents:* and publishes an Agent Card at /.well-known/agents/:id. Compatible with the broader agent interop standards.

Unified activity timeline

Every email send, vault read, calendar update, and signature lands on one timeline keyed on the identity. Filterable, exportable, and the same shape compliance teams already use.

What people build

Identity is the substrate. Here's what sits on top.

Frequently asked

Things builders ask about Mailgent Identity.

What exactly is a Mailgent Identity?
It is a single entity — addressable by email, by DID, and by project API key — that owns a set of capabilities (Mail, Vault, 2FA, Calendar, optional KYC). Every action an agent takes traces back to that identity, and the identity itself traces back through a delegation chain to a verified human.
Why anchor agent identity to email?
Because email is the only universal addressing system already deployed on every system on earth, backed by 40 years of DKIM, SPF, and DMARC trust infrastructure. Re-using that PKI is far better than asking the industry to adopt a new identifier format from scratch.
Is this the same as OIDC-A or A2A Agent Cards?
Mailgent Identity is compatible with both. Each Mailgent Identity publishes an Agent Card at /.well-known/agents/:id in the A2A format, and tokens issued via the OAuth 2.1 endpoint carry OIDC-A claims (agent_model, agent_provider, delegator_sub, agent_capabilities). You do not have to pick.
Do I need all five capabilities to start?
No. Capabilities are independent and scope-gated. An identity that only sends email never touches Vault or KYC. Toggle them on per project as the agent's use case grows.
How is the signing key protected?
Each project's Ed25519 signing key is encrypted at rest with VAULT_MASTER_KEY and only ever used inside the Mailgent API surface — never exposed through any endpoint. Recipients verify signatures against the public identifier without contacting Mailgent.
Can I use my own domain for agent email?
Custom domains are on the roadmap. Today every project ships with an address on mailgent.dev, with deliverability configured out of the box. When custom domains land, the same identity can keep its existing mailgent.dev address as an alias.
What happens when I revoke an identity?
Revoking the identity invalidates the project API key, rejects subsequent signing requests, and pauses outbound email. Existing signed receipts and emails remain verifiable (the signature is mathematical, not policy) — but no new signatures, mail sends, or vault reads will succeed.
How does delegation work?
Every identity tracks the delegator (the human or org that authorized it). Tokens issued for downstream agents can only attenuate scopes — never widen them. Revoking the human cascades to every agent created under them. The full delegation chain ships in every JWT and every Agent Card.

One identity. Every surface.

The same identity that sends email also signs payment receipts, authorizes Vault reads, and gates the optional KYC. Build one agent on the open internet — not five disconnected accounts.

Start a project →
See pricing