InterAI Risk Oracle

InterAI Risk Oracle

重大なエージェントアクションの実行前に判断する、独立したレイヤーです。

エージェントが実行する前に、InterAI が検証します。

私は Alejandro Bolognese です。InterAI Labs を通じて InterAI を開発し、エージェントインフラストラクチャ、実行制御、信頼境界、本番システムに関する取り組みを継続しています。

実証デモ： Action Boundary Lab · 制御された安全なデモ · アーキテクチャと権限境界 · OpenAPI

InterAI は、自律型エージェントと重大なアクションの間に位置します。エージェントが実行したい内容を提案すると、InterAI はそのアクションをコンテキストに照らして評価し、権威あるホスト／アカウントの制約と、リクエスト単位の呼び出し元の制約を適用して、機械可読な権限判断を返します。

proposed action
      |
      v
   InterAI
      |
      +--> ALLOW
      +--> REVIEW_REQUIRED
      +--> BLOCK
      |
      v
 signed trust receipt

重要なのは、単に このプリンシパルが技術的にアクションを実行できるか？ ということではありません。

この特定のアクションを、このコンテキストで、このポリシーのもと、今実行すべきか？

そのため InterAI は、認証、権限、支出上限、ワークフロールール、ドメイン固有の制御に取って代わるのではなく、それらを補完します。

InterAI の位置づけ

Identity / authentication
  "Who is this?"
        |
Permissions / deterministic limits
  "Can this principal do this class of operation?"
        |
InterAI
  "Should this exact proposed action execute in this context?"
        |
Execution / escalation / abort

ツールの実行、資金の移動、本番環境の状態更新、ワークフローの承認、ウォレットアクションへの署名、外部へのメッセージ送信、またはその他の取り消し不能もしくはコストを伴う操作など、エージェントが実際の影響を伴う操作を実行しようとしているときに、InterAI を使用します。

判断コントラクト

自律実行リクエストに対する InterAI の主要な権限コントラクトは、次のとおりです。

• recommended_action：allow、review_required、または block
• policy_result：有効なポリシーに基づく権限判断の結果
• policy_violations：該当する場合の明示的なポリシー違反
• trust_receipt_id：永続的な判断の証拠
• execution_intent_digest：評価対象となった正確な意図を識別する決定的な識別子
• 認証済み判断レシートに含まれる、有効なホスト／アカウント／呼び出し元ポリシーの来歴情報

review_required は、現在のポリシーのもとでは、現在のエージェントが自律的に実行すべきではないことを意味します。レビューは、スーパーバイザーエージェント、ポリシーシステム、ガバナンスキュー、ウォレットルール、または人間のオペレーターが行えます。

アクションの厳密なバインディング

実行可能なパイロット認可では、ホストが信頼できるアクションエンベロープ interai-canonical-action/v1 と、ホストが証明する実行コンテキスト interai-host-execution-context/v1 を構築します。InterAI は CanonicalExecutionIntent（interai-canonical-execution-intent/v2）、execution_intent_digest、および認証済みの allow の場合に限り ExecutionAuthorization（interai-execution-authorization/v1）を返します。ホストはレシートを検証し、副作用が発生する直前に最終的な呼び出しを再構築して、正規ダイジェストを再計算し、認可を検証したうえで、不一致があればフェイルクローズしなければなりません。ツール、引数、権限を持つアクター、実行、ワークスペース、環境、リソース／宛先、または関連するポリシーに変更があれば、以前の allow は無効となり、新たな判定が必要です。review_required と block は認可を行いません。

実行認可は1回限りで、有効期間は1～300秒です（デフォルトは60秒）。InterAI は外部ランタイム全体にわたる普遍的な分散リプレイ防止機能を提供しません。この保証が必要な場合、ホストは認可を原子的かつ永続的に消費しなければなりません。

レビューによってアクションが変更された場合、それは新たに提案されたインテントです。Pydantic AI では、proposal → review/override → final validation → InterAI → exact-intent check → execute の順に処理します。最終検証と InterAI に渡す前に、ToolApproved.override_args を適用してください。

現在のホステッドベータ版では、score、risk_level、機械可読な signals も返されます。これらのフィールドは現在の互換性対象の一部であり、診断や既存の統合に役立ちますが、基本的な認可契約と見なすべきではありません。実行境界は、有効なポリシーに基づく最終的な allow / review_required / block 判定です。

ポリシーの権限境界

ホステッド認証済み自律実行では、厳格な権限順序に従ってポリシーを組み合わせます。

HOST -> ACCOUNT -> CALLER -> EFFECTIVE

