SecureStamp Trust Protocol

SPF verifies that an IP is authorized to send on behalf of a domain. DKIM verifies message integrity and domain association. DMARC ties them together with a policy. But none of these standards prove that a payment instruction, credential request, vendor change or agent action matches a declared counterparty policy.

A domain can pass all three checks and still carry a manipulated request, a compromised workflow, a lookalike counterparty, or a message generated by AI that pressures a human or agent into acting too quickly.

Humans and agents need a reliable signal at the instant before action: click, reply, approve, pay, share credentials, update records or execute an automated workflow. Without a shared protocol, the burden falls on discipline, manual callbacks and visual judgment.

An organization registers domains, senders, official channels and counterparty policies at securestamp.online. Registration creates verifiable records anchored on the audit ledger and scoped to the tenant or public perimeter as appropriate.

DNS TXT record — the domain publishes a TXT record at _securestamp.example.com containing the stamp ID and verify URL. This is the most robust channel as it is controlled by the domain owner and queried independently of private message body.

HTTP header — mail servers add an X-SecureStamp SMTP header to outgoing messages. This requires mail server configuration but provides per-message verification with a signed JWT payload.

API registration — organizations register channels, counterparties and action policies with SecureStamp directly, enabling real-time verification lookups without DNS propagation delays.

When a plugin, verifier or agent encounters a message or requested action, it queries POST /api/trust/check or the Action Verdict API with the origin, domain, channel, abstract risk signals or source hash. The API returns a structured trust response, Safe Next Step or signed receipt without requiring raw message content.

Signals and the notarial layer resolve to a five-level scale. The scale grades the strength of verifiable origin evidence, and it is monotonic: each level adds something a verifier can recompute. It is not a risk score, and a level is never a verdict — a legitimate origin can still request an action that requires review.

• L1 — Registered · Declared originThe domain or organization is registered in SecureStamp and its perimeter is declared.
• L2 — Aligned · Technical floorTechnical signals such as SPF, DKIM, DMARC or DNS are aligned. The most a commodity check can assert.
• L3 — Signed · Signed tokenThe message, channel or event carries a signed, verifiable token bound to the registered origin.
• L4 — Notarized · Integrity referenceA verifiable integrity reference or receipt exists for later audit of the covered envelope.
• L5 — Certified · Notarial match + KYBThe origin or message envelope matches a notarial record issued by a registered identity with an approved business-identity (KYB) check. Certifies origin and envelope integrity — nothing about the truth of the content.

Degraded, suspicious and failing states are a separate axis. They belong to the verdict a decision surface produces, not to the evidence ladder, and earlier drafts of this document conflated the two.

An issuer registers a notarial record at issue time. The record is an ES256-signed attestation over a canonical hash of the message envelope — sender, ordered recipients, and subject — never the body. The recipient's client recomputes the same canonical hash and asks POST /api/verify/email to compare it against the signed record, yielding one of certified_match, token_valid_hash_mismatch, token_invalid or not_registered.

Forgery resistance rests entirely on the signing key, not on secrecy of the scheme: without the issuer's private key an attacker cannot mint a valid record, and altering any covered field changes the hash and breaks the match. Signing keys are rotated and the corresponding public keys are published as a JWKS set (key-id pinned), so any party can verify a signature — current or recently rotated — without trusting SecureStamp at run time.

L5 certifies that a message or origin matches a registered issuer and that its covered envelope is intact. It makes no claim about whether the content is true or whether a requested action should execute without context. This boundary is a deliberate, non-negotiable property of the protocol.

A notarial match alone reaches the certified band only when the issuing organization has passed a business-identity (KYB) review. Until identity is approved, an otherwise-perfect notarial match is capped at L4. This binds the cryptographic claim (“this registered identity issued this record”) to a vetted real-world identity (“and we verified who that organization is”).

The SecureStamp audit ledger is append-only and records signed transparency entries for stamp issuance, revocation, score changes and abuse events. The production storage model is designed for deterministic reads, tamper-evident hashes and independent verification without exposing private message content.

Every stamp issuance, revocation, and score change is written to the ledger as an immutable transaction. Ledger entries contain only stamp IDs and cryptographic hashes — never personal data or message content.

Any party can independently verify a stamp's authenticity and history by querying the public ledger endpoint at GET /v1/ledger/tx/:txHash.

Five records, each signed by a different party, each binding the next by digest:

