正確な効果を認可するための
信頼プロトコル。
SecureStamp は、デジタルの信頼を発信元と意図から実行までつなぎます。承認された決定は、顧客が管理するポリシーによって制限された限定的な実行権限となり、独立して検証可能な証拠があとに残ります。
Gmail、Outlook、Apple Mail。受信トレイに発信元の証拠を表示
公式チャネル
WhatsApp、Telegram、そしてブランドが宣言する境界
エージェントと API
MCP ツール、API、自律ワークフロー
プロトコルのアーキテクチャ
行動の前に信頼を。実行の後に証拠を。
ひとつの信頼スタックを、すべての面に適用する。
SecureStamp は、エージェント機能を後付けしたメールチェッカーではありません。発信元、意図、実行の認可、実行の証拠は、ひとつの連鎖を成す四つの層です。そしてその連鎖は、指示が受信トレイに届いても、メッセンジャーに届いても、MCP のツール呼び出しで来ても、同じように働きます。
SecureStamp は信頼を、指示から結果まで延ばします。
これはどこから来たのか。ドメイン、ヘッダー、署名、宣言された identity、チャネルの境界。裏づけの証拠であり、決して見出しではありません。
Trust Levels
Trust Level は発信元を説明します。Action Verdict は行動の判断を助けます。
L1〜L5 は検証可能な発信元の証拠を格付けします。内容が真実だとも、行動を自動で実行すべきだとも主張しません。
L1
登録済み
そのドメインまたは組織が SecureStamp に登録されています。
L2
整合
SPF、DKIM、DMARC、DNS などの技術シグナルが整合しています。
L3
署名済み
メッセージ、チャネル、イベントに署名済みで検証可能なトークンが含まれています。
L4
公証済み
後の監査のために、検証可能な完全性の参照またはレシートが存在します。
L5
認証済み
発信元の背後にある組織の identity を、追加の証拠で審査しました。
発信元が確認できても、行動が承認されたわけではありません
Trust Level は発信元の証拠の強さを表します。Action Verdict は SSF、文脈、ポリシーを使って具体的な行動を評価します。正当な発信元でも、確認が必要な行動を求めることがあります。
さらに詳しく · Official Channel Signal
Official Channel Signal
会話型の面をまたいだ公式チャネルの検証
Signal を使うと、番号、ボット、ハンドル、リンク、アカウント、連絡先が、ある主体の宣言した公式境界に属するかどうかを問い合わせられます。WhatsApp、Telegram、Web、QR、サポート、請求など、人やエージェントが機微な指示を受け取りうるチャネルのための層です。
公式境界
メール、WhatsApp、Telegram、Web、QR、サポート、請求のチャネルを検証可能なレコードと照合します。
SSF に接続
チャネルのシグナルは、ブランドを絶対的な保証に変えることなく、Trust、Action Verdict、receipts に反映されます。
正直な限界
Signal は公式境界への所属を検証します。すべてのメッセージが真実だと証明するものではありません。
何が求められているのか。要求された行為を先に読み取り、先に示します。支払う、承認する、認証情報を渡す、ツールを呼び出す。入力シグナルであって、証明ではありません。
プロトコルの主張
新しい境界は、アクションそのもの。
はじめは、マルウェアやトロイの木馬から端末を守っていました。次に、フィッシングから受信トレイを守りました。いまはソフトウェアが私たちの代わりに動きます。問いはもう「どこまで届くか」だけではありません。「何を変えられるか」です。
メッセージ、イベント、プロンプトは、API、ツール呼び出し、ワークフロー、デジタル通貨の操作を引き起こせます。SecureStamp は、コミュニケーションがアクションになる前に、検証可能なシグナルを提示します。
identity は、誰がシステムにアクセスできるかを制御します。SecureStamp は、自律的なソフトウェアが引き起こしてよい正確な効果を限定します。
Proof of Intent
何が求められているのか。要求された行為を先に示す入力シグナルです。何が認可されたかの証明ではありません。
Proof of Origin
どこから来たのか。ドメイン、組織、チャネル、送信者、切手、技術シグナル。裏づけの証拠です。
Action Verdict
進めるべきか。決定のシグナルです。その決定のあとに起きることが Execution Authorization です。
さらに詳しく · 四つの層
四つの層
認証は identity を確立します。アクセス制御は到達範囲を制限します。Execution Authorization は効果を限定します。
認証
誰が、あるいは何が動いているのか。
アクセスの認可
どのリソースに到達してよいのか。
Execution Authorization
どの効果を正確に引き起こしてよいのか。
実行の証拠
どの認可が消費され、実行地点はどの結果を確認できたのか。
四つ目の問いは意図してこう書いています。確認できない結果は不確定のままであり、このスタックのどの層もそれをごまかしません。
私たちの位置
SecureStamp は、決定が終わるところから始まります。
identity、ポリシー、承認の各システムが、そのアクションを進めるべきかを決めます。SecureStamp は、その承認された決定を、実行してよい正確な効果に結びつけます。
決める
何を許すべきか。これに答えるのは identity、ポリシーエンジン、承認、そして人です。
認可する
どの効果を正確に許すのか。これが SecureStamp の加える層です。
実行する
顧客の制約の範囲内で、顧客が管理する地点でその効果を適用します。
検証する
どの認可が消費され、実行地点はどの結果を確認できたのか。
SecureStamp は identity、ポリシーエンジン、承認ワークフロー、プロバイダー API を置き換えません。それらが承認した決定を、正確な実行可能効果に結びつけます。
SecureStamp は検証可能なシグナルと限定された認可を提供します。社内ポリシー、権限設定、サンドボックス、人による承認、既存のセキュリティ統制を置き換えるものではありません。
端末
最初の近代的な境界は端末でした。マルウェア、トロイの木馬、危険なファイル、ローカルでの挙動です。
受信トレイ
やがてリスクはメッセージへ移りました。よく似たドメイン、偽のリンク、添付ファイル、支払いの急かし、なりすましです。
アクション
いまは一通の指示が、ツールを開き、API を呼び、請求書を処理し、データを動かし、支払いを準備できます。
Trust checks
SecureStamp はメッセージが何を求めているか(支払い、承認、認証情報の提供、ツールの実行)を読み取り、返信・支払い・データ共有・ワークフロー実行の前に、発信元・チャネル・文脈の証拠で裏づけます。
チャネル非依存
チャネルに依存しない標準
SecureStamp は、特定の受信トレイ、アプリ、業種のために作られたものではありません。プロトコルは、発信元、チャネル、宣言された意図、アクションを軸にシグナルを整理します。メール、メッセージング、QR、ウェブサイト、請求書、チケット、API、エージェント、デジタル通貨の操作に適用できます。
Signal Framework
SSF: SecureStamp Signal Framework
SSF はまず要求されている操作を、続いて内容・発信元・認証・チャネル・文脈のシグナルを整理し、人・システム・エージェントが読めるシンプルで監査可能な出力を生成します。
Requested Action
返信、開封、支払い、送金、承認、データ共有、ツールの呼び出し、ワークフローの実行。
Content Signals
緊急性、リンク、添付ファイル、認証情報、支払い指示、口座変更。
Origin Signals
ドメイン、組織、宣言された identity、送信者。
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 は、進めるべきかを推奨します。三つとも決定に入力されるシグナルであり、決定はまだ認可ではありません。
どの効果を正確に引き起こしてよいのか。承認された決定は、明示的な制約のもとで、ひとつの正規オペレーションに対する限定的な一回限りの権限になります。
実行レイヤー
Public Beta · 本番アクセスは管理下判定は証明ではない。
verdict は、そのアクションを進めるべきかを推奨できます。しかしそれ自体は、何が正確に認可されたのか、その背後の権限、認可が再利用されたかどうか、実行時に観測された結果を証明しません。
Action Proof はその証拠の連鎖をつくります。承認された決定は、限定された実行可能な権限になります。正確な効果ひとつ、権限ひとつ、期限ひとつ、使用回数ひとつ — 誰でもオフラインで検証できます。
証明の連鎖
5 つの環、それぞれ異なる当事者が署名
認可の暗号学的な証明。実行結果の署名付き証拠。
Source Envelope
プラグインは、人が実際に見たものを端末上で、端末から出ない鍵で署名します。メッセージ本文が送信されることはありません。
Action Effect
モデルではなく Guardian が、プロバイダーの状態を読み、正確な効果を正規化します。プロバイダー、オペレーション、リソース、パラメーター、そして直前状態の digest です。
Execution Grant
SecureStamp Cloud は、その効果の digest、承認した権限、有効なポリシーバージョン、期限に結びついた一回限りの grant に署名します。maxUses は常に 1 です。
Execution Claim
あなたの Guardian は、自分の ledger に対して grant を請求します。再生された grant は、どのプロバイダーに接触するより前に拒否されます。
Action Receipt
Guardian は、消費された認可、実行のコンテキスト、確認できた結果を、それを限定したローカルポリシーの digest とともに署名します。
エージェントとハーネス · Beta
再現可能なラボが、コーディングエージェントに宣言された制限を MCP、シェル、スクリプト、API の直接呼び出しを通じて破ろうと試み、結果をエージェントの外から観測したうえで、同じプロファイルのもとで実際のタスクを実行します。外に出るのはレビューされた変更そのものだけで、それも Execution Guardian を通ります。
さらに詳しく · 実行レイヤー
アクセスは行動の認可ではない
アクセスはソフトウェアが到達できる範囲を制御します。Execution Authorization は、引き起こしてよい正確な効果を限定します。
リソースの認可は、principal が何にアクセスしてよいかに答えます。Execution Authorization は、取引固有のどの効果を引き起こしてよいかに答えます。fine-grained なアクセスでも、取引そのものは未定義のままです。どのリソースか、いくらか、どの宛先か、何回か。
ツールへのアクセスだけでなく、効果を認可する。
顧客が管理する上限
上限はあなたのポリシーです。
SecureStamp Cloud は認可をより狭くできます。あなたの組織が署名してローカルに導入したポリシーより広くすることはできません。クラウドの認可は必要ですが、それだけでは決して十分ではありません。
実効的な許可
実効的な許可 =
クラウドの grant
∩ 署名済みローカルポリシー
∩ アダプターの制約
∩ kill switches- ローカルポリシーは、あなたの組織が自らの鍵で署名し、Guardian のそばに導入する文書です。tenant、gateway、オペレーション、アダプターの manifest、受け入れる権限とポリシーのバージョン、リソース、パラメーター、金額の上限、同時実行数、ネットワーク宛先を固定します。
- 構造上 deny-only です。クラウドが与えなかったものを与えられるフィールドは、ひとつもありません。
- 有効な署名済みローカルポリシーなしに本番モードで起動することは、警告ではなく起動時の拒否になります。
- kill switches はグローバルに、またプロバイダー、オペレーション、tenant、gateway ごとに存在し、さらにローカルポリシーの内側にも存在します。すでに発行された grant を止めます。
- ポリシーには必須のレビュー日と任意の有効期限があります。期限切れのポリシーは新しいミューテーションを止め、ステータス、証明、読み戻し、照合はそのまま残します。
- 鍵の復旧は M-of-N かつオフラインです。SecureStamp のサポートがこの管理を代行することはできません。それこそが要点です。
- クラウドのコントロールプレーンが侵害されても、ローカルで許された権限を超えることはできません。
顧客ホスト型
当社が承認し、お客様が実行する。
Guardian はあなたの環境で動き、プロバイダーの認証情報を保持します。SecureStamp Cloud はプロバイダーの認証情報を受け取らず、あなたのプロバイダーを呼び出すこともありません。
- プロバイダーの認証情報は root 所有のファイルとしてマウントされます。環境変数やインライン設定にはしません。
- モデルに最も近いプロセスである MCP bridge は、プロバイダーの認証情報もクラウド SDK も必要としません。
- 効果は daemon 自身が読み取った状態から解決されます。モデルが渡したパラメーターからではありません。
- 直前の状態はミューテーションの直前に読み直されます。実質的な変化があれば、上書きではなく grant を無効にします。
権限
いかなるリクエストも、自らの許可を携えてはこない。
あるオペレーションが要求する権限はプロトコルが定めます。呼び出し側は選べず、モデルは主張できず、その権限を必要とするリクエストの中で格下げすることもできません。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、メソッド、ヘッダーはなく、リダイレクトもなく、厳格な schema と決定的な冪等性があります。
SDK / sidecar
宣言的な契約を満たせないプロトコル向けに、Unix ソケット経由で。
保証の宣言のしかた
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 は identity、ポリシーエンジン、承認ワークフロー、プロバイダー API を置き換えません。それらが承認した決定を、正確な実行可能効果に結びつけます。
証拠の境界
receipt が示すことと、示さないこと。
Action Receipt は、登録済みの Guardian を通過したものと、その Guardian が確認できた結果を証明します。SecureStamp の外で何の行為もなかったことは証明せず、プロバイダー口座の法的所有権を確立するものでもありません。
証拠の境界は、登録された実行経路です。
その経路の外で行われた行為は、receipt の範囲外です。
リリース状況
これらのパッケージがまだベータと表示される理由。
For the single-grant chain, the protocol, the code and the verifier are complete and auditable today. Bounded delegation — one approval for several exact steps — is a separate profile still in design and simulation, and its known gaps are published. 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.
パッケージ
@securestamp/action-proof-verifyオフライン検証器と、その検証契約。検証する対象すべてより先に公開されます。
@securestamp/action-proof-verify@securestamp/execution-guardian-mcpMCP bridge。構造上、認証情報もクラウド SDK も持ちません。
@securestamp/execution-guardian-mcp委譲された権限
権限がソフトウェアに委譲されるあらゆる場所で。
エージェント、自動化、ワークフロー、他者に代わって動く委譲されたサービス — どれも同じ問いを生みます。アクセス権限は「どこまで届くか」を語りますが、この取引で承認された正確な効果を定義しません。
エージェント向けの 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 → ActionReceiptV3Action Proof — Execution Authorization
ツールへのアクセスだけでなく効果を認可する。正典となる例、三つのステップ、ローカルの認可上限、検証器が再計算する契約、そして receipt をオフラインで検証する方法。
Bounded delegation — Task Contract
The specification for a signed, revisable mandate: tenant, actors, Guardian, revision, steps, budget, validity window, policy and revocation — plus the deliberate exclusions and the known gaps of the local runtime, listed until they close.
エージェントハーネス・ラボ
プロファイル HP0–HP2 とラボのレベル LR0–LR2、テストの背後にある失敗のファミリ、経路ごとの証拠の適用可否、Execution Guardian を通じた正確なエクスポート、停止とキャンペーン予算、そしてラボが証明しないこと。
どの認可が消費され、実行地点はどの結果を確認できたのか。誰でもオフラインで検証できる署名付きレシートです。
Receipts、registry、監査
スクリーンショットに頼らない監査可能な証拠
関連する問い合わせや宣言ごとに、検証可能な receipt を生成できます。receipt があれば、インターフェースを盲信せずに発信元、チャネル、宣言された意図、Action Verdict を監査できます。
Trust Receipts
シグナル、許可された文脈、タイムスタンプ、検証可能な参照をまとめた署名付き receipts。
Registry
フローが許す場合、トークン、receipts、公開参照は認証なしで検証できます。
監査
組織は receipts を社内ポリシー、承認、コンプライアンス統制と組み合わせられます。
検証可能な registry
切手、receipts、公開参照を検証する
SecureStamp が発行した切手、receipt、公開参照はすべて、このサイトを商用ランディングページに変えることなく検証できます。財団は標準と問い合わせ先を維持します。
securestamp.org/verify/[token]Evidence and coverage
What is proven, and what is not. The four evidence levels, the rules that make a coverage claim refutable, the named threats with their open gaps, and everything that sits outside the guarantee.
ホワイトペーパーの実行層
同じ層を仕様の深さで。五つの環からなる証明の連鎖、一回限りの grant、署名済みポリシースナップショットとしての quorum プロファイル、オープンなアダプタープラットフォーム、そして証拠の境界。
適用範囲
Gmail · Outlook · Apple Mail
公式チャネル
WhatsApp · Telegram · 宣言された境界
エージェント
MCP クライアントとアシスタント
APIs
直接統合
Workflows
自動化と委譲されたサービス
Execution Authorization は、AI エージェントに限らず、権限がソフトウェアに委譲されるあらゆる場面に当てはまります。他者に代わって動く自動化、ワークフロー、委譲されたサービスも、同じ問いを突きつけます。どの効果が正確に承認されたのか。
どこから始めるか
やるべきことに応じた、4つの道筋。
DNS、メールヘッダー、REST API、MCP サーバーから信頼を宣言し、照会します。どの方式にも例とドキュメントがあります。
DNS TXT record
_securestamp.[domain] の下に TXT レコードを公開します。検証側はサブドメインを解決し、非公開の内容を覗かずに宣言された発信元を検証します。
Email header
送信メッセージに X-SecureStamp を挿入すると、クライアント、プラグイン、ゲートウェイが署名付きシグナルで発信元と状態を問い合わせられます。
REST API
機微な指示を平文で保存せずに、ドメイン、チャネル、アクションを問い合わせます。応答にはシグナル、reasons、Trust Receipts を含められます。
MCP Server
エージェントがツール呼び出し、API、ワークフロー、機密操作の前にtrust checkを照会できる有効なAgent Trustレイヤー。
さらに詳しく · 統合ポイント
統合ポイント
信頼を宣言し、問い合わせる四つの方法
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 を挿入すると、クライアント、プラグイン、ゲートウェイが署名付きシグナルで発信元と状態を問い合わせられます。
- —送信者または認可ノードが署名したトークン
- —最小クレーム: 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
エージェントがツール呼び出し、API、ワークフロー、機密操作の前にtrust checkを照会できる有効なAgent Trustレイヤー。
- —SecureStamp MCP Server
- —Tool call checks
- —実行前の Action Verdict
- —ポリシーが求める場合の人による承認
securestamp.get_action_verdict({
origin: "billing@example.com",
action: "payment_request",
amount: "1200.00",
destination: "acct_..."
})委任されたソフトウェアが引き起こせることを限定します。ひとつの正確な効果には Action Proof、複数のステップには限定委任、そして自律性を与える前に設定を点検する Safe Defaults Kit。
Action Proof — Execution Authorization
ツールへのアクセスだけでなく効果を認可する。正典となる例、三つのステップ、ローカルの認可上限、検証器が再計算する契約、そして receipt をオフラインで検証する方法。
Bounded delegation — Task Contract
The specification for a signed, revisable mandate: tenant, actors, Guardian, revision, steps, budget, validity window, policy and revocation — plus the deliberate exclusions and the known gaps of the local runtime, listed until they close.
エージェントハーネス・ラボ
プロファイル HP0–HP2 とラボのレベル LR0–LR2、テストの背後にある失敗のファミリ、経路ごとの証拠の適用可否、Execution Guardian を通じた正確なエクスポート、停止とキャンペーン予算、そしてラボが証明しないこと。
Safe Defaults Kit
A local kit that reads the config files you point it at, names what it found — an inline secret, a shell launch, an unpinned package — and proposes a minimal corrected version on a copy. No account, no data leaving the machine.
Evidence and coverage
What is proven, and what is not. The four evidence levels, the rules that make a coverage claim refutable, the named threats with their open gaps, and everything that sits outside the guarantee.
切手、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.
Evidence and coverage
What is proven, and what is not. The four evidence levels, the rules that make a coverage claim refutable, the named threats with their open gaps, and everything that sits outside the guarantee.
公証モデルと L5
SecureStamp が L5 Certified に至る道筋。メッセージ envelope の ES256 署名付き公証記録に加え、事業体 identity(KYB)の審査。五段階と、正直な境界。証明するのは発信元と完全性であって、内容の真実性ではありません。
フェデレーテッドネットワークにノードを追加します。申請、技術審査、認証情報、監査付きの運用。
フェデレーテッドネットワーク
フェデレーテッドネットワークと承認済みノード
SecureStamp Foundation は、共有レコードを書き込み検証する承認済みノードのネットワークを調整します。ノードの運用には技術審査、SLA、ガバナンス原則との整合が必要です。
申請を送る
組織、地域、運用能力、想定 SLA、技術的な対象範囲、宣言するユースケースを記載します。
技術審査
財団が能力、運用セキュリティ、カバレッジ、利益相反の可能性を評価します。
認証情報の発行
承認されると、運用者はネットワーク参加のための認証情報と統合要件を受け取ります。
監査下の運用
ノードは可用性、公開 health、運用のトレーサビリティ、インシデント対応プロセスを維持しなければなりません。
ノードの義務
ドキュメントと仕様
プロトコルのドキュメント
自律型ソフトウェアに作業を委任する開発者と組織向けのドキュメント。Break the Mandate による MCP サーバー、エージェント、ハーネスの保護(ネイティブファイルに対する Doctor、再現可能なラボ、Exact Export、実行の制御)、正確な効果を承認し、オフラインで検証できるレシートを伴う Action Proof、Task Contract による境界付き委任、メッセージ向けの Proof of Origin、Proof of Intent、SSF、Action Verdict(公開済みの Gmail および Outlook プラグイン付き)、各プロファイルの証拠レベル、そしてそのすべての正直な限界を扱います。
仕様やプロトコル設計についてのご質問は? protocol@securestamp.org
技術 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 とは?
エージェントが機微なツール呼び出しの前に Model Context Protocol 経由で trust check を問い合わせるための、developer preview の方向性です。
お問い合わせ
ご連絡ください
それぞれのアドレスが担当チームに直接つながります。チケットシステムはありません。人が対応します。