• ホストポリシーは、InterAI が管理する、緩和できない最低基準です。
• アカウントポリシーは、アクションリクエストの外部に保存されるバージョン管理されたプロファイルで、ベアラー認証情報がアカウントに解決された後にのみ適用されます。
• 呼び出し元ポリシーはリクエスト単位の制限を追加できますが、ホストまたはアカウントの要件を緩和することはできません。
• 有効なポリシーは、判定に使用する、より厳格なポリシーの組み合わせです。

アカウントポリシーの管理は、現在InterAI が管理するコントロールプレーンです。これは現時点では、顧客自身によるポリシー管理、委任されたテナント管理、またはエンタープライズ向けポリシー管理製品ではありません。

アカウントを持たない／x402 による実行では解決対象となるアカウントプロファイルがないため、引き続き HOST -> CALLER -> EFFECTIVE の順序となります。

外部エビデンス

InterAI は、外部システムが生成した検証可能なアサーションを、実行権限をそれらのシステムに移譲することなく受け入れられます。

外部エビデンス。内部の権限。

プロバイダーがアサーションを行い、InterAI が権限を決定します。

この境界は意図的に設けられています。

external provider
      |
      | signed / verifiable assertion
      v
   InterAI
parse -> verify -> bind -> record

現在のステージ2のエビデンスは、検証され、関連付けられたうえで、権限を持たない外部エビデンスとして記録されます。これは InterAI の実行判定や現在の互換性リスクシグナルを変更しません。

プロバイダーの判定は、InterAI による実行指示ではなく、引き続きアサーションです。上流の PASS、CAUTION、または BLOCK が、InterAI 内で直接 ALLOW、REVIEW_REQUIRED、または BLOCK になることはありません。

この分離が重要なのは、エビデンスと権限が異なる責務だからです。特化したシステムは、世界について価値ある情報を持っていても、自律的なアクションの実行が認可されるかを決定するシステムになるわけではありません。

現在の外部エビデンスの境界は、意図的に限定されており、権限を持ちません。ライブでの参照解決や、将来の権限を伴うモードは、現在の契約を暗黙に拡張するのではなく、別途、信頼境界に関する決定を必要とします。

docs/external-evidence.md と docs/architecture.md を参照してください。

Insight ↔ InterAI

相互運用性を検証済み

Insight と InterAI は、凍結された external-evidence/v0 rev6 コントラクトに対する相互運用性を、それぞれ独立して実装し、相互検証しました。この結果は、ドメイン固有のプロバイダーが署名付き証拠を生成し、InterAI がそれを独立して検証、紐付け、権威を持たない外部証拠として記録できることを示しています。その際、プロバイダーによる主張と InterAI の実行権限との分離が保たれます。

これは、独立して実装された技術的な相互運用性の成果です。Insight と InterAI の間に、本番環境での提携や稼働中の依存関係があることを意味するものではありません。

例

{
  "use_case": "agent-before-payment",
  "action": {
    "type": "payment",
    "name": "release_vendor_payment",
    "description": "Release payment to a vendor agent after delivery validation",
    "amount_usd": 125,
    "currency": "USD",
    "irreversible": false,
    "external_side_effect": true
  },
  "context": {
    "agent_id": "agent_123",
    "environment": "production",
    "counterparty_id": "vendor_agent_456",
    "user_confirmation": false
  },
  "policy": {
    "require_trust_receipt": true,
    "amount_usd_limit": 500
  }
}

権限に関する結果の例：

{
  "request_contract": "autonomous_execution",
  "recommended_action": "allow",
  "policy_result": "allow",
  "execution_intent_digest": "sha256-hex-digest",
  "trust_receipt_id": "tr_01JZPUBLICEXAMPLE"
}

ホスト型ベータ版には現在、score や risk_level などの互換性フィールドも含まれています。実行権限の境界を明確にするため、上記では省略しています。

呼び出し側システムは、その後、この権限に関する判断をどのように適用するかを決定します。

ALLOW             -> verify receipt + exact intent + authorization, then execute
REVIEW_REQUIRED   -> route / pause / escalate
BLOCK             -> abort

InterAI はアクションを実行しません。周辺の実行レイヤーで、判断に基づいて処理を振り分け、最終的な完全一致の意図比較を適用する必要があります。

ホスト型ベータ版を試す

アクション境界ラボ — 提案されたアクションを変更し、実際の実行前判断の境界を確認できます。

https://api.interailabs.dev/lab

制御された安全なデモ — 実際の信頼レシートを使用した、制限付きの読み取り専用サンドボックス検証を 1 回実施できます。

https://api.interailabs.dev/demo

ホスト型検証：

