API key は identity ではなく、identity は permission ではありません。
ほとんどの API traffic は、どの account が支払っているかを示す credential 付きで届きますが、どの client が呼び出しているのか、誰が指示したのかは示しません。request に署名する client もあれば、name を declared するだけのものも多く、何も示さないものも多くあります。
Proof of Actor は、すべての API が答える必要のある3つの問いを分け、それぞれに適切な証拠と制御を与えます。
- 誰が呼び出していますか？Actor の識別: 署名、宣言、または推論
- どの認証情報ですか？お客様のAPI key、OAuth tokenまたはsession
- 何ができますか？認可とポリシー
Proof of Actor は最初の問いに答えます。残りの2つはあなたのスタックに残ります。
API チームがアクターコンテキストで行うこと
署名済みクライアントを識別する
公開されたキーに対してリクエスト署名を照合し、どのオペレーターに属するリクエストかを確認します。
declared は declared として扱う
自己申告されたクライアント名を記録し、Verifiedな識別情報とは分けて扱います。
ルートごとのポリシー
影響の小さい読み取りは自由に許可し、書き込みと影響の大きいエンドポイントでは追加の確認を求めます。
すべての呼び出し元を確認する
unknown なものを含め、どの client がどの endpoint を使っているかを理解します。
credentials を分離する
API キーと OAuth が引き続きアクセスを決定します。アクターのコンテキストは、誰が呼び出しているかを追加します。
Unknown 向けの計画
呼び出し元が使用可能な evidence を示さない場合に何が起きるかを、route ごとに定義します。
01 · 検出
すべての request からの evidence。
サーバー、エッジ、HTTP API の統合は、リクエスト署名、宣言されたクライアント詳細、リクエストコンテキストを読み取り、それぞれにその根拠を付けます。
- 公開されたキーに照らして検証されたHTTPメッセージ署名。
- 申告として記録された declared client names。
- サーバー、ゲートウェイ、またはエッジからリクエストコンテキストを取得します。
- リクエスト署名valid · sample-crawler.exampleverified
- クライアント宣言"research-assistant/2.1"declared
- ブラウザでの対話pointer + keyboard eventsinferred
- サポートされる signal なしroute not instrumentedunknown
02 · 理解
誰がどの endpoint を使っているかを把握する
各ルートのアクター構成、最も多く呼び出すオペレーター、未知の呼び出し元が集中する場所を確認します。
- ルートとオペレーター別の呼び出し元。
- すべての分類の根拠。
- endpoint ごとの Unknown rate。
- /dashboard不明 7%
- /api/v1/catalog不明 15%
- /support/tickets不明 8%
- /signup不明 21%
03 · ルーティング
影響に見合った制御。
ルート単位のポリシーを記述できます。Verified のエージェントには構造化された応答、Declared のクライアントには標準的な制限、影響の大きい操作にはより強い認証情報を適用します。
- ルート、クラス、基準別のポリシー。
- 必要な場面で、より強い認証情報に切り替えます。
- 観測し、preview し、それから enforce します。
- /api/v1/catalogenforceエージェント許可 · 構造化 API
- /support/ticketsenforce人間 + AI許可 · AI-assisted とラベル付け
- /account/*preview不明既存の checks を維持する
- /api/v1/orderspreviewエージェントより強い認証情報を要求する
判断例
request から result、そしてあなたの decision へ。
検証済みのエージェントがカタログを読む
Request
GET /api/v1/catalog
結果
エージェントbasis: verifiedあなたの判断
Agent 用の rate limit と構造化応答で許可します。
自動化クライアントが注文を行います
Request
POST /api/v1/orders
結果
エージェントbasis: inferredあなたの判断
注文を作成する前に、アプリのより強い credential を求めます。
証拠のないクライアント
Request
GET /api/v1/catalog
結果
不明basis: unknownあなたの判断
読み取り専用ルート: 既定のレート制限で許可。
リスクを抑えて展開
チームはobservation modeから始め、routeごとに進めます。
- 01
すべてのrouteを観測
APIの前にmiddlewareまたはHTTP APIを追加します。署名、宣言、Unknownの呼び出し元はrouteごとに記録されます。
- 02
route policyをプレビュー
agentのrate limitやstep-up credentialsが実際のtrafficに対して何をしていたかを、適用前に確認します。
- 03
影響度で適用
読み取りは開いたままにし、書き込みは厳しくし、アクセス制御はAPI keysとOAuthに任せます。
あなたの stack と連携します
- 創業チーム
Webサーバーミドルウェア (Node.js)
サーバー側
サーバーレンダリングのアプリと APIs 向けのリクエストレベルのシグナル。
- 創業チーム
Next.js
サーバーサイドとエッジ
page と API route 用の middleware。
- 創業チーム
ブラウザスクリプト
ブラウザシグナルのみ
browser session からの interaction signals を、server-side integration とあわせて取得します。
- 創業チーム
Cloudflareとエッジランタイム
Edge
リクエストがオリジンに届く前に、エッジでシグナルを取得します。
- 創業チーム
汎用HTTP API
あらゆるスタック
リクエストコンテキストを API に送信し、根拠付きの結果を受け取ります。
- 創業チーム
MCPサーバー
MCP
MCP ツール呼び出しのための Actor コンテキスト。
- ロードマップ
WordPress
plugin
WordPress サイト向けプラグイン。
- ロードマップ
ネイティブモバイル
iOS and Android
Native iOS と Android の SDK。
各創業チームとのオンボーディング中に、統合は実作業ベースで進めます。別のスタックをお使いですか? 応募時にお知らせください。
よくある質問
client は request に署名する必要がありますか?
いいえ。署名された request が最も強い evidence を示しますが、Proof of Actor は declaration と inference も記録し、それぞれ basis を付けてラベル付けし、不十分な場合は Unknown を報告します。
有効な signature があると、client に行動が許可されることになりますか?
いいえ。request が公開された identifier に結び付いた key で署名されたことを示します。その operator が何をできるかは、authorization と policy で決まります。
API keys や OAuth の代わりになりますか?
いいえ。access は引き続き credentials が制御します。Proof of Actor は誰または何が呼び出しているかを追加するため、その上により適切な policy を適用できます。
エンドポイントごとに異なるルールを設定できますか?
はい。ポリシーはルートごとに記述されるため、読み取り専用エンドポイントと影響の大きい書き込みを別々に扱えます。
費用はいくらですか？
選定された創業開発チームは、合意済みの使用上限内で最大 12 months free を受けられます。