用於精確效果授權的
信任協定。
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 不是為某一個收件匣、某一個應用或某一個產業設計的。協定圍繞來源、管道、宣告的意圖與動作來組織訊號。它可以用在郵件、即時通訊、QR、網站、發票、工單、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、QR、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、網頁、QR、客服、帳務等管道的那一層——在這些地方，人或代理程式都可能收到敏感指令。
官方邊界
將電子郵件、WhatsApp、Telegram、網頁、QR、客服與帳務管道與可驗證記錄比對。
接上 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
聯絡
聯絡我們
每個信箱都直達對應團隊。沒有工單系統——是真人。