curl -sS -X POST https://api.interailabs.dev/verify \
  -H "Authorization: Bearer <interai_credential>" \
  -H "Content-Type: application/json" \
  -H "X-Idempotency-Key: vendor-payment-001" \
  -d '{
    "use_case":"agent-before-payment",
    "action":{"type":"payment","name":"release_vendor_payment","amount_usd":125,"currency":"USD","irreversible":false,"external_side_effect":true},
    "context":{"environment":"production","counterparty_id":"vendor_agent_456","user_confirmation":false},
    "policy":{"require_trust_receipt":true,"amount_usd_limit":500}
  }'

信頼レシート

重大な判断にはすべて、永続的な信頼レシートを生成できます。レシートは、実行前の判断を確認可能にし、再試行、引き継ぎ、ガバナンスシステム、後日の監査にわたって伝達できるよう設計されています。

認証済みの自律型 DecisionReceipt は、ポリシーの出所情報と execution_intent_digest を紐付けます。ExecutionReceipt は、ディスパッチまたは結果に関する、ホスト／ランタイムからの独立した証拠です。DecisionReceipt は判断の証拠であり、ベアラートークンでも、副作用が発生したことの証明でもありません。

現在のレシート署名には HMAC-SHA256 を使用しており、InterAI がサービス側で検証可能です。これにより、認証済みのサービス側の完全性が確保されますが、第三者が InterAI を介さずにオフラインで検証できる、独立した公開鍵署名と同等の保証ではありません。

レシートが証明するのは、その時点で署名済みレシートのペイロードによって認証される内容です。根底にある主張が普遍的に真実であることを証明するものではなく、必要な場合にドメイン固有の管理策や人による確認に代わるものでもありません。

docs/trust-receipts.md を参照してください。

オープンソースツール

公開リポジトリには、toolkit/ に小規模でフレームワークに依存しないツールが含まれています。これらは Apache-2.0 の下で個別にライセンスされており、プロプライエタリな Risk Oracle 判断エンジンとは意図的に分離されています。

• Agent Action Gate — プロバイダーの不確実性がある場合はフェイルクローズし、曖昧さのない allow の場合にのみ実行します。
• Exact Action Binding — JSON 互換の提案アクションに対する変更を、ホスト側で決定論的に検出します。
• Decision Receipts — 所有者認証済みの署名付き証拠を取り込み、実行意図ダイジェストとの完全一致を検証し、不透明な署名済みペイロードを再シリアライズせずに、InterAI のサービス検証エンドポイントを使用します。

パッケージをインストールせずに、スタンドアロンの公開コントラクトを実行できます。

