AuthProof SDK

AuthProof はエージェント型AIのための暗号化委任プロトコルです。この分野のほとんどのプロトコルは、オペレーターが定義したポリシーに基づいて強制を行います。つまり、オペレーターはユーザーの本来の意図を後から拡大または再解釈する権限を持ちます。AuthProof は異なる信頼モデルに基づいて構築されています。ユーザー自身の秘密鍵が実行をゲートする認可オブジェクトに署名し、ライブモデルの状態が認可時と実行直前の両方で検証されます。ユーザーが署名した権限とライブモデル状態によるゲーティングの組み合わせが、このプロトコルの具体的な主張であり、広範な強制の話ではありません。

何が違うのか:

ユーザーが署名権限者です。 競合するすべてのプロトコル（AIP、AITH、OAP、SAGA、AgentSpec）は、オペレーターが定義したポリシーに基づいて強制を行います。AuthProof では、ユーザーの秘密鍵が直接認可オブジェクトに署名します。ユーザーが署名した後、オペレーターがスコープを拡大することはできません。
2フェーズのモデル状態コミットメント。 モデルは認可時に測定され、実行直前に再測定されます。認可時と実行時の間でモデルが変化した場合、実行は事前検証でブロックされます。
プロバイダ更新と悪意ある置き換えの区別。 このプロトコルはモデル状態の変更を2つのカテゴリに分類します。正当なプロバイダ更新（PROVIDER_UPDATE_REQUIRES_REAUTH）と不正な置き換え（MALICIOUS_MODEL_SUBSTITUTION）です。それぞれ、どのコンポーネントが変更されたかを識別する機械可読な拒否理由コードを生成します。

事前実行検証器

エージェントのアクションが実行される前に動作する決定論的ゲート。

PreExecutionVerifier はエージェントランタイムの外部に配置されます。検証が成功するまでランタイムは制御を取得できません。侵害された、または悪意のあるエージェントでもこれをスキップすることはできません。ランタイムが起動する前に実行されます。

なぜ重要なのか

従来の認可チェックはエージェントランタイム内部で行われます。ランタイムが侵害されると、これらのチェックはスキップ、並べ替え、またはバイパスされる可能性があります。PreExecutionVerifier は認可をランタイムの完全に外部に移動することで、この攻撃対象領域を排除します。エージェントは、6つすべての逐次チェックが最初に成功した場合にのみ実行されます。

クイックスタート```js

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 six checks pass

### 6つの逐次チェック（最初の失敗で停止）

| # | チェック | ブロックされる条件 |
|---|-------|-------------|
| 1 | レシート署名 | ECDSA P-256 署名が無効、またはレシートが改ざんされた場合 |
| 2 | 失効 | `RevocationRegistry` を介してレシートが失効された場合 |
| 3 | 時間枠 | レシートの有効期限切れ、またはまだ有効でない（クライアントクロックではなくログタイムスタンプオラクル） |
| 4 | スコープ | アクションが `ScopeSchema.allowedActions` にない、またはテキストベースのスコープマッチングに失敗した場合 |
| 5 | オペレーター指示 | 現在の指示が発行時にレシートにロックされたハッシュと一致しない場合 |
| 6 | プログラムハッシュ | 提供された `programHash` がコミットされた `executes` ハッシュと一致しない場合（コード置換防止） |

各チェック結果（合格または不合格）は、検証者の自身のキーで署名された不変の `ActionLog` に自動的に記録されます。

### ミドルウェア統合

一般的なフレームワーク用のドロップインラッパー。各ラッパーは、ラップされたコードが実行される前に、すべての呼び出しを `PreExecutionVerifier` を通過させます。

- **[LangChain](https://github.com/commonguy25/authproof-sdk/blob/main/src/middleware/langchain.js)** — `invoke()` メソッドを持つ任意のエージェントをラップします
- **[Express/HTTP](https://github.com/commonguy25/authproof-sdk/blob/main/src/middleware/express.js)** — 任意の Express 互換フレームワーク用のリクエストミドルウェア
- **[汎用関数ラッパー](https://github.com/commonguy25/authproof-sdk/blob/main/src/middleware/generic.js)** — 任意の非同期関数をラップします```js
// 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 })

問題点

既存のIETFエージェントアイデンティティフレームワーク â AIP、draft-klrc-aiagent-auth、WIMSE â はすべて、サービス対エージェントの信頼を扱っています。つまり、下流のサービスがエージェントが呼び出しを許可されているかを検証する方法です。これらのどれも、ユーザ対オペレータの信頼 には対応していません。