1. Source Envelope. The client plugin signs what the human actually saw, on the device, with a key that never leaves it. Message bodies are never transmitted.
2. Action Effect. The Guardian — not the model — reads provider state and normalizes the exact effect: provider, operation, resources, parameters and a digest of the prestate.
3. Execution Grant. SecureStamp Cloud signs a single-use grant bound to that effect digest, to the authority that approved it and to an expiry. maxUses is always 1.
4. Execution Claim. The Guardian claims the grant against its own ledger. A replayed grant is rejected before any provider is contacted.
5. Action Receipt. The Guardian signs the outcome as succeeded, failed_no_effect or indeterminate.

The third outcome is deliberate. When a provider accepts a mutation and the response is lost, the honest answer is that the result is undetermined until reconciliation resolves it. Rounding that up to success is how duplicate executions enter an audit trail.

The authority an operation demands is fixed by the protocol. The caller cannot choose it, the model cannot argue for it, and it cannot be downgraded inside the request that needs it.

human_mfa requires a named human approving against a live MFA session. quorum requires M-of-N independent approvers, each with their own MFA session, against a policy the organization set in advance; the requester can never approve their own request. Every grant of privilege — in any cloud — requires quorum.

Any privilege attribution executed through a Guardian requires M-of-N quorum and is bound cryptographically to the exact principal, role, scope, prestate and outcome.

SecureStamp authorizes; the customer executes. The Execution Guardian is a daemon the customer runs inside their own network, holding their own provider credentials. SecureStamp never receives those credentials and never calls the customer's provider.

Credentials are mounted as root-owned files rather than environment variables or inline configuration. The MCP bridge — the process closest to the model — holds no credentials and links no cloud SDKs. The effect is resolved from state the daemon reads itself, never from parameters the model supplied, and the prestate is re-read immediately before the mutation so that a material change invalidates the grant instead of overwriting it. A timeout is reconciled by reading the provider back; the daemon never blind-retries a mutation.

Each connector is a separate module with its own manifest, its own least-privilege credential and its own certification evidence. Adding one does not alter the manifests or the evidence of the others.

Cloud IAM surfaces differ in ways the protocol has to absorb rather than hide. Google Cloud replaces an entire policy under an etag, so the Guardian preserves the full policy, applies exactly one binding delta, and fails closed when the etag moved. Azure names each role assignment with a GUID, which the Guardian derives from the grant identifier so that a retry of the same grant can only ever produce the same resource. Entra assignments are issued as temporary schedule requests and are not reported as successful until the assignment is observed active.

A grant from SecureStamp Cloud is necessary to execute, and it is never sufficient on its own. The Guardian also enforces a GuardianLocalPolicyV1 document that the customer signs with its own P-256 key and installs beside the daemon. The effective permission is an intersection:

effective permission =
      cloud grant
    ∩ signed local policy
    ∩ adapter constraints
    ∩ kill switches

The local policy pins tenant and gateway, the operations allowed and the exact adapter manifest digest for each, the authorities and policy versions it will accept, resource and parameter rules, monetary ceilings and daily quotas, concurrency and permitted network destinations. It is deny-only by construction: there is no field in it that can grant something the cloud did not. Running in production_opt_in without a valid signed policy is refused at startup rather than warned about.

Policies carry a mandatory reviewAfter date and an optional expiresAt. An expired policy blocks new mutations while leaving status, proof, readback and reconciliation intact. Recovery of the signing key is M-of-N and offline; SecureStamp support cannot substitute for that control, which is the point of it. Kill switches exist globally and per provider, operation, tenant and gateway, and again inside the local policy — they stop grants that were already issued, and they can only deny.

A compromised SecureStamp control plane still cannot exceed the authority a customer allowed locally. That is the property the local policy exists to provide, and it is the reason the policy is signed by the customer rather than by us.

Two artifacts carry the policy binding. ActionReceiptV3 adds policyVersion (apol_v1:<SHA-256 JCS> of the authorization-policy snapshot) and localPolicyDigest (gpol_v1: of the signed local policy). ActionProofBundleV2 carries the snapshots needed to recompute both hashes, together with the exact adapter manifest and the connector assurance descriptor.

