用于精确效果授权的
信任协议。
SecureStamp 将数字信任从来源和意图延伸到执行。获批准的决策成为受限的执行权限，由客户掌控的策略加以约束，并留下可独立验证的证据。
Gmail、Outlook 和 Apple Mail，在收件箱中显示来源证据
官方渠道
WhatsApp、Telegram 以及品牌声明的边界
智能体与 API
MCP 工具、API 和自主工作流
协议架构
行动之前先有信任。执行之后留下证据。
一套信任堆栈，应用于每一个触点。
SecureStamp 不是一个外挂了智能体功能的邮件检查器。来源、意图、执行授权和执行证据是同一条链条的四层——无论指令来自收件箱、即时通讯工具，还是一次 MCP 工具调用，这条链条的运作方式都相同。
SecureStamp 把信任从指令一直延伸到后果。
信任堆栈
来源
这是从哪里来的？域名、邮件头、签名、声明的身份和渠道边界。这是佐证——必要，但绝不是标题。
意图
对方要求什么？先读出并先说明被请求的动作：付款、批准、交出凭据、调用工具。这是输入信号，不是证明。
Execution Authorization
允许造成什么确切效果？获批准的决策会变成一次性的受限权限，只对应一个规范操作，并受明确约束。
执行证据
消耗了哪一份授权，执行点又确认了什么结果？一张任何人都能离线验证的签名回执。
应用于
Gmail · Outlook · Apple Mail
官方渠道
WhatsApp · Telegram · 已声明的边界
智能体
MCP 客户端与副驾驶
APIs
直接集成
Workflows
自动化与受托服务
只要权限被委托给软件，Execution Authorization 就适用，而不只是针对 AI 智能体。代表他人行事的自动化流程、工作流或受托服务，都会引出同一个问题：究竟批准了什么效果？
协议主张
新的边界就是动作本身。
最初我们保护设备，抵御恶意软件和木马。随后我们保护收件箱，抵御钓鱼。如今软件代替我们行事，问题不再只是它能触及什么——而是它能改变什么。
消息、事件和提示词都可能触发 API、工具调用、工作流和数字货币操作。SecureStamp 在一次沟通变成一个动作之前，先给出可验证的信号。
身份控制谁可以访问一个系统。SecureStamp 限定自主软件被允许造成的确切效果。
四层
认证确立身份。访问控制限制触及范围。Execution Authorization 限定效果。
认证
是谁、或者是什么在行动？
访问授权
它可以触及哪些资源？
Execution Authorization
它可以造成什么确切效果？
执行证据
消耗了哪一份授权，执行点又能确认什么结果？
第四个问题是刻意这么写的。无法确认的结果就保持不确定，这一堆栈里没有任何一层会假装并非如此。
我们的位置
SecureStamp 从决策结束的地方开始。
身份、策略和审批系统决定一个动作是否应当继续。SecureStamp 把那个获批准的决策，绑定到可以被执行的确切效果上。
决策
什么才应当被允许？由身份、策略引擎、审批和人来回答。
授权
允许造成什么确切效果？这正是 SecureStamp 补上的那一层。
执行
在客户的约束之内、在客户掌控的一个点上，施加那个效果。
验证
消耗了哪一份授权，执行点又能确认什么结果？
SecureStamp 不替代身份系统、策略引擎、审批流程或提供方 API。它把这些系统已批准的决策，绑定到确切的可执行效果上。
SecureStamp 提供可验证的信号和受限的授权。它不替代内部策略、权限设置、沙箱、人工批准或你已有的安全控制。
设备
第一道现代边界是设备：恶意软件、木马、危险文件和本地行为。
收件箱
随后风险转移到消息上：仿冒域名、假链接、附件、付款催促和身份冒充。
动作
如今一条指令就能打开工具、调用 API、处理发票、搬运数据或准备付款。
Trust checks
SecureStamp 读取消息要求你做什么——付款、审批、交出凭据、调用工具——并在回复、付款、共享数据或执行工作流之前，以来源、渠道与上下文证据为其背书。
与渠道无关
一套与渠道无关的标准
SecureStamp 不是为某一个收件箱、某一个应用或某一个行业设计的。协议围绕来源、渠道、声明的意图和动作来组织信号。它可以用在邮件、即时通讯、二维码、网站、发票、工单、API、智能体和数字货币操作上。
被委托的权限
只要权限被委托给软件。
一个智能体、一段自动化、一条工作流，或一项代表他人行事的受托服务，都会引出同一个问题。访问权限说明它们能触及什么；它并没有定义这一笔交易获批准的确切效果。
面向智能体的 MCP
SecureStamp MCP Server
MCP 是 AI 应用触及工具、数据和工作流的方式。SecureStamp 就站在这层触及之前：在任何东西运行之前，软件先问清这条指令究竟在要求什么、对方是谁、可能造成什么确切效果。
SecureStamp 负责授权；它从不持有你下游的提供方凭据。当一个操作确实需要执行时，签名的 grant 会送到你自己运行的 Execution Guardian，只有那个 daemon 会碰提供方。
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(...)概念流程
agent → read_message_request → analyze_message_intent → get_safe_next_step → request_execution_grant → Execution Guardian → ActionReceiptV3Signal Framework
SSF: SecureStamp Signal Framework
SSF 先整理所要求的操作，再整理内容、来源、身份验证、渠道与上下文信号，产出一份人、系统与代理都能读懂且可审计的简明结论。
Requested Action
回复、打开、付款、转账、批准、共享数据、调用工具或运行工作流。
Content Signals
紧迫感、链接、附件、凭据、付款指示和银行账户变更。
Origin Signals
域名、组织、声明的身份、发送方。
Technical Signals
SPF、DKIM、DMARC、DNS TXT、邮件头、签名、密钥和 receipts。
Channel Signals
邮件、网页、WhatsApp、Telegram、二维码、API、客服、账单和工单。
Verdict Layer
Trust、Signal 与 Action Verdict：一份可读、可审计的结论，先说明所要求的操作，来源证据列在其下。
三个输入信号，然后才是授权
Proof of Origin 回答一条指令从哪里来。Proof of Intent 说明它在要求什么。Action Verdict 建议它是否应当继续。三者都是喂给决策的信号——而决策还不是授权。
Proof of Intent
对方在要求什么？一个先说明被请求动作的输入信号。它不是「授权了什么」的证明。
Proof of Origin
这是从哪里来的？域名、组织、渠道、发送方、邮票和技术信号。属于佐证。
Action Verdict
这件事该继续吗？一个决策信号。那个决策之后发生的事，就是 Execution Authorization。
执行层
Public Beta · 生产访问受控判定不等于证明。
verdict 可以建议一个动作是否应当继续。但它本身并不证明究竟授权了什么确切效果、背后是哪种权限、授权是否被重复使用，也不证明执行时观察到的结果。
Action Proof 构建这条证据链。获批准的决策成为受限的可执行权限：一个确切效果、一种权限、一个有效期、一次使用——任何人都能离线验证。
有访问权不等于有行动授权
访问控制软件能触及什么。Execution Authorization 限定它可以造成的确切效果。
资源授权回答的是一个 principal 可以访问什么。Execution Authorization 回答的是它可以造成哪一个针对具体交易的效果。即便是 fine-grained 的访问，交易本身仍然没有定义：哪个资源、多少金额、哪个目的地、几次。
授权效果，而不只是授权访问工具。
由客户掌控的上限
你的策略就是上限。
SecureStamp Cloud 可以把一次授权收得更窄。它无法把授权放得比你的组织签名并在本地安装的策略更宽。云端授权是必要的，但单靠它永远不够。
有效权限
有效权限 =
云端 grant
∩ 已签名的本地策略
∩ 适配器约束
∩ kill switches- 本地策略是一份由你的组织用自己的密钥签名、并安装在 Guardian 旁边的文档。它固定 tenant、gateway、操作、适配器 manifest、接受的权限与策略版本、资源、参数、金额上限、并发以及网络目的地。
- 它在构造上就是 deny-only。里面没有任何一个字段能授予云端没有授予的东西。
- 没有有效的已签名本地策略就以生产模式启动，不是给个警告，而是在启动时被拒绝。
- kill switch 存在于全局层面，也按提供方、操作、tenant 和 gateway 分别存在——并且在本地策略内部再有一层。它们能叫停已经签发的 grant。
- 策略带有强制复审日期和可选的到期时间。过期的策略会阻止新的变更，同时让状态、证明、回读和对账保持完好。
- 密钥恢复是 M-of-N 且离线的。SecureStamp 的支持无法替代这项控制，而这正是关键所在。
- 即使云端控制平面被攻陷，也仍然无法超出本地允许的权限。
客户自托管
我们授权，你来执行。
Guardian 运行在你的环境里，持有提供方凭据。SecureStamp Cloud 不接收提供方凭据，也从不调用你的提供方。
- 提供方凭据以 root 所有的文件形式挂载，绝不作为环境变量或内联配置。
- 最贴近模型的进程 MCP bridge，既不需要提供方凭据，也不需要云 SDK。
- 效果由 daemon 自己读取的状态解析而来，绝不来自模型提供的参数。
- 前置状态会在变更前立刻重新读取；出现实质变化时，grant 会被作废而不是被覆盖。
证明链
五个环节，各由不同主体签名
授权的密码学证明。执行结果的签名证据。
Source Envelope
插件在设备上，用一把从不离开设备的密钥，对人真正看到的内容签名。邮件正文从不外传。
Action Effect
由 Guardian——而不是模型——读取提供方状态并归一化确切效果：提供方、操作、资源、参数，以及前置状态的 digest。
Execution Grant
SecureStamp Cloud 签发一次性 grant，绑定到该效果 digest、批准它的权限、生效中的策略版本以及一个到期时间。maxUses 恒为 1。
Execution Claim
你的 Guardian 对照自己的 ledger 认领这个 grant。被重放的 grant 会在联系任何提供方之前就被拒绝。
Action Receipt
Guardian 对已消耗的授权、执行上下文以及它所能确认的结果签名，并附上限定它的那份本地策略的 digest。
权限
没有哪个请求会自带许可。
一个操作所要求的权限由协议规定。调用方不能挑选，模型不能为其辩护，也不能在需要它的那次请求内部被降级。quorum 配置是已签名的策略快照，不是权限取值：standard 和 elevated 是给人看的标签，而证明依赖 threshold、审批人名单和策略 hash。
none从不授予执行。它存在，是为了让这种缺席是明示的，而不是被默认。
policy_delegated在组织事先设定的策略范围内自主，且仅限于在设备上签名的请求。关联请求绝不适用。
human_mfa一位具名的人对一个有效的 MFA 会话进行批准。用于效果有界、实践中可回退的场景。
quorumM-of-N 位独立审批人，各自持有自己的 MFA 会话，对照事先设定的策略批准。请求者永远不能批准自己的请求。任何权限授予都必须如此。
故障安全
不知道就是不知道。
提供方给出的含糊响应在对账完成前保持不确定。会改变状态的操作不会被盲目重试。
某个支付 API 在收到一次变更之后超时。重复一次可能让效果翻倍。SecureStamp 不会假定失败然后重试：Guardian 会对账提供方状态，并且可以返回 indeterminate。含糊是一等结果，绝不会被向上取整成成功。
独立验证
不必问我们，自己核对这条链。
验证器是一个没有网络访问的已发布包。它离线重算 proof bundle 里的每一个 digest 和每一个签名，包括策略快照的 hash 和已签名本地策略的 digest。receipts 可以离线验证，无需联系 SecureStamp，验证也不依赖运行中的 SecureStamp 服务。
npx --package @securestamp/action-proof-verify action-proof-verify bundle.json验证器先于它所验证的产物发布。在已发布的验证器接受之前，绝不会发出新的 receipt 或 bundle 版本。
连接器
把你已经在用的执行点接进来。
SecureStamp 的授权模型与提供方无关。这些是参考连接器，不是一份封闭目录。连接器如何集成，以及 SecureStamp 为它背书到什么程度，是两个不同的问题，我们特意把它们分开。
如何接入
认证适配器
由我们编写、评审，并与已公开的认证证据绑定的模块。
声明式 HTTPS 适配器
origin、方法和 path 在安装时固定。不接受模型给出的任意 URL、方法或 header，不跟随重定向，schema 严格，幂等性确定。
SDK / sidecar
面向无法满足声明式契约的协议，通过 Unix socket 接入。
其保证如何声明
SecureStamp Certified
我们编写、我们评审，并公开了证据。
Partner Attested
由一位具名合作伙伴背书，bundle 里也写明这一点。
Customer Defined
这是你自己构建的。链条照样可以验证，而 bundle 会明明白白写出：SecureStamp 并未认证该连接器的代码。
适配器把已授权的效果翻译成特定提供方的执行。它们不会重新定义已授予的权限。
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.createquorum契合你现有的控制平面
与你已有的管控一起工作。
SecureStamp 不替代身份系统、策略引擎、审批流程或提供方 API。它把这些系统已批准的决策，绑定到确切的可执行效果上。
证据的边界
一份 receipt 能确立什么，不能确立什么。
一份 Action Receipt 证明的是什么经过了一个已登记的 Guardian，以及那个 Guardian 能够确认的结果。它不证明在 SecureStamp 之外没有发生过任何动作，也不确立提供方账户的法律所有权。
证据的边界就是已登记的执行路径。
在该路径之外发生的动作，不在这份 receipt 的范围内。
发布状态
这些包为什么仍然标注为 beta。
协议、代码和验证器今天已经完整且可审计。但在我们公开针对真实提供方的 100 次真实执行的证据之前——包括故障注入、重放拒绝，以及证明那份凭据不可能做得更多——并把它们绑定到产生这些证据的确切 commit，我们不会称一个连接器为 stable。生产执行需要明确的 opt-in 和连接器资格；在连接器通过那道关卡之前，它的 Guardian 拒绝在沙箱模式之外运行。一个要你凭一句话就相信它的信任产品，本身就已经失败了。
软件包
@securestamp/action-proof-verify离线验证器及其验证契约。发布时间早于它所验证的一切。
@securestamp/action-proof契约、签名与 proof bundle。
@securestamp/execution-guardian由客户自托管的 daemon 及其提供方连接器。
@securestamp/execution-guardian-mcpMCP bridge。在构造上就没有凭据、没有云 SDK。
Trust Levels
Trust Level 说明来源。Action Verdict 帮助判断动作。
L1-L5 等级评估可验证的来源证据。它们不宣称内容属实，也不表示某个动作应当自动执行。
L1
已注册
该域名或组织已在 SecureStamp 注册。
L2
已对齐
SPF、DKIM、DMARC 或 DNS 等技术信号一致。
L3
已签名
该消息、渠道或事件包含可验证的签名令牌。
L4
已公证
存在可验证的完整性引用或回执，供日后审计。
L5
已认证
来源背后的组织身份已通过额外证据审核。
来源已验证，不等于动作已批准
Trust Level 描述来源证据的强度。Action Verdict 结合 SSF、上下文和策略评估一个具体动作。来源合法，仍然可能提出需要复核的请求。
集成方式
声明与查询信任的四种方式
DNS TXT record
在 _securestamp.[domain] 下发布一条 TXT 记录。验证方解析该子域并校验声明的来源，无需查看私密内容。
- —v=1 — 协议版本
- —id=<stamp_id> — 可验证标识符
- —url=<verify_url> — 规范验证 URL
_securestamp.example.com. 3600 IN TXT
"securestamp=v=1;
id=f47ac10b-58cc-4372-a567-0e02b2c3d479;
url=https://securestamp.org/verify/eyJhbG..."Email header
在外发邮件中注入 X-SecureStamp，让客户端、插件和网关可以用签名信号查询来源与状态。
- —由发送方或授权节点签名的令牌
- —最少 claims：stampId、domain、orgId、score、exp
- —用于校验的公钥或可验证引用
X-SecureStamp: v=1;
token=eyJhbGciOiJFUzI1NiJ9.eyJzdGFtcElkIjoiZjQ3YWMxM...;
verify=https://securestamp.org/verify/eyJhbG...REST API
查询域名、渠道或动作，无需以明文保存敏感指令。响应可包含信号、reasons 和 Trust Receipts。
- —针对域名和渠道的 trust check
- —针对敏感动作的 Action Verdict
- —可供审计的可验证 receipts
- —适用时提供公开验证器与 registry
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
活跃的 Agent Trust 层，让代理在工具调用、API、工作流和敏感操作前查询 trust check。
- —SecureStamp MCP Server
- —Tool call checks
- —执行前的 Action Verdict
- —策略要求时由人工批准
securestamp.get_action_verdict({
origin: "billing@example.com",
action: "payment_request",
amount: "1200.00",
destination: "acct_..."
})Official Channel Signal
跨对话触点的官方渠道验证
Signal 让你查询某个号码、机器人、账号、链接、账户或联系入口，是否属于某个主体声明的官方边界。它是面向 WhatsApp、Telegram、网页、二维码、客服、账单等渠道的那一层——在这些地方，人或智能体都可能收到敏感指令。
官方边界
将邮件、WhatsApp、Telegram、网页、二维码、客服和账单渠道与可验证记录进行比对。
接入 SSF
渠道信号会汇入 Trust、Action Verdict 和 receipts，同时不会把一个品牌变成绝对担保。
诚实的边界
Signal 验证是否属于官方边界。它不证明每一条消息都是真的。
Receipts、registry 与审计
不依赖截图的可审计证据
每一次相关的查询或声明都可以生成一份可验证的 receipt。receipts 有助于审计来源、渠道、声明的意图和 Action Verdict，而不必盲目相信某个界面。
Trust Receipts
签名的 receipts，汇总信号、允许的上下文、时间戳和可验证引用。
Registry
流程允许时，令牌、receipts 和公开引用无需认证即可验证。
审计
组织可以把 receipts 与内部策略、审批和合规控制结合起来。
公开术语表
用户、支持团队和集成者的共同语言
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.
打开术语表SecureStamp 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.
联邦网络
联邦网络与已批准节点
SecureStamp Foundation 协调一个由已批准节点组成的网络，用于写入和验证共享记录。运营节点需要技术评审、SLA 以及与治理原则保持一致。
提交申请
请包含组织、地区、运营能力、预期 SLA、技术范围以及声明的使用场景。
技术评审
基金会评估能力、运营安全、覆盖范围以及潜在的利益冲突。
签发凭据
通过后，运营方会收到加入网络所需的凭据和集成要求。
受审计的运营
节点必须维持可用性、公开的 health、运营可追溯性以及事件响应流程。
节点义务
可验证的 registry
验证邮票、receipts 和公开引用
SecureStamp 签发的每一枚邮票、每一份 receipt 或公开引用都可以被验证，而不必把本站变成商业落地页。基金会维护标准与查询入口。
securestamp.org/verify/[token]技术 FAQ
面向开发者与集成方的常见问题
什么是 SecureStamp Foundation？
发布并治理开放 SecureStamp 标准的实体，用于在行动之前验证来源、意图、渠道和动作。
这个协议解决什么问题？
帮助人、系统和智能体在回复、付款、共享数据、调用 API 或运行工作流之前，查询可验证的信号。
信任堆栈和触点是什么关系？
信任堆栈是来源、意图、Execution Authorization 和执行证据。触点是邮件、官方渠道、智能体、API 和工作流。这是两个独立的维度：同一套堆栈适用于每一个触点，而 Execution Authorization 是一层，绝不是独立的触点。
什么是 Proof of Origin？
可验证的证据，表明某个域名、渠道、发送方或组织对应一个已注册的来源。
什么是 Execution Authorization？
把一个已获批准的决策绑定到受限的、针对单笔交易的权限的过程，使软件可以在明确约束下造成一个已定义的效果。访问控制限制软件能触及什么；Execution Authorization 限定它可以造成的确切效果。
什么是 Action Verdict？
在执行前对一个具体动作的评估。它可以根据信号和策略建议放行、复核、拒绝或需要人工批准。
什么是 SSF？
SecureStamp Signal Framework：一套关于来源、认证、渠道、内容、上下文、动作和 verdict 信号的共同语言。
什么是 SecureStamp MCP Server？
一个 developer preview 方向，让智能体在敏感的工具调用之前，通过 Model Context Protocol 查询 trust check。
文档与规范
协议文档
规范涵盖 Proof of Origin、Proof of Intent、SSF、Action Verdict、集成方式、receipts、诚实的边界，以及面向智能体的 MCP 方向。
对规范或协议设计有疑问？ protocol@securestamp.org
联系
联系我们
每个邮箱都直达对应团队。没有工单系统——是真人。