commonguy25/authproof-sdkAIエージェント向けの暗号署名付き委任レシート。AIが実行できること、できないことを正確に定義 — 署名済み、検証可能、改ざん防止。
AuthProofは、AIエージェント向けの監査および帰属レイヤーです。エージェントが行動する前にユーザーが何を承認したかを証明し、その承認に対してエージェントが実際に行ったことを記録します。
仕組みはシンプルです。ユーザーは自身の秘密鍵で委任レシートに署名します。レシートにはスコープ、境界、オペレーター指示（ハッシュ化）、および時間枠が含まれます。実行前検証器が提案された各アクションをレシートと照合し、追記専用のアクションログが実行された内容を記録します。その結果が証拠となります。何が承認され、何が実際に行われたかの差分です。
これは悪意あるオペレーターに対するセキュリティ制御ではありません。検証器はエージェントと同じプロセスで動作し、不正なオペレーターは単にそれを呼び出さないようにできます。同じランタイム内部からこれを修正できる暗号学的特性は存在しません。AuthProofはゲートを実行するデプロイメントに対して承認を証明し、監査者、規制当局、ユーザーに対して事後に検証可能な記録を提供します。
他との違い:
ユーザーが署名権限者である。 承認オブジェクトはオペレーター管理のポリシーに書き込まれるのではなく、ユーザーの秘密鍵で署名されます。レシート内の署名済みスコープとプログラムハッシュは、常にオペレーターのログメタデータよりも優先されます。オペレーターメタデータが署名済みレシートと矛盾する場合、ゲートはメタデータに従うのではなくアクションを拒否します。
二段階のモデル状態コミットメント。 モデルは承認時に測定され、実行前に再測定されます。これらの測定値はソフトウェアで計算された自己証明であり、ハードウェアにルートを持ちません。これらは誠実なデプロイメントに対する改ざん証拠であり、敵対的なホストに対する証明ではありません。
プロバイダー更新と悪意ある置換の区別。 モデル状態の変化は、正当なプロバイダー更新（PROVIDER_UPDATE_REQUIRES_REAUTH）と不正な差し替え（MALICIOUS_MODEL_SUBSTITUTION）に分類されます。それぞれが、どのコンポーネントが変更されたかを識別する機械可読な拒否理由コードを生成します。
エージェントのアクションが実行される前に動作するゲート。
PreExecutionVerifier.check() は、提案された各アクションを署名済み委任レシートと照合して検証します。エージェントのプロセス内で、アクションが実行される前にすべてのアクションをこれに通してください。検証器は自身の許可/拒否の決定を監査ログに署名するため、すべての結果が記録の一部となります。
前提として受け入れるべき厳しい事実が一つあります。検証器は同一プロセスです。それは証明を検証しますが、呼び出しを拒否するオペレーターを止めることはできません。コードを実行するオペレーターに対する強制が必要な場所ではなく、証拠が欲しい場所で使用してください。
今日のエージェント承認のほとんどは、オペレーターの言葉に依存しています。オペレーターが書いたポリシーを、オペレーターが管理するコードで強制するものです。何か問題が起きたとき、ユーザーが実際に何を承認したかの記録はなく、オペレーターによるその再構成があるだけです。AuthProofはこれを覆します。ユーザーの署名済みレシートは実行に先行し、アクションログはそれに対して実行された内容を記録します。「ユーザーはこれを承認したのか?」という問いは、議論の対象ではなく検証可能なものになります。
import { PreExecutionVerifier, DelegationLog } from 'authproof-sdk/pre-execution-verifier'
import { RevocationRegistry } from 'authproof-sdk'
// 1. Set up the gate
const delegationLog = new DelegationLog()
const revocationRegistry = new RevocationRegistry()
await revocationRegistry.init({ privateKey, publicJwk })
const verifier = new PreExecutionVerifier({ delegationLog, revocationRegistry })
await verifier.init({ privateKey: verifierKey, publicJwk: verifierPub })
// 2. Register your delegation receipt
delegationLog.add(receiptHash, receipt)
// 3. Gate every action â before the agent runs
const result = await verifier.check({
receiptHash,
action: { operation: 'read', resource: 'calendar' },
operatorInstructions: 'Summarize meetings. Stay within scope.',
programHash, // optional: prevents code substitution attacks
})
if (!result.allowed) {
throw new Error(`Blocked: ${result.blockedReason}`)
}
// Agent runtime only reaches here after all thirteen checks pass
| # | チェック | ブロック条件 |
|---|---|---|
| 1 | レシート署名 | ECDSA P-256 署名が無効、またはレシートが改ざんされている |
| 2 | 失効 | レシートが RevocationRegistry 経由で失効している (カスケード: 失効した祖先はその子孫を拒否する) |
| 3 | 時間枠 | レシートが期限切れ、またはまだ有効でない (クライアントクロックではなくログタイムスタンプオラクル) |
| 4 | スコープ | アクションが ScopeSchema.allowedActions に含まれていない。構造化スキーマがない場合、キーワードマッチングは助言的のみで、決してゲートしない |
| 5 | オペレータ指示 | 提供された指示が発行時にレシートにロックされたハッシュと一致しない。呼び出し元が省略した場合は警告付きでスキップされる |
| 6 | プログラムハッシュ | 提供された programHash がコミットされた executes ハッシュと一致しない (オプション) |
| 7 | セッションリスク | 信頼/リスク閾値を超えている (オプション) |
| 8 | ツールスキーマ整合性 | toolSchemaHash がレシートと一致しない (オプション) |
| 9 | モデル状態 | モデルドリフトが検出された (オプション; ソフトウェア計算による自己申告測定) |
| 10 | ツール出力ハッシュバインディング | 出力ハッシュがレシートと一致しない (オプション) |
| 11 | 指示の来歴 | 指示ソースがレシートの trustedSources に含まれていない (オプション) |
| 14 | 親スコープ封じ込め | サブレシートが親のスコープを超えている (サブレシートのみ); 任意の祖先を失効させると、チェック時に子が拒否される |
| 15 | 権限状態ドリフト | authorityStateCommitment が発行以降にドリフトしている (オプション) |
スロット 12 と 13 は実装されたことがなく、番号の欠番は歴史的なものです。ゲートは最初に失敗したチェックで停止します。ワンタイムユースの消費はすべてのチェックが通過した後に最後に実行されるため、別の理由で拒否されるレシートで消費スロットが無駄に消費されることはありません。
すべてのチェック結果は、合格・不合格を問わず、検証者自身の鍵で署名された不変の ActionLog に自動的に記録されます。
署名済みデータが優先されます。 署名済みレシートのスコープとプログラムハッシュは、常にオペレータログのメタデータよりも優先されます。署名されていない DelegationLog メタデータが署名済みレシートと矛盾する場合、ゲートはアクションを拒否します (SCOPE_METADATA_MISMATCH / PROGRAM_METADATA_MISMATCH)。ログメタデータは、レシートに構造化スコープまたは署名済み executes 値が含まれていない場合にのみフォールバックとなります。
ガイド付き委任は観察によって導かれます。 ScopeDiscovery.guided() と AuthProofClient.delegateGuided() は observe → generateScope → approve → finalize を 1 回の呼び出しで実行し、観察されたドラフトスコープ全体が人間のレビューなしで自動承認されます。真の人間による承認の瞬間を得るには、reviewDraft フックを渡すか (発行前にドラフトを承認、修正、または拒否する)、明示的な approve() を伴う各ステップを個別に実行してください。
一般的なフレームワーク向けのドロップインラッパー。各ラッパーは、ラップされたコードが実行される前に、すべての呼び出しを PreExecutionVerifier 経由でゲートします。
invoke() メソッドを持つ任意のエージェントをラップします// LangChain
import { authproofMiddleware } from 'authproof-sdk/middleware/langchain'
const guardedAgent = authproofMiddleware(agent, { receiptHash, verifier })
// Express
import { authproofMiddleware } from 'authproof-sdk/middleware/express'
app.use(authproofMiddleware({ verifier, getReceiptHash: (req) => req.headers['x-receipt-hash'] }))
// Any function
import { guardFunction } from 'authproof-sdk/middleware/generic'
const guardedExecute = guardFunction(executeAction, { receiptHash, verifier, action })
AuthProof があなたにとって何を証明するかを判断する前に、これを読んでください。
ScopeSchema がない場合、スコープマッチングは可観測性のために記録されるキーワード重複シグナルです。許可や拒否を行うことはありません。実際のスコープ強制には ScopeSchema が必要です。operatorInstructions を渡してください。ConsumptionStore が必要です（Redis アダプタが含まれています）。これがないと、プロセス間のリプレイ検出は保証されません。エージェントアイデンティティに関する既存の IETF フレームワーク â AIP、draft-klrc-aiagent-auth、WIMSE â はすべて、サービス対エージェントの信頼を扱っています。つまり、下流のサービスがエージェントに呼び出し権限があることをどのように検証するかです。これらのいずれも ユーザー対運用者の信頼 を扱っていません。
現在のエージェントシステムにおける委任チェーンは次のとおりです:
User â Operator â Agent â Services
ユーザーはオペレーターに指示を出す。オペレーターはエージェントに指示を出す。しかし、委任の瞬間にユーザーの元の意図を記録した暗号学的な記録は存在しない。オペレーターは、ユーザーの指示がエージェントに届く前に、それを拡大、歪曲、または省略する無制限の権限を持つ信頼された第三者となる。
その結果:
AuthProofはこのギャップを埋める。
委任レシートとは、エージェントのアクションが始まる前に、分散型の追記専用ログに固定された署名済みの認可オブジェクトである。これには4つの必須フィールドが含まれる:
許可された操作の明示的な許可リスト。リストにないものはすべてデフォルトで拒否される。自然言語ではなく、構造化された形式で表現される。操作クラス:
| クラス | 説明 |
|---|---|
reads | 指定されたリソースへの読み取りアクセス |
writes | 指定されたリソースへの書き込みアクセス |
deletes | 指定されたリソースの削除 |
executes | 特定のプログラムの実行。その静的ケイパビリティ署名ハッシュによって参照される |
executesは最も危険なクラスである。名前、URI、または説明ではなく、Safescriptプログラムの静的ケイパビリティDAGの暗号学的ハッシュを参照しなければならない。ハッシュが一致しなければ実行されない。
いかなる状況下でもオペレーターの指示によって上書きできない明示的な禁止事項。その後のオペレーターの指示を経ても存続する、ユーザー定義のハードリミット。
認可の有効期間。ログのタイムスタンプが時間のオラクルであり、クライアントの時計ではない。クライアントの時計は時間検証から明示的に除外される。
委任時点におけるオペレーターの表明された指示の暗号学的ハッシュ。オペレーターがその後エージェントに異なる指示を出した場合、その不一致は追加の信頼前提なしにログから検出可能である。