node --test toolkit/*/*.test.mjs

これらのツールが公開するのは、統合／適用ロジックのみです。本番環境の検証、スコアリング、ネイティブの判断ポリシー、課金／ストレージ、署名の内部実装、信頼インテリジェンス、運用システムは非公開のままです。公開ツールの境界 を参照してください。

InterAI はハブ・アンド・スポークモデルを採用しています。このリポジトリは Risk Oracle の製品／コントラクト／SDK のハブとして維持しつつ、安定したツールの一部については、非公開のコアロジックを複製することなく発見しやすさや貢献のしやすさを高めるため、個別の専用リポジトリでも提供する場合があります。

統合インターフェース

InterAI はホステッドサービスとして利用でき、複数の公開インターフェースを通じて発見または呼び出すことができます。

• HTTPS API と OpenAPI 3.1
• npm で公開されている TypeScript SDK：[email protected]（beta dist-tag）
• PyPI で公開されている Python SDK：interai-risk-oracle==0.1.7b0
• MCP リモート
• A2A エンドポイント
• .well-known ディスカバリーメタデータ
• x402 / Base USDC 決済経路
• プリペイド API キー経路

SDK パッケージのバージョン管理は、ホステッドランタイムのバージョン管理とは独立しています。別途ランタイムをリリースするまでは、ホステッドサービスとそのディスカバリーマニフェストは現在のランタイムリリースのままです。

公開済みの SDK をインストールします。

npm install [email protected]
pip install interai-risk-oracle==0.1.7b0

まずはこちらをご覧ください。

• オープンソースツール
• アーキテクチャと権限の境界
• 外部エビデンスの境界
• フレームワーク統合の例
• OpenAI Agents SDK の例
• Mastra の例
• Google ADK の例
• 統合パターン
• テスター向け準備状況
• TypeScript SDK
• Python SDK
• TypeScript ミドルウェアの例
• Python ミドルウェアの例
• 決済前のエージェント
• x402 決済前の InterAI
• ツール実行前のエージェント

現在の製品範囲

InterAI は管理された技術ベータ版です。

現在利用可能な機能：

• 自律的なアクションの検証
• 明示的な allow / review_required / block 判定
• InterAI ホストポリシーの最低基準の適用
• 認証済みアカウント向けのバージョン管理されたアカウント固有の権威あるポリシー
• より上位の権限による制約を厳しくすることしかできない、リクエスト単位の呼び出し元ポリシー
• 検証、紐付け、記録を伴う、権威を持たない外部エビデンスの取り込み
• ホスト／アカウント／呼び出し元／有効なポリシーの来歴を含む、署名付きでサービスによる検証が可能な信頼レシート
• 正規の実行意図ダイジェストと、意図を厳密に一致させるディスパッチ契約
• レシートの公開検索
• 冪等な有料検証。認証済みの判定 ID には、アカウントポリシーのバージョン／ダイジェストが含まれます
• ホステッド OpenAPI、MCP、A2A、および機械可読なディスカバリー
• 公開済みの TypeScript および Python SDK パッケージ

現時点では提供をうたっていないもの：

• 顧客によるセルフサービスまたは委任されたテナントポリシー管理
• 外部エビデンスプロバイダーへの権限委譲
• 外部エビデンスの制限のないライブ参照解決
• 独立して検証可能な公開鍵によるレシート署名
• 外部ランタイム間での、分散型の単回実行または同時リプレイ防止
• 幅広い高トラフィックの本番環境への対応
• エンタープライズ調達への対応
• 万能な事実の真偽保証
• 医療、法律、金融、安全性が極めて重要な分野、その他の専門領域におけるレビューの代替

現在の準備状況の境界については、docs/professional-readiness.md を参照してください。

レガシー互換性

InterAI は互換性のため、従来のプロンプト／レスポンス検証契約も引き続きサポートしています。製品の主な方向性は、autonomous_execution 契約と実行前の判定境界です。

ホステッドベータ版では、現在の実装および既存の統合で使用されているスコア／リスクの互換性フィールドも引き続き提供されます。これらは、InterAI の権限境界を概念的に定義する長期的なものではありません。

リポジトリの境界

この公開リポジトリには、SDK のソース、スキーマ、サンプル、OpenAPI／ディスカバリーメタデータ、Apache ライセンスのオープンソースツール、ホスト型サービスのドキュメントなど、統合に必要な資料が含まれています。

本番環境の検証エンジン、課金インフラ、信頼ロジック、スコアリングの内部処理、ネイティブな意思決定の実装、署名の内部処理、ホスト型サービスの実装は、引き続きプロプライエタリです。

エンジニアリング

InterAI の主張は意図的に限定しています。すべてのエージェントとのやり取りをセキュリティ上の問題として扱うのではなく、重大な処理を実行する前に、明確な権限の境界を構築しています。

エージェントインフラ、実行システム、信頼境界、本番環境の自動化に関する、より広範な取り組みの一環として InterAI を開発しています。相互運用性や実行制御に関する具体的な課題を解決するための、厳選した技術協力やインフラに関する対話を歓迎します。

リンク

• ホスト型ベータ版：https://api.interailabs.dev
• アクション境界ラボ：https://api.interailabs.dev/lab
• 制御された安全なデモ：https://api.interailabs.dev/demo
• 料金：https://api.interailabs.dev/pricing
• オンボーディング：https://api.interailabs.dev/onboard
• OpenAPI：https://api.interailabs.dev/.well-known/openapi.json
• MCP：https://api.interailabs.dev/mcp
• npm：https://www.npmjs.com/package/interai-risk-oracle
• PyPI：https://pypi.org/project/interai-risk-oracle/0.1.7b0/
• サポート／セキュリティ／協力に関するお問い合わせ：[email protected]

レシートのプライバシー（2026年9月）

認証情報なしで GET /trust/receipts/{receiptId} にアクセスした場合、レシート ID と発行時刻を含む public_summary のみが返されます。これは署名済みの証拠でも、実行の承認でもありません。レシートの完全な内容、元の不透明な verification.signed_payload、署名、承認を取得するには、レシートのアカウントに属する有効な Bearer キーを指定してください。無効なキーには 401 が返され、別のアカウントからのアクセスには 404 が返されます。レスポンスをキャッシュしてはいけません。

アカウントを持たない x402／支払い参照クライアントは、元の検証で返された証拠一式を保持する必要があります。公開検索では非公開の内容を復元できません。デモリンクにも公開参照のみが表示されます。レシートの URL に API キーを含めないでください。検証時には署名済みペイロードのバイト列を変更せず、そのまま保持してください。