現在のエージェントシステムにおける委任チェーンは次のとおりです:``` User â Operator â Agent â Services

ユーザーはオペレーターに指示を出す。オペレーターはエージェントに指示を出す。しかし、委任の瞬間にはユーザーの本来の意図の暗号学的記録は存在しない。オペレーターは、ユーザーの指示がエージェントに届く前に、それを拡大、歪曲、または省略する無制限の権限を持つ信頼された第三者となる。

その結果：

- ユーザーは自分が何を承認したかを証明できない。
- 規制当局には監査証跡がない。
- 裁判所には証拠連鎖がない。
- エージェントは、正当なオペレーター指示と侵害された、または不正な指示を区別できない。

AuthProofがこのギャップを埋める。

---

## コアプリミティブ：委任領収書

**委任領収書**は、エージェントの行動が開始される前に、分散型追記専用ログに固定された署名済み認可オブジェクトです。これには4つの必須フィールドが含まれます：

### スコープ

許可された操作の明示的な許可リスト。リストにないものはすべてデフォルトで拒否されます。自然言語ではなく構造化形式で表現されます。操作クラス：

| クラス | 説明 |
|---|---|
| `reads` | 指定されたリソースへの読み取りアクセス |
| `writes` | 指定されたリソースへの書き込みアクセス |
| `deletes` | 指定されたリソースの削除 |
| `executes` | 特定のプログラムの実行。その**静的機能シグネチャハッシュ**によって参照される |

`executes`は最も危険なクラスです。名前、URI、説明ではなく、Safescriptプログラムの静的機能DAGの暗号学的ハッシュを参照する必要があります。ハッシュが一致しない場合、実行は行われません。

### 境界

明示的な禁止事項。いかなる状況でもオペレーター指示によって上書きできません。その後のオペレーター指示に関係なく存続するユーザー定義のハードリミット。

### 時間枠

認可の有効期間。**ログタイムスタンプ**が時刻のオラクルであり、クライアントクロックではありません。クライアントクロックは時間検証から明示的に除外されます。

### オペレーター指示ハッシュ

委任時のオペレーターの表明された指示の暗号学的ハッシュ。オペレーターがその後エージェントに異なる指示を出した場合、その不一致は追加の信頼前提なしにログから検出可能です。

ユーザーは、WebAuthn/FIDO2を介してデバイスのセキュアエンクレーブを使用し、自身の秘密鍵でこのオブジェクトに署名します。署名はエージェントの行動前にログに公開されます。その後のすべてのエージェント行動はレシートハッシュを参照します。スコープ外の行動は暗号学的に無効です。

---

## 信頼スタックアーキテクチャ

3つのプロトコル層が3つの信頼された第三者を排除します：

### レイヤ1 — 署名済み機能マニフェスト（レジストリへの信頼を排除）

現在のMCPエコシステムでは、ツールサーバーの説明が実際の動作と一致するという暗号学的証明はありません。オペレーターは任意のスキーマを提示できます。

修正：ツールサーバーは、ユーザー認可が行われる前に、暗号学的に署名された機能マニフェストを公開します。委任領収書の`scope`フィールドは、オペレーターの自己申告スキーマではなく、**このマニフェストのハッシュ**を参照します。サーバーの動作とマニフェストの乖離はログ層で検出可能です。

### レイヤ2 — 委任領収書（オペレーターへの信頼を排除）

ユーザーの本来の意図は、オペレーター指示がエージェントに届く前に不変に記録されます。オペレーターの逸脱は証明可能です。

### レイヤ3 — Safescript実行（コードへの信頼を排除）

[Safescript](https://github.com/safescript)は、AIエージェント実行のためのオープンソースのサンドボックス言語です。その静的DAG構造により、すべてのプログラムの完全な機能シグネチャが実行前に計算可能です。動的ディスパッチや実行時機能拡張はありません。

`executes`スコープクラスは特定のSafescript機能シグネチャハッシュを参照します。オペレーターが提供したプログラムがコミットされたハッシュと一致しない場合、実行はブロックされます。委任後にエージェントが別のプログラムに置き換えられることはありません。

---

## クイックスタート```js
import { AuthProof, Scope, KeyCustody } from 'authproof-sdk';

// Initialize with hardware-backed key custody (recommended)
const authproof = new AuthProof({
  custody: KeyCustody.HARDWARE, // WebAuthn/FIDO2 via device secure enclave
  log: 'https://log.authproof.dev',
});

// Define permitted operations â explicit allowlist, deny-by-default
const scope = new Scope()
  .allow('reads',  ['resource://calendar/events', 'resource://email/inbox'])
  .allow('writes', ['resource://calendar/events'])
  .deny('deletes', '*')
  .execute('sha256:a3f1c9d8...', { program: 'scheduler-v1.sg' }); // Safescript hash

// Hard limits that survive any operator instruction
const boundaries = {
  never: ['external-network', 'credential-store', 'payment-methods'],
};

// Issue the Delegation Receipt â anchored to log before any agent action
const receipt = await authproof.delegate({
  scope,
  boundaries,
  window: { duration: '8h' },           // validated against log timestamp
  operatorInstructions: instructionText, // hashed and committed
});

// receipt.id    â unique receipt identifier
// receipt.hash  â reference in every agent action
// receipt.log   â append-only log anchor

// Agent-side: validate an action against the receipt
const check = await authproof.validate({
  receiptHash: receipt.hash,
  action: { class: 'writes', resource: 'resource://calendar/events' },
});

if (!check.authorized) {
  // Out-of-scope action: surface a micro-receipt request to the user
  const microReceipt = await authproof.requestMicroReceipt({
    action: check.requestedAction,
    parent: receipt.hash,
  });
}

動的認可: マイクロレシート

元の委任レシートの対象外となるツール呼び出しでは、エージェントは黙って処理を進めることはできません。プロトコルは以下を義務付けています:

エージェントがスコープ外の機能要件を特定する。
エージェントが特定のアクションを説明する機能リクエストをユーザーに提示する。
ユーザーがそのアクションのみを対象とするマイクロレシートに署名する。
エージェントはマイクロレシートのハッシュを参照して処理を進める。

authproof-sdk

人気

AuthProof SDK

事前実行検証器

なぜ重要なのか

クイックスタート```js

問題点

動的認可: マイクロレシート