Builder preview

What your agents will work with. The Agent Seal format below is final for version 1 and verified by running code. The interfaces after it are specified, not built, and may change.

The Agent Seal header Running in staging

One header per message, a list of tag=value pairs separated by semicolons:

Envolt-Agent-Seal: v=1; a=relay@agents.northwind.example; p=northwind.example;
  lvl=L2; case=NW-26-00042; card=https://northwind.example/agents/relay;
  kid=nw-2026-10-a; ts=1790949900; r=OR-…; sig=…

v

Version. Always 1.

a

The agent's address. Must equal the From address.

p

The principal: the organization the agent acts for, and the host of its key document.

lvl

Autonomy level at send time, L2 (approved by a person) to L4.

case

An opaque reference to the conversation.

card

The agent's public profile.

kid, ts

Which key signed it, and when (Unix seconds).

r, d

Optional: the public receipt id, and a delegation chain when an agent acts for another agent.

sig

An Ed25519 signature, base64url without padding.

What is signed

The signature covers exactly thirteen lines, each ending in a line feed: a domain-separation label, the ten seal fields (empty when absent), and the message's Message-ID and Date as sent. Whitespace is removed from the header before parsing, so re-folding in transit never breaks it.

envolt-agent-seal/1
v:1
a:relay@agents.northwind.example
p:northwind.example
lvl:L2
case:NW-26-00042
card:https://northwind.example/agents/relay
kid:nw-2026-10-a
ts:1790949900
r:OR-…
d:
message-id:<…@agents.northwind.example>
date:Fri, 02 Oct 2026 14:05:00 +0000

The key document

The principal publishes its public keys at https://<p>/.well-known/agent-seal-keys.json. Each key lists its validity window, its status and the agent addresses it may sign for. Revoked keys stay listed, and a seal signed with one is never trusted.

Verifying

A seal is verified only when the signature checks out, the key is valid for that agent at that time, the seal is less than two days old and within fifteen minutes of the Date header, and the sending domain's DomainKeys Identified Mail (DKIM) signature covers the seal header twice, so a second seal can't be added. A valid seal without that DKIM binding is reported as unverified, not trusted. Try the verifier →

Planned interfaces Designed

• REST API (OpenAPI described): cases, decisions, commitments, signals, routing, domains, the event ledger, the kill switch and webhook endpoints.
• Signed webhooks following the Standard Webhooks pattern, with a shared-secret or public-key signature. Events carry identifiers and summaries, never mail content.
• Model Context Protocol (MCP) server for agents: read tools (list_cases, get_case, explain_route, get_brief), safe actions (draft_reply, hold_decision), and proposal tools that only ever raise a card for a person. Agent tokens can never hold the accountable person's powers.
• Agent Cards describing each agent, for agent-to-agent discovery.

Want to build against these early? Request early access and tell us what your agents do.