Proof of Actorで確認できることと、できないこと。
分類、その背後にある evidence、適用される context、そして設計上の制約を平易に説明します。
- リクエスト署名valid · sample-crawler.exampleverified
- クライアント宣言"research-assistant/2.1"declared
- ブラウザでの対話pointer + keyboard eventsinferred
- サポートされる signal なしroute not instrumentedunknown
要点
| Proof of Actor が示せること (対応している場合) | 保証できないこと |
|---|---|
| 対応するエージェントリクエスト署名が検証されるかどうか | エージェントが正直で、安全で、いかなる操作も許可されていること |
| セッションが特定の対話シグナルまたは自動化シグナルを露出しているかどうか | 人間が、観測可能な統合の外で AI を使用していないこと |
| 対応ワークフローで AI の利用が申告されたか、または観測可能だったか | AI assistance, copied content, または別の device の universal detection |
| その証拠では不十分だったこと | 未知のインタラクションが悪意あるものであること |
利用可否は、あなたの統合と有効化されたチェックに依存します。適用判断の नियंत्रणは、アプリケーションの所有者が保持します。
分類
4 つの public class。それぞれに定義された意味と明示的な限界があります。
- 人間
サポートされている観測可能なシグナルは、人間が主導する操作を示しています。
意味しないこと: AI が使われていないこと、またはその人の実世界での身元が確認済みであること。
- 人間 + AI
AI 支援が宣言されたか、実際にそれを観測できる対応済み統合によって検知されました。
意味しないこと: 別のタブや別のデバイスを含め、隠れた AI 利用のすべてを検出できること。
- エージェント
検証可能な identity または慎重に条件付けられた推論によって裏付けられた、自動化または agent 起点の interaction。
意味しないこと: エージェントが認可されていること、安全であること、または人からの有効な委任のもとで動作していること。
- 不明
利用可能な証拠では、信頼できる判断はできません。
意味しないこと: そのインタラクションが疑わしい、または悪意があること。
Verified、Declared、Inferred、Unknown
すべての result には basis があります。class が inference を cryptographic verification であるかのように見せることはなく、これは security-sensitive な application で特に重要です。
- verified
- 検証済み. たとえば公開済み鍵に対するリクエスト署名のような、暗号学的または別の方法で検証可能な主張。これはその確認のみを証明するもので、それ以上ではありません。
- declared
- 申告済み. アクターまたはあなたのアプリケーションがそう述べたものです。たとえば、AI 支援の開示や、自らをエージェントと名乗るクライアントです。宣言が真実でない場合もあります。
- inferred
- 推定. 行動的または文脈的な信号から導かれた結論。推定は誤ることがあり、常に推定として表示されます。
- unknown
- 不明. 判断に足る evidence がありません。推測せず、結果は Unknown として報告されます。
信頼度の数値に検証済みで調整されたモデルが必要になる場合、代わりに定性的な証拠の強さを用います。測定と説明がなされていない限り、99.7% human のような数値は表示されません。
対応するcontextとその制限
ブラウザ
ブラウザコレクタは、実行されているページ上の対話セッションを確認できます。JavaScript を実行しないクライアント、他のタブやアプリケーションやデバイスでの操作、または人が別の場所からコピーして入力したテキストは確認できません。
サーバーと API
サーバーサイド統合はリクエストのコンテキストを確認でき、クライアントが対応している場合はリクエスト署名も確認できます。人の画面は確認できず、ほとんどの未署名クライアントは自分自身を任意に名乗ることができます。
MCP
MCP server は、クライアントの宣言済み詳細と、そのクライアントが行う tool 呼び出しを把握します。宣言されたクライアント名は、verification ではなく declaration です。
理解しておくべき2つの制限
別の tab または device で生成された AI text
人が別のタブや自分のスマートフォンでチャットボットに質問し、その答えをフォームに貼り付けても、通常のウェブトラフィックには通常それが何も現れません。セッションは人間主導に見えます。なぜなら、人間がそれを主導したからです。
Proof of Actor は、支援が Declared された場合、またはアプリの独自アシスタント機能のように実際にそれを確認できる対応済み統合によって観測された場合にのみ Human + AI と報告します。
署名付きbot requestが示すこと
公開済みの key に対して検証できる HTTP message signature は、その request が、オペレーターのドメインのようなその identifier に関連付けられた key で署名されたことを示します。
これは、リクエストの背後にいる人物の実世界での本人性、その人物に権限が委任されているかどうか、またはその行為が安全か許可されているかどうかを示すものではありません。この分野の標準化は、IETF Web Bot Auth の作業を含め、まだ Internet-Drafts の段階です。
既定のblockingなし
Proof of Actor は既定では何もブロック、拒否、チャレンジしません。推定されたアクター結果だけを理由にブロックや拒否をすることは推奨しません。特に、その結果だけに基づいて、人に関する重大な判断（雇用、信用、金融サービス、教育、または生活に不可欠なサービスへのアクセス）を下すことは避けるべきです。
enforcement は、team が選択し確認した policy の下で、application 内で行われます。Unknown と timeout には明示的な fallback があります。
Unknownと棄権
証拠が信頼できる判断を支えない場合、結果は Unknown になります。Unknown が Human に変換されることはなく、怪しいことを意味するわけでもありません。これを可視のままにしておくと、どこまでをカバーできているかが分かり、何かを enforce する前に必要な情報が得られます。
privacyとgovernanceのprinciple
目的の限定
evidence は application owner に interactions を説明します。cross-site profile の構築には使用されません。
最小限の収集
各 integration は、その context に必要なものだけを収集します。sensitive telemetry には明示的な opt-in が必要です。
テナント分離
ある customer の evidence は、別の customer には一切表示されません。
設定可能な保持期間
保持期間は、オンボーディング中に各創業チームと合意します。
顧客管理のアクセス
証拠と結果を、チームの誰が見られるかは、あなたが決めます。
identity checks なし
biometric collection も identity verification も Proof of Actor には含まれません。
すべての team と合意済み
performanceとmethodology
coverage、unknown rate、false positive、calibration は、各対応 context において founding team とともに、team がすでに把握している outcome を基準に測定されます。methodology と result は、各 context の成熟に応じてここで公開されます。
プライバシーやセキュリティについてご質問ですか? [email protected]