Your assistant drafts. You decide.

Connect a helper

Sign in to your human mailbox, open Approvals → Helpers, and create a draft-only key. Choose its name, sending addresses, expiry and optional exact recipients. Save the one-time secret in your assistant’s secret store. Existing two-factor authentication also protects key creation and revocation.

This exclusive mail:draft key cannot read your inbox, send directly, pay, manage domains or use SMTP/IMAP. Agent account keys and mail read/send keys cannot propose into someone else’s mailbox. You do not need to create another account.

Propose over REST or MCP

Use a descriptive User-Agent. Generate a UUID v4 for each new proposal, and reuse that UUID and the identical message after a timeout. An uncertain edit should be checked with GET before retrying.

curl https://keykeeper.world/api/v1/agent/drafts   -H "Authorization: Bearer $KEYKEEPER_DRAFT_KEY"   -H 'Content-Type: application/json'   -H 'User-Agent: MyApprovalHelper/1.0'   -d '{"clientKey":"d2fae809-ea94-4374-b1c9-934e5f787552","message":{"to":"[email protected]","subject":"For your review","body":"Here is the proposed message."}}'

The response contains id, revision, contentHash, state and expiresAt. GET /api/v1/agent/drafts lists only this key’s proposals; GET /api/v1/agent/drafts/ID returns its current version or status. Poll at a reasonable interval, such as 30 seconds.

PATCH /api/v1/agent/drafts/ID with action: edit, the current revision and contentHash, and the complete replacement message. Use action: withdraw with the same version fields to withdraw it. Once the human saves an edit, the helper cannot edit, withdraw or read the revised message.

MCP exposes propose_email, list_proposals, get_proposal and update_proposal with the same key and rules. There is no agent approval tool. See OpenAPI for exact request schemas.

Review the exact message

The owner can edit From, To, Cc, Bcc, subject and plain-text body, inspect or remove attachments, and then save and approve. Owner edits may use other authorized mailbox identities or recipients because the owner is authorizing the final message. An approval includes the reviewed revision and SHA-256 content fingerprint. If the agent changed it, approval stops and asks you to reload.

Approval queues that version with 20-second Undo Send. Usual draft allowances, sender ownership, quotas, account security and abuse controls still apply. A revoked or expired helper key blocks pending approvals. Revoking a key after approval does not cancel mail already authorized by you; use Undo Send while available.

approved means the owner authorized the message. Inspect submission.status for held, sending, accepted, failed, unknown or cancelled. SMTP acceptance does not prove inbox delivery. Never create another proposal to retry an unknown submission. Humans can check Sent or the existing draft.

Scope and retention

Plain-text bodies up to 1 MiB, at most 20 inline base64 attachments totaling 8 MiB, and valid In-Reply-To/References headers are supported. HTML and encrypted proposals are not supported in this review flow yet. Treat agent text and files as untrusted content; download files only when you intend to inspect them.

Up to 20 pending proposals per mailbox, 30 writes/hour and 120 reads/minute. Proposals expire after seven days or when their key expires, whichever comes first. Bodies and files use authenticated server-side encryption, not end-to-end encryption. On approval, the frozen message moves into the regular send queue; on rejection or withdrawal its proposal body is removed. Hourly cleanup removes expired bodies, seven-day summaries and 90-day decision metadata. Encrypted backups follow their separate retention policy.

The decision history records the helper key, revision, content fingerprint and time. It does not retain a second copy of the approved message body. Human-edited content is never returned to the helper.