A trust protocol for
exact-effect authorization.
SecureStamp extends digital trust from origin and intent to execution. Approved decisions become bounded execution authorities constrained by customer-controlled policy and followed by independently verifiable evidence.
Gmail, Outlook and Apple Mail, with origin evidence in the inbox
Official channels
WhatsApp, Telegram and the perimeter a brand declares
Agents and APIs
MCP tools, APIs and autonomous workflows
Protocol architecture
Trust before action. Evidence after execution.
One trust stack, applied across every surface.
SecureStamp is not an email checker with an agent feature bolted on. Origin, intent, execution authorization and execution evidence are four layers of one chain — and that chain runs the same way whether the instruction arrives in an inbox, in a messenger or through an MCP tool call.
SecureStamp extends trust from instruction to consequence.
Trust stack
Origin
Where did this come from? Domains, headers, signatures, declared identity and channel perimeter. Supporting evidence — necessary, and never the headline.
Intent
What is being asked? The requested action is read and stated first: pay, approve, hand over credentials, invoke a tool. An input signal, not a proof.
Execution Authorization
What exact effect may be caused? An approved decision becomes a bounded, single-use authority for one canonical operation under explicit constraints.
Execution Evidence
What authorization was consumed, and what outcome could the execution point establish? A signed receipt anyone can verify offline.
Applied across
Gmail · Outlook · Apple Mail
Official channels
WhatsApp · Telegram · declared perimeters
Agents
MCP clients and copilots
APIs
Direct integrations
Workflows
Automations and delegated services
Execution Authorization applies wherever authority is delegated to software, not only to AI agents. An automation, a workflow or a delegated service acting on someone else’s behalf raises the same question: what exact effect was approved?
Protocol thesis
The new perimeter is the action.
First we defended devices against malware and trojans. Then we defended inboxes against phishing. Now software acts on our behalf, and the question is no longer only what it may reach — it is what it may change.
Messages, events and prompts can trigger APIs, tool calls, workflows and digital money operations. SecureStamp proposes verifiable signals before a communication becomes an action.
Identity controls who can access a system. SecureStamp bounds the exact effect autonomous software is allowed to cause.
Four layers
Authentication establishes identity. Access control limits reach. Execution Authorization bounds the effect.
Authentication
Who or what is acting?
Access Authorization
What resources may it reach?
Execution Authorization
What exact effect may it cause?
Execution Evidence
What authorization was consumed, and what outcome could the execution point establish?
The fourth question is worded deliberately. An outcome that cannot be established stays indeterminate, and no layer of this stack pretends otherwise.
Where we sit
SecureStamp starts where the decision ends.
Identity, policy and approval systems decide whether an action should proceed. SecureStamp binds that approved decision to the exact effect that may be executed.
Decide
What should be allowed? Identity, policy engines, approvals and humans answer this.
Authorize
What exact effect is permitted? This is the layer SecureStamp adds.
Execute
Apply that effect within customer constraints, at a point the customer controls.
Verify
What authorization was consumed, and what outcome could the execution point establish?
SecureStamp does not replace identity, policy engines, approval workflows or provider APIs. It binds their approved decisions to exact executable effects.
SecureStamp provides verifiable signals and bounded authorizations. It does not replace internal policies, permissions, sandboxing, human approval or existing security controls.
Devices
The first modern perimeter was the device: malware, trojans, dangerous files and local behavior.
Inboxes
Then risk moved to messages: lookalike domains, fake links, attachments, payment urgency and impersonation.
Actions
Now an instruction can open tools, call APIs, process invoices, move data or prepare payments.
Trust checks
SecureStamp reads what a message asks for — pay, approve, hand over credentials, invoke a tool — and backs it with origin, channel and context evidence before a reply, a payment, a data transfer or a workflow.
Channel agnostic
A channel-agnostic standard
SecureStamp is not designed for one inbox, app or industry. The protocol organizes signals around origin, channel, declared intent and action. It can apply to email, messaging, QR, websites, invoices, tickets, APIs, agents and digital money operations.
Delegated authority
Wherever authority is delegated to software.
An agent, an automation, a workflow or a delegated service acting on someone else’s behalf all raise the same question. Access permission says what they can reach; it does not define the exact effect approved for this transaction.
MCP for agents
SecureStamp MCP Server
MCP is how AI applications reach tools, data and workflows. SecureStamp sits in front of that reach: software asks what an instruction is actually requesting, who the counterparty is and what exact effect it may cause — before anything runs.
SecureStamp authorizes; it never holds your downstream provider credentials. When an operation must genuinely execute, the signed grant travels to an Execution Guardian you run, and only that daemon touches the provider.
read_message_request(...)analyze_message_intent(...)verify_counterparty(...)get_safe_next_step(...)authorize_action(...)create_action_challenge(...)issue_action_receipt(...)get_source_envelope(...)request_execution_grant(...)get_execution_status(...)Conceptual flow
agent → read_message_request → analyze_message_intent → get_safe_next_step → request_execution_grant → Execution Guardian → ActionReceiptV3Signal Framework
SSF: SecureStamp Signal Framework
SSF organizes the requested action first, then content, origin, authentication, channel and context signals, to produce a simple, auditable output readable by humans, systems and agents.
Requested Action
Replying, opening, paying, transferring, approving, sharing data, invoking tools or running workflows.
Content Signals
Urgency, links, attachments, credentials, payment instructions and bank-account changes.
Origin Signals
Domain, organization, declared identity, sender.
Technical Signals
SPF, DKIM, DMARC, DNS TXT, headers, signatures, keys and receipts.
Channel Signals
Email, web, WhatsApp, Telegram, QR, API, support, billing and tickets.
Verdict Layer
Trust, Signal and Action Verdict: a readable, auditable output that states the requested action first and shows origin evidence beneath it.
Three input signals, then authorization
Proof of Origin answers where an instruction came from. Proof of Intent states what it is asking for. Action Verdict recommends whether it should proceed. All three are signals that feed a decision — and a decision is not yet an authorization.
Proof of Intent
What is being asked? An input signal that states the requested action first. It is not a proof of what was authorized.
Proof of Origin
Where did it come from? Domain, organization, channel, sender, stamp and technical signals. Supporting evidence.
Action Verdict
Should this proceed? A decision signal. What happens after that decision is Execution Authorization.
Execution layer
Public Beta · Production access controlledA verdict is not a proof.
A verdict can recommend whether an action should proceed. It does not by itself prove the exact effect that was authorized, the authority behind it, whether the authorization was reused, or the outcome observed at execution.
Action Proof creates that evidence chain. An approved decision becomes bounded executable authority: one exact effect, one authority, one expiry, one use — verifiable offline, by anyone.
Access is not authorization to act
Access controls what software can reach. Execution Authorization bounds the exact effect it may cause.
Resource authorization answers what a principal may access. Execution Authorization answers what transaction-specific effect it may cause. Fine-grained access still leaves the transaction itself undefined: which resource, which amount, which destination, how many times.
Authorize the effect, not just access to the tool.
Customer-controlled ceiling
Your policy is the ceiling.
SecureStamp Cloud can make an authorization narrower. It cannot make it broader than the policy your organization signed and installed locally. Cloud authorization is necessary, but never sufficient on its own.
Effective permission
effective permission =
cloud grant
∩ signed local policy
∩ adapter constraints
∩ kill switches- The local policy is a document your organization signs with its own key and installs beside the Guardian. It pins tenant, gateway, operations, adapter manifests, accepted authorities and policy versions, resources, parameters, monetary limits, concurrency and 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 mode without a valid signed local policy is refused at startup, not warned about.
- Kill switches exist globally and per provider, operation, tenant and gateway — and again inside the local policy itself. They stop grants that were already issued.
- Policies carry a mandatory review date and an optional expiry. An expired policy blocks new mutations while leaving status, proof, readback and reconciliation intact.
- Key recovery is M-of-N and offline. SecureStamp support cannot substitute for that control, which is the point.
- A compromised cloud control plane still cannot exceed the authority allowed locally.
Customer-hosted
We authorize. You execute.
The Guardian runs in your environment and holds the downstream provider credentials. SecureStamp Cloud does not receive downstream provider credentials and never calls your provider.
- Provider credentials are mounted as root-owned files, never environment variables and never inline configuration.
- No downstream provider credentials or cloud provider SDKs are required by the MCP bridge — the process closest to the model.
- The effect is resolved from state the daemon reads itself, never from parameters the model supplied.
- Prestate is re-read immediately before the mutation; a material change invalidates the grant instead of overwriting it.
Proof chain
Five links, each signed by a different party
Cryptographic proof of authorization. Signed evidence of execution outcome.
Source Envelope
The plugin signs what the human actually saw, on the device, with a key that never leaves it. Message bodies are never transmitted.
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.
Execution Grant
SecureStamp Cloud signs a single-use grant bound to that effect digest, to the authority that approved it, to the policy version in force, and to an expiry. maxUses is 1, always.
Execution Claim
Your Guardian claims the grant against its own ledger. A replayed grant is rejected before any provider is contacted.
Action Receipt
The Guardian signs the authorization consumed, the execution context and the outcome it was able to establish, together with the digest of the local policy that bounded it.
Authority
No request carries its own permission.
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. Quorum profiles are signed policy snapshots, not authority values: standard and elevated are labels for humans, while the proof relies on the threshold, the approver roster and the policy hash.
noneNever grants execution. It exists so that its absence is explicit rather than implied.
policy_delegatedAutonomy inside a policy the organization set in advance, and only for a device-signed request. Never for a correlated one.
human_mfaA named human approves against a live MFA session. Used where the effect is bounded and reversible in practice.
quorumM-of-N independent approvers, each with their own MFA session, against a policy set in advance. The requester can never approve their own request. Required for every grant of privilege.
Failure safety
Unknown stays unknown.
An ambiguous provider response remains indeterminate until reconciliation. Mutating operations are not blindly retried.
A payment API times out after receiving a mutation. Repeating it may duplicate the effect. SecureStamp does not assume failure and retry: the Guardian reconciles provider state and can return indeterminate. Ambiguity is a first-class result and is never rounded up to success.
Independent verification
Check the chain without asking us.
The verifier is a published package with no network access. It recomputes every digest and every signature in a proof bundle offline, including the policy snapshot hash and the digest of the signed local policy. Receipts can be verified offline without contacting SecureStamp, and verification does not depend on a live SecureStamp service.
npx --package @securestamp/action-proof-verify action-proof-verify bundle.jsonThe verifier ships ahead of the artifacts it verifies. A new receipt or bundle version is never emitted before a released verifier already accepts it.
Connectors
Bring the execution point you already use.
SecureStamp’s authorization model is provider-independent. These are reference connectors, not a closed catalog. How a connector integrates and how much SecureStamp vouches for it are two separate questions, and we keep them separate on purpose.
How it connects
Certified adapter
A module we wrote, reviewed and bound to published certification evidence.
Declarative HTTPS adapter
Origin, method and path fixed at install time. No arbitrary URL, method or headers from the model, no redirects, strict schema, deterministic idempotency.
SDK / sidecar
For protocols that cannot satisfy the declarative contract, over a Unix socket.
How its assurance is declared
SecureStamp Certified
We wrote it, we reviewed it, and we published the evidence.
Partner Attested
A named partner attests to it, and the bundle says so.
Customer Defined
You built it. The chain still verifies, and the bundle states plainly that SecureStamp did not certify the connector code.
Adapters translate an authorized effect into provider-specific execution. They do not redefine the authority granted.
Stripe
refund.createhuman_mfaOkta
group.add_userhuman_mfaAWS
iam.attach_role_policyquorumGoogle Cloud
iam.project_binding.addquorumAzure
rbac.role_assignment.createquorumMicrosoft Entra
pim.directory_role_assignment.createquorumFits your existing control plane
Works with the controls you already have.
SecureStamp does not replace identity, policy engines, approval workflows or provider APIs. It binds their approved decisions to exact executable effects.
Evidence boundaries
What a receipt does and does not establish.
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, nor does it establish legal ownership of the provider account.
The evidence boundary is the enrolled execution path.
Actions performed outside that path are outside the scope of the receipt.
Release status
Why these packages still say beta.
The protocol, the code and the verifier are complete and auditable today. But we do not call a connector stable until we have published evidence of 100 real executions against a live provider — including fault injection, replay rejection and proof that the credential could not have done more — bound to the exact commit that produced them. Production execution requires explicit opt-in and connector eligibility, and until a connector clears that gate its Guardian refuses to run outside sandbox mode. A trust product that asks you to take its word for it has already failed.
Packages
@securestamp/action-proof-verifyThe offline verifier and its verification contracts. Published ahead of everything it verifies.
@securestamp/action-proofContracts, signing and proof bundles.
@securestamp/execution-guardianThe customer-hosted daemon and its provider connectors.
@securestamp/execution-guardian-mcpThe MCP bridge. No credentials, no cloud SDKs, by construction.
Trust Levels
Trust Level explains origin. Action Verdict helps decide the action.
Levels L1-L5 grade verifiable origin evidence. They do not claim that content is true or that an action should automatically execute.
L1
Registered
The domain or organization is registered in SecureStamp.
L2
Aligned
Technical signals such as SPF, DKIM, DMARC or DNS are aligned.
L3
Signed
The message, channel or event includes a signed and verifiable token.
L4
Notarized
A verifiable integrity reference or receipt exists for later audit.
L5
Certified
The organizational identity behind the origin was reviewed with additional evidence.
Verified origin does not mean approved action
Trust Level describes the strength of origin evidence. Action Verdict evaluates a concrete action using SSF, context and policy. A legitimate origin can still request an action that requires review.
Integration points
Four ways to declare and query trust
DNS TXT record
Publish a TXT record under _securestamp.[domain]. Verifiers resolve the subdomain and validate declared origin without inspecting private content.
- —v=1 — protocol version
- —id=<stamp_id> — verifiable identifier
- —url=<verify_url> — canonical verification URL
_securestamp.example.com. 3600 IN TXT
"securestamp=v=1;
id=f47ac10b-58cc-4372-a567-0e02b2c3d479;
url=https://securestamp.org/verify/eyJhbG..."Email header
Inject X-SecureStamp into outbound messages so clients, plugins and gateways can query origin and status with signed signals.
- —Token signed by the sender or authorized node
- —Minimum claims: stampId, domain, orgId, score, exp
- —Public key or verifiable reference for validation
X-SecureStamp: v=1;
token=eyJhbGciOiJFUzI1NiJ9.eyJzdGFtcElkIjoiZjQ3YWMxM...;
verify=https://securestamp.org/verify/eyJhbG...REST API
Query domains, channels or actions without storing sensitive instructions in plaintext. Responses can include signals, reasons and Trust Receipts.
- —Trust checks for domains and channels
- —Action Verdict for sensitive actions
- —Verifiable receipts for audit
- —Public verifier and registry when applicable
GET https://securestamp.org/v1/trust/example.com{
"domain": "example.com",
"trustLevel": "L3",
"signals": { "spf": "pass", "dkim": "pass", "dmarc": "pass" },
"actionVerdict": "needs_confirmation",
"receiptRef": "tr_01h..."
}MCP Server
Active Agent Trust layer so agents can query trust checks before tool calls, APIs, workflows and sensitive operations.
- —SecureStamp MCP Server
- —Tool call checks
- —Action Verdict before execution
- —Human approval when policy requires it
securestamp.get_action_verdict({
origin: "billing@example.com",
action: "payment_request",
amount: "1200.00",
destination: "acct_..."
})Official Channel Signal
Official channel verification across conversational surfaces
Signal lets you query whether a number, bot, handle, link, account or contact point belongs to the official perimeter declared by an entity. It is the layer for WhatsApp, Telegram, web, QR, support, billing and other channels where a person or agent can receive sensitive instructions.
Official perimeter
Checks email, WhatsApp, Telegram, web, QR, support and billing channels against verifiable records.
Connected to SSF
Channel signals feed Trust, Action Verdict and receipts without turning a brand into an absolute guarantee.
Honest limit
Signal verifies membership in the official perimeter. It does not prove that every message is true.
Receipts, registry and audit
Auditable evidence without relying on screenshots
Each relevant query or declaration can generate a verifiable receipt. Receipts help audit origin, channel, declared intent and Action Verdict without relying on blind trust in an interface.
Trust Receipts
Signed receipts summarizing signal, allowed context, timestamp and verifiable reference.
Registry
Tokens, receipts and public references can be verified without authentication when the flow allows it.
Audit
Organizations can combine receipts with internal policies, approvals and compliance controls.
Public glossary
A shared language for users, support and integrators
The glossary explains SecureStamp, email, cryptography, Signal, E2EE, API and infrastructure terms so a non-technical person or junior developer can understand what they are reading.
Open glossarySecureStamp Terms
Concepts created or defined by SecureStamp to explain trust, stamps, receipts and verifiable perimeters.
Email, Domains and Authentication
Classic abbreviations used when SecureStamp explains whether a sender or domain is properly authenticated.
Cryptography and Security
Terms needed to understand signatures, encryption, keys, verifiable logs and enterprise recovery.
Protocols, APIs and Infrastructure
Common language for junior developers and integrators reading APIs, plugins, dashboards or runbooks.
Federated network
Federated network and approved nodes
SecureStamp Foundation coordinates a network of approved nodes to write and verify shared records. Operating a node requires technical review, SLA and alignment with governance principles.
Submit application
Include organization, region, operating capacity, expected SLA, technical surface and declared use case.
Technical review
The foundation evaluates capacity, operational security, coverage and potential conflicts of interest.
Credentials issued
If approved, the operator receives credentials and integration requirements to participate in the network.
Audited operation
The node must maintain availability, public health, operational traceability and incident-response processes.
Node obligations
Verifiable registry
Verify stamps, receipts and public references
Every stamp, receipt or public reference issued by SecureStamp can be verified without turning this site into a commercial landing page. The foundation maintains the standard and query points.
securestamp.org/verify/[token]Technical FAQ
Frequently asked questions for developers and integrators
What is SecureStamp Foundation?
The entity that publishes and governs the open SecureStamp standard for verifying origin, intent, channel and action before operating.
What problem does the protocol solve?
It helps humans, systems and agents query verifiable signals before replying, paying, sharing data, invoking APIs or running workflows.
How do the trust stack and the surfaces relate?
The trust stack is Origin, Intent, Execution Authorization and Execution Evidence. The surfaces are email, official channels, agents, APIs and workflows. They are two independent axes: the same stack applies across every surface, and Execution Authorization is a layer, never a surface of its own.
What is Proof of Origin?
Verifiable evidence that a domain, channel, sender or organization corresponds to a registered origin.
What is Execution Authorization?
The process of binding an approved decision to a bounded, transaction-specific authority that permits software to cause one defined effect under explicit constraints. Access control limits what software can reach; Execution Authorization bounds the exact effect it may cause.
What is Action Verdict?
An evaluation of a concrete action before execution. It can recommend allow, review, deny or human approval according to signals and policy.
What is SSF?
SecureStamp Signal Framework: a common language for origin, authentication, channel, content, context, action and verdict signals.
What is SecureStamp MCP Server?
A developer preview direction for agents to query trust checks before sensitive tool calls through Model Context Protocol.
Docs and specification
Protocol documentation
The specification covers Proof of Origin, Proof of Intent, SSF, Action Verdict, integration points, receipts, honest limits and MCP direction for agents.
Questions about the specification or protocol design? protocol@securestamp.org
Contact
Get in touch
Each address routes directly to the right team. No ticketing system — real people.