Proof of Actor の仕組み。
incoming interaction から application decision までの evidence-first な path。
- /api/v1/catalogenforceエージェント許可 · 構造化 API
- /support/ticketsenforce人間 + AI許可 · AI-assisted とラベル付け
- /account/*preview不明既存の checks を維持する
- /api/v1/orderspreviewエージェントより強い認証情報を要求する
interaction から decision へ
- 01アプリケーションの request または eventページ閲覧、API 呼び出し、MCP ツール呼び出し、またはアプリ内操作。
- 02サポート対象の統合からのシグナルその integration がその context で観測できる内容のみです。
- 03evidence の正規化と classificationシグナルは確認され、根拠ごとにラベル付けされ、統合されます。
- 04根拠と不確実性を伴う Actor 結果Human, Human + AI, Agent or Unknown、そしてその根拠。
- 05Dashboardと分析team が review するための trends, routes, evidence。
- 06アプリケーション自身の判断観測のみ、または選択した policy を適用します。
What your code receives
Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.
{
"route": "GET /api/v1/catalog",
"class": "agent",
"basis": "verified",
"evidence": [
{ "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
{ "signal": "client_declaration", "value": "assistant.example" }
],
"observed_at": "2026-11-13T10:42:07Z"
}- class
- Human, Human + AI, Agent, Unknown。
- basis
- 証拠の強さです: Verified, Declared, Inferred, Unknown。
- evidence
- 結果の背後にあるsignalsです。理由をチームが確認できます。
observation modeから始めます。結果をlogの横に記録し、policyを選ぶまで何も変更しません。 Node.js integration guideを読む
observation modeが既定です
Proof of Actorを導入しても、いかなるrequestもブロックしたり変更したりしません。結果は記録されるため、チームは実際のapplicationの結果と比較し、false positiveを確認し、どのpolicyが適切かを判断できます。
証拠の種類
利用できる証拠は、統合方法とcontextによって異なります。各workflowの確認内容はオンボーディング時にチームと合意し、signalの内部は模倣しにくいよう非公開のままにします。
リクエスト署名
キーを公開する自動クライアントからの暗号署名。
申告
自らをエージェントと名乗るクライアント、またはアプリ内での AI 支援の開示。
interaction signals
承認済みのブラウザコレクターから、そのコレクターが実行されるページ上でシグナルを取得します。
リクエストコンテキスト
サーバーサイド統合で利用できるヘッダーとプロトコルの詳細。
routing decision の位置づけ
application は Proof of Actor を呼び出し、result を受け取り、独自の rule を適用します。route と risk tier ごとに、integration を fail open にするか つまり Proof of Actor がない場合と同じように request を進めるか、fail closed にするか つまり既存のより強い check を適用するかを選べます。
API タイムアウト
結果が時間内に得られない場合、その統合はそのルートで選択したフォールバックを使用します。タイムアウトがHumanの結果になることはありません。
telemetry 不足
ブラウザコレクターが実行されなかった、または信号が欠落している場合、結果はその状態を反映します。証拠の欠落は言える内容を減らしますが、疑わしいものとして扱われることはありません。
Unknown の classifications
Unknown は通常の結果です。policy が各 route における Unknown の意味を定義します。たとえば、public pages は allow し、account changes では既存の checks を維持します。
古い証拠
evidence には時間と scope があります。session の前半で得られた result を、より機微な後続 action に fresh check なしで再利用すべきではありません。
beta統合workflow
- 01適用app と、理解したいインタラクションについて教えてください。
- 02対象範囲統合、ルート、利用制限、データ取り扱いについて合意します。
- 03観測モードで統合するapp の応答は変わりません。
- 04検証する既知の正解データと結果を比較します: カバレッジ、Unknown率、誤検知、レイテンシ。
- 05決定するevidence が裏付ける場合にのみ policy を有効化します。
Founding Teams で測定する内容