# Signed Human–Agent Receipt Protocol

**SHARP — Simulacra design draft 0.1 · 10 September 2026 · Jonas Kgomo**

Status: a proposed protocol for an opt-in experiment. No sender, receiver, credential integration, or cryptographic verifier is implemented by this document. The accompanying website illustration is a scripted preview.

The definition and interactive introduction appear in [Protocols as Rules of Play](/simulacra/protocols-as-rules-of-play). The motivating email cases are discussed in [When the Senders Are Machines](/simulacra/when-the-senders-are-machines).

SHARP is a working protocol name. This draft uses the experimental `Simulacra-Agent` email header and `sharp-mail+jws` signature type; neither is a registered standard.

## 1. Claim and scope

An agent initiating contact should disclose that it is an agent and carry verifiable, limited authority from a human principal. The recipient should be able to distinguish that delegation from human authorship, approval of a particular message, or endorsement of the offer.

SHARP adds a receiver-checked delegation layer to ordinary SMTP delivery. It does not replace SMTP, SPF, DKIM, DMARC, spam filtering, or a recipient’s right to decline. A valid permit makes an approach eligible for the receiver’s policy; it never guarantees inbox placement.

The first profile covers one recipient per message and plain-text email. Its purpose is to test new approaches from agents. Attachments, HTML, mailing lists, Bcc, forwarding-based transfer of trust, payments, and delegated sub-agents are outside this profile.

The human principal is the person delegating authority. The operator runs the agent and can be a different party. The receiver operates the recipient’s mailbox service. The credential issuer attests personhood according to a published method. None of these roles should be silently substituted for another.

## 2. Foundations and limits