ActionReceiptV2 remains byte-compatible and is never rewritten; history does not get retrofitted. Quorum profiles are policy snapshots rather than new authority values, so authority stays none, policy_delegated, human_mfa or quorum. A standard and an elevated profile both sign as quorum; what distinguishes them verifiably is the threshold, the approver roster and the resulting policy hash. A step-up selects the more restrictive snapshot available, or it holds — it is never a silent no-op.

Release order follows from this. The verifier is published as its own package, @securestamp/action-proof-verify, and a released verifier accepts a new receipt or bundle version before anything emits one. Adapter manifests are self-contained and immutable, and the verifier checks the manifest included in the bundle instead of regenerating it from the current registry, so adding operations or providers never invalidates historical proofs.

The six reference connectors are not the catalog. How a connector integrates and how much SecureStamp vouches for it are separate questions, and the protocol keeps them separate. A connector integrates as a certified adapter, as a declarative HTTPS adapter whose origin, method and path are fixed at install time, or through an SDK or sidecar over a Unix socket for protocols that cannot satisfy the declarative contract. Independently of that, its assurance is declared and signed as securestamp_certified, partner_attested or customer_defined.

Adapters translate an authorized effect into provider-specific execution. They do not redefine the authority granted: an adapter receives the normalized effect and an idempotency key, never the grant. This is what makes an open catalog defensible — a customer-defined connector can execute and prove its chain without SecureStamp ever claiming to have certified code it did not write.

After a timeout the daemon always reconciles. Positive confirmation resolves to succeeded, confirmed absence to failed_no_effect, and an unprovable result stays indeterminate. There is no blind retry of a mutation anywhere in the design.

An Action Receipt proves what passed through an enrolled Guardian and the outcome that Guardian could establish. It does not prove that no action occurred outside SecureStamp, and it does not establish legal ownership of a provider account. The evidence boundary is the enrolled execution path; actions performed outside that path are outside the scope of the receipt.

The protocol also declines several claims it could be mistaken for making. There is no hardware attestation of the Guardian host, no trusted execution environment, no zero-knowledge proof and no blockchain anchoring. Provenance provider_verified is reserved and not operational. Every guarantee in this section rests on signatures, canonical digests and a customer-controlled enforcement point — nothing else.

The verifier is a published package with no network access. It recomputes every digest and every signature in a proof bundle offline. Receipts issued today remain verifiable if SecureStamp is unreachable — or gone.

The protocol, the implementation and the verifier are complete and auditable today. The packages nevertheless ship on an explicitly unverified beta channel, and a beta Guardian refuses to start outside sandbox mode.

A connector is not called stable until published evidence covers 100 real executions against a live provider, including fault injection, replay rejection and proof that the credential could not have exceeded its allowlist — bound to the exact commit that produced them and to the digest of the connector module itself. If the manifest, the module or the execution core changes, the executions are repeated rather than reused.

A trust product that asks you to take its word for it has already failed. The release gate is public for the same reason the verifier is offline.

The default suite is SSCM-1: ECDH P-256 key agreement, HKDF-SHA256 derivation, and AES-256-GCM content encryption. A per-message key encrypts the body and is wrapped for each recipient via an ephemeral ECDH agreement, so recipient key identifiers stay opaque (Bcc is not leaked). All key generation and encryption happen on the client; private keys are non-extractable and never leave the device.

Senders publish only their public keys to a directory. Directory and preflight responses are themselves ES256-signed (verifiable via the same JWKS as the notarial layer), so a client can confirm it is encrypting to the genuine recipient key and not a substituted one. First-seen keys are pinned (TOFU).

Each message carries a sender signature (proof-of-possession) the recipient verifies against the directory, distinguishing a genuine sender from a replay. Users hold an individual recovery file, and organizations may hold a recovery key — both are client-side secrets SecureStamp cannot read. The mode is strict by design: if any recipient lacks an active key the client blocks the send rather than silently downgrading to plaintext. The suite is crypto-agile (SSCM-2 X25519, SSCM-3 post- quantum hybrid are reserved).

Each stamp contains an ES256-signed JWT payload anchored to the ledger. Copying a stamp image provides no benefit — the plugin verifies the signature at verification time, not the visual.

Plugins operate with minimal permissions. Chrome MV3 restricts background page access. Office.js sandboxes the plugin within the Outlook renderer. No plugin has access to the full email body in production mode.

All API keys are prefixed and hashed before storage. The system supports key rotation without service interruption. All mutation endpoints require valid JWT or API key authentication. Rate limiting is enforced at the Vercel WAF edge before reaching application code.