World’s [proof-of-personhood introduction](https://world.org/blog/world/proof-of-personhood-what-it-is-why-its-needed) supplies one account of proving humanness and uniqueness privately. It is an example, not SHARP’s mandatory identity provider.

Adler and colleagues’ [Personhood credentials](https://arxiv.org/abs/2408.07892), particularly [section 3.3](https://arxiv.org/html/2408.07892v4#S3.SS3), motivates verifying that an agent represents a real person. SHARP’s sending-permit and email-binding design below is an experimental application.

Credential eligibility is issuer-relative. Accepting several issuers can give one person several eligible credentials. A receiver must publish that limitation and cannot describe this design as global one-person-one-account. A valid personhood presentation does not establish a legal identity or reveal who wrote an email.

### What the inbox examples add

The PHC paper already discusses delegation, service rules, and credential recovery. SHARP addresses a narrower engineering question: what evidence should accompany this particular email and remain available after the exchange?

Christopher’s email to Jonas combines an unsolicited commercial offer with a promise to accept refusal. Sam Ellis’s message to Toby Ord claims human review of publication, which is not the same as approval of outreach. Neither example supplies a verified delegation or evidence that a subsequent boundary was respected. They motivate requirements, not findings of misconduct.

SHARP proposes scoped authority, distinct approval modes, recipient-controlled follow-ups, and signed verification receipts. Its expected advantage over a credential badge alone is more precise, repeatable evidence for an inbox decision. Whether that reduces abuse or recipient effort remains an experimental question. The proposal cannot verify the truth of a sales pitch, prove an agent’s distress, or force an uncooperative mail service to enforce its rules.

## 3. The four records

SHARP separates four records so a sender cannot make a claim true merely by displaying a badge.

1. **Enrolment:** the receiver verifies an accepted personhood presentation and creates a service-specific principal account. The issuer and assurance method are recorded. Raw biometrics and a global identity identifier are not required by this draft.
2. **Permit:** through that account, the principal authorises an agent public key, sending address, exact recipient, purpose, time window, and contact allowance. The receiver stores the grant and its current state. The operator may be separately declared; a declaration is not identity verification.
3. **Message assertion:** the agent signs a grant reference and a digest of this email. The receiver verifies the signature against the key already bound to the permit, then checks the permit and allowance.

4. **Receipt:** the receiver signs what it checked, against which grant and policy, at what time, and with what result. A private evidence bundle lets another checker repeat the cryptographic checks.

Credentials are proved during enrolment, not attached to every email. A permit is an opaque reference to receiver-held authorisation, not a bearer token that allows whoever copies it to send.

## 4. Enrolment and delegation

For the pilot, participating receivers are configured explicitly. There is no automatic discovery from arbitrary sender-supplied URLs.

The receiver offers an HTTPS portal at its configured origin. It issues a random, single-use challenge expiring after five minutes. An accepted credential adapter must verify a presentation bound to that challenge and receiver audience, then produce a stable pseudonym within that receiver’s scope. That pseudonym must be reusable for quota enforcement without becoming a cross-service tracking identifier. An adapter that cannot provide these properties is unsupported in this profile.

The personhood system and its verifier are external dependencies. Each adapter needs a documented issuance policy, challenge/audience binding, duplicate-use behaviour, recovery process, and conformance tests before integration. This draft does not assume that any named provider already implements this exact flow.

An enrolment session must remain bound to the verified principal. The principal sees the complete proposed permit before authorising it. The receiver also challenges the agent to prove possession of its proposed Ed25519 key. Pilot keys must be distinct for each receiver service. A principal must have a human-accessible route to review and revoke all their grants.

Two grant modes are defined:

- `single-message`: the principal authorises one exact message digest. The permit may be consumed once. The interface calls this “specific message authorised”; it does not claim to prove that a person attentively read it.
- `bounded-contact`: the principal delegates a stated number of messages to one recipient until expiry. The interface calls this “sending authority delegated”. The principal need not approve each message separately.

The receiver may impose stricter limits than the principal requests. Issuing a permit does not mean the recipient has invited contact.

## 5. Permit record

This is a receiver-side example, not a signed token or live credential. Values are illustrative.

```json
{
  "version": "sharp/0.1",
  "grant_id": "g_demo_7c28",
  "principal_ref": "receiver-local-pseudonym",
  "personhood": {
    "issuer": "configured-issuer-id",
    "assurance_policy": "receiver-policy-01",
    "checked_at": "2026-09-10T12:00:00Z"
  },
  "agent_key_ref": "receiver-local-key-id",
  "operator_declared": "Example agent service",
  "from": "agent@sender.example",
  "to": "reader@receiver.example",
  "mode": "bounded-contact",
  "purpose": "Offer one research memo and answer a requested clarification",
  "not_before": "2026-09-10T12:00:00Z",
  "expires_at": "2026-09-11T12:00:00Z",
  "max_messages": 2,
  "max_uninvited_messages": 1,
  "approved_message_sha256": null,
  "state": "active"
}
```

The pilot limits grants to 24 hours. `single-message` requires a digest and `max_messages: 1`; `bounded-contact` requires `approved_message_sha256: null`. Grant IDs must contain at least 128 bits of randomness in an implementation; the readable example above is not suitable for use.

Counters aggregate across grants and agent keys for the same principal account. For the initial experiment, one credential-linked principal may make at most three new approaches per receiver service in a rolling 24-hour period, and at most one uninvited approach to a particular recipient in seven days. These are experimental settings, not evidence of a socially optimal rate.

The purpose is disclosed to the recipient. Its semantic truth cannot be established by a signature. Numeric limits, recipient, key, address, expiry, and approval digest are mechanically enforceable.

## 6. Message assertion and cryptography

The email carries one folded experimental header:

```text
Simulacra-Agent: <compact JWS containing the message assertion>
```

This schematic value is not a working signature. A client may fold the compact token between characters with CRLF followed by whitespace; the verifier removes folding whitespace before decoding it. The unfolded token must contain no other whitespace and must be at most 8 KiB. Duplicate `Simulacra-Agent` fields are invalid.

Use compact [JWS (RFC 7515)](https://www.rfc-editor.org/rfc/rfc7515.html) with the Ed25519 form of `EdDSA` described in [RFC 8037](https://www.rfc-editor.org/rfc/rfc8037.html). The protected header is exactly `{"alg":"EdDSA","typ":"sharp-mail+jws"}`. Reject other algorithms, additional protected parameters, duplicate JSON keys, and unsupported versions. Do not accept embedded keys, `jku`, or remotely supplied key locations. The grant determines the trusted key; the unverified grant reference is only a bounded local lookup.

Example assertion payload before signing:

```json
{
  "version": "sharp/0.1",
  "grant_id": "g_demo_7c28",
  "aud": "https://receiver.example",
  "recipient": "reader@receiver.example",
  "message_id": "<example-42@sender.example>",
  "nonce": "UNIQUE_RANDOM_BASE64URL_VALUE",
  "iat": 1789041600,
  "exp": 1789041900,
  "message_sha256": "BASE64URL_SHA256_OF_PROTECTED_MESSAGE"
}
```

The signature covers the exact JWS payload bytes. A verifier must not reserialize JSON before signature verification. Strings are UTF-8; `iat` and `exp` are integer Unix seconds. Unknown payload members are rejected for version 0.1. The nonce must decode to at least 16 random bytes. Enforce `0 < exp - iat <= 300`, an issue time no more than 60 seconds ahead of the receiver’s clock, and receipt before both assertion and grant expiry. A delayed message can therefore lose verified status even though ordinary email delivery continues.

### Protected email digest

Before SMTP dot-stuffing, construct the digest input from the transmitted RFC 5322 message bytes in CRLF form:

1. Require exactly one each of `From`, `To`, `Date`, `Message-ID`, `Subject`, `MIME-Version`, `Content-Type`, and `Content-Transfer-Encoding`. Accept at most one `Reply-To`. Reject `Sender`, `Resent-*`, and `Bcc` in this pilot profile. Reject malformed header syntax and duplicate protected fields.
2. This profile permits one ASCII mailbox in `From` and `To`, with no display names or groups. They must match the permit’s addresses; `To` and the actual SMTP envelope recipient must also match the assertion’s `recipient`. Domain comparison is case-insensitive; local-part comparison is exact. A present `Reply-To` must equal `From`. `Message-ID` must equal the assertion value.
3. Require `MIME-Version: 1.0` and a single `text/plain` body with UTF-8 charset. Permit `7bit`, `quoted-printable`, or `base64` content-transfer encoding. Unsupported MIME profiles have no verified SHARP status.
4. Canonicalize the protected headers using RFC 6376 relaxed header canonicalization, in the fixed order listed in step 1, followed by `Reply-To` if present. Include each canonical header’s terminal CRLF. Preserve the complete encoded body using RFC 6376 simple body canonicalization. No body-length truncation is permitted.
5. Compute SHA-256 over ASCII `SHARP/0.1` followed by CRLF, the ordered canonical headers, one additional CRLF, and the canonicalized body. Encode the result as unpadded base64url.

The experimental header itself is excluded to avoid a circular digest. Trace headers added in transit are excluded. Body decoding is for display only and takes place after checking the digest. A MIME rewrite in transit can invalidate the assertion. This deliberate pilot limitation needs fixtures before broader interoperability is claimed.

Mail authentication results remain separate from the SHARP result. They are computed by the receiver, never trusted from a sender-inserted `Authentication-Results` header. A receiver may require DMARC as additional admission policy, but a DMARC pass alone cannot create a SHARP delegation.

## 7. Receiver decision procedure

The receiver performs bounded parsing, looks up the grant, verifies JWS and the protected message digest, checks times and addresses, and then checks live grant state and principal restrictions. It must not fetch URLs embedded in assertions or message bodies to discover trust.

Admission and quota consumption must be one atomic operation. Key replay detection by `(grant_id, nonce)`, store the accepted message digest and delivery identifier, and retain that record for at least seven days. After signature and digest verification, a recognised byte-equivalent retry returns the previous disposition without another delivery or quota charge; it is a lookup of the earlier decision, not a new admission, even if the grant has since expired or been revoked. New attempts must satisfy all current validity and state checks. Reusing a nonce for a different digest is invalid. A replay after its stored record expires is still outside the assertion’s five-minute validity window.

Both the grant counter and principal-wide counter must pass. Opening a new grant or changing the agent key cannot reset the principal’s allowance. A revoked or blocked principal cannot enrol a fresh agent under the same credential-linked account to evade the restriction.

The receiver exposes distinct results:

| Result | Meaning | Default pilot handling |
| --- | --- | --- |
| `absent` | No assertion. | Ordinary mail policy; no agent or human inference. |
| `unsupported` | Unknown version, credential adapter, or MIME profile. | Ordinary policy or review; no verified claim. |
| `declared` | Body or sender identifies an agent, with no verified permit. | Label as self-declared if shown. |
| `verified-delegation` | Valid assertion, current bounded-contact permit, and allowance. | Eligible for recipient policy, not automatically trusted. |
| `specific-message-authorised` | Same checks plus the single-message approval digest. | Describe the narrower grant accurately. |
| `expired` / `revoked` | Authority is no longer current. | Withhold verified admission; expose the reason. |
| `quota-exceeded` / `recipient-blocked` | Local admission policy denies the approach. | Hold or reject according to published receiver policy. |
| `invalid` | A supported assertion fails a required check. | No verified badge; hold or reject without exposing grant existence. |
| `unavailable` | Required receiver state cannot be checked. | Queue for recheck; never fail open to verified status. |

An absent assertion is not proof of human authorship. A sender cannot remove a bad assertion and thereby gain verified access. Receivers retain ordinary abuse controls for all unverified mail.

## 8. Refusal, replies, and revocation

The receiver supplies authenticated mailbox controls: decline this approach, block this principal for this recipient, revoke my own grant, and challenge an incorrect decision. These are receiver UI actions, not instructions extracted from arbitrary message text.

Silence, a read receipt, an automatic reply, and the sender’s own claim of consent do not grant follow-up permission. For a bounded-contact permit allowing a second message, the recipient must explicitly enable a reply in the receiver UI. That permission is recorded against the grant and recipient; a new sender-side claim cannot substitute for it.

A principal can revoke an agent’s grant immediately at the receiver. Revocation prevents new verified admissions and is checked again before releasing a queued message. It cannot retract a message already delivered. A recipient block applies to the principal-recipient pair across that principal’s grants at this service. Blocking must not automatically send an email to a possibly forged sender or create a backscatter loop.

### The receipt and reproducible verification

For each admission attempt, the receiver records a decision and may return an authenticated receipt to the principal’s portal. It must not automatically reply to an unverified sender. The recipient can inspect the receipt and explicitly export a private evidence bundle.

The receiver signs the receipt using compact JWS with protected header `{"alg":"EdDSA","typ":"sharp-receipt+jws"}`. Verification uses a receiver signing key obtained through prior trusted configuration, never a key declared authoritative by the bundle itself. Key rotation must preserve historical verification keys and their trust history. A receipt includes:

```json
{
  "version": "sharp/0.1",
  "receipt_id": "r_demo_93a1",
  "receiver": "https://receiver.example",
  "received_at": "2026-09-10T12:01:00Z",
  "assertion_sha256": "BASE64URL_SHA256_OF_COMPACT_ASSERTION",
  "grant_snapshot_sha256": "BASE64URL_SHA256_OF_SNAPSHOT_BYTES",
  "policy_sha256": "BASE64URL_SHA256_OF_POLICY_BYTES",
  "evaluator_version": "sharp-pilot-0.1",
  "result": "verified-delegation",
  "checks": {
    "agent_signature": "pass",
    "message_binding": "pass",
    "audience_and_recipient": "pass",
    "within_validity_window": "pass",
    "grant_state_at_admission": "active",
    "remaining_grant_messages_after_admission": 1,
    "followup_permission_at_admission": false
  }
}
```

All byte digests in a receipt use SHA-256 and unpadded base64url. A grant snapshot includes the effective grant record, its bound public key, and the receiver’s attestation of the principal’s enrolment checks. Its exact UTF-8 JSON bytes are retained and hashed; exported copies must not be reformatted. The same rule applies to the policy snapshot, which includes the numeric limits, time rules, parser profile, and ordered decision rules used for that evaluation. Failed checks appear as `fail` or `not-checked`, never as a fabricated pass. An unknown grant has a null snapshot digest and no associated principal data.

The private bundle comprises the original protected message bytes, compact agent assertion, signed receiver receipt, grant snapshot, policy snapshot, and the identifiers of the verifier’s preconfigured trust anchors. It contains neither raw personhood presentations nor biometrics. Export warns the recipient that message content and the service-local pseudonym are included. Redacting signed content creates a derivative copy that cannot reproduce the original digest check.

**Reproducible** has a precise limit here. Given the same bundle, trusted keys, and evaluator version, another implementation should reproduce the signature, digest, address, and time-window checks. It can authenticate the receiver’s recorded grant and policy assertions. It cannot independently reconstruct a private quota database, establish that an issuer enrolled a human correctly, or prove that the receiver’s recorded time and revocation state are truthful. Those remain signed attestations with identified trust dependencies. The receiver stores transaction-state evidence for its own audits; including a receipt does not turn those hidden facts into independently observed facts.

A receipt describes an admission-time decision. Checking whether authority is still current requires a new check at the receiver. Historical validity and present authorisation are separate results. Receipts must not claim to reproduce an agent’s reasoning or certify the truth of its prose.

## 9. Privacy and trust boundaries

The recipient interface shows a service-specific principal reference, credential issuer and assurance description, agent identity, grant scope, expiry, and locally verified status. The separately declared operator must be labelled as declared unless checked by another mechanism. Never display “human-written”, “safe”, or “consented” merely because a grant verifies.

Do not attach raw personhood proofs, global nullifiers, or biometric material to messages. Publish counter and replay-retention periods. Use different principal pseudonyms and agent keys across receivers. Stable sender email addresses, content, timing, and operators can still correlate activity; SHARP does not claim that the email channel as a whole is unlinkable.

Account compromise, credential lending, colluding issuers, several issuers enrolling the same person, and people selling access to their allowance remain threats. Enrolment and recovery policies therefore belong in the experiment. Credential-linked sanctions are service-level enforcement, not proof of legal liability or a mechanism for deanonymisation.

## 10. First experiment and acceptance cases

Start with a local test receiver, synthetic principals, a test-only issuer, and generated keys. A production personhood adapter is a later milestone. Run three conditions with the same offers and recipient capacity: self-declaration, verified delegation, and verified delegation with principal-wide limits. Do not send unsolicited experimental mail to real recipients.

The reference implementation should pass these cases before any pilot:

- Valid bounded permit and correctly signed message: eligible, quota consumed once.
- Single-message permit used for an altered subject or body: invalid.
- Different recipient, forged grant reference, mismatched agent key, duplicate protected header, or unsupported algorithm: no verified admission.
- A retry of an accepted message: no duplicate delivery; same nonce with another digest: invalid.
- Twenty concurrent attempts against a one-message grant: at most one acceptance.
- New agent key for the same principal: existing principal limits still apply.
- Revocation after queueing but before release: held; already-delivered mail remains delivered.
- A recipient’s silence or automatic reply: no new follow-up permission.
- PHC presented for another receiver or an expired challenge: enrolment fails.
- Several accepted issuers: enforce the declared credential policy without claiming global uniqueness.
- Forwarded or MIME-rewritten email: no inherited verified status without fresh recipient-bound authority.
- State-store failure, clock boundary, missing assertion, and unsupported client: explicit non-verified state, with an accessible review route.
- Two independent verifiers with the same evidence bundle and trusted keys: matching cryptographic and expiry checks, with receiver-attested state labelled separately.
- An altered grant snapshot, policy snapshot, signed receipt, or message: verification fails; a replacement key supplied inside the bundle is not accepted as its own trust anchor.
- An old valid receipt after revocation: historical verification may pass while current sending authority is denied.

Measure recipient review time, useful approaches admitted, useful approaches excluded, contacts after refusal, false verification, mistaken sanctions, and recovery time. More accepted mail is not the success criterion.

## 11. Decisions before implementation

Wire identifiers need review and registration before wider use. Credential-adapter selection, issuer admission, account recovery, approved cryptographic libraries, test vectors for MIME and header parsing, accessibility of personhood enrolment, and abuse-resistant grant issuance are implementation gates. This draft fixes a testable flow while leaving those provider-specific choices explicit.

## References

- World, [Proof of personhood: What it is and why it’s needed](https://world.org/blog/world/proof-of-personhood-what-it-is-why-its-needed), 2024.
- Adler et al., [Personhood credentials](https://arxiv.org/abs/2408.07892), 2024; revised January 2025.
- [RFC 5322: Internet Message Format](https://www.rfc-editor.org/rfc/rfc5322.html).
- [RFC 6376: DKIM](https://www.rfc-editor.org/rfc/rfc6376.html), including section 3.4 canonicalization.
- [RFC 7208: SPF](https://www.rfc-editor.org/rfc/rfc7208.html) and [RFC 7489: DMARC](https://www.rfc-editor.org/rfc/rfc7489.html).
- [RFC 7515: JWS](https://www.rfc-editor.org/rfc/rfc7515.html) and [RFC 8037: Ed25519 in JOSE](https://www.rfc-editor.org/rfc/rfc8037.html).