メインコンテンツにスキップ
エージェントアクセスポリシー

制御可能なポリシーでAIエージェントをルーティングする

アプリケーションが、人、AI支援ユーザー、自律エージェントをルートごとにどう扱うかを決めます。Proof of Actor が証拠を示し、ポリシーが判断します。

早期アクセスを取得仕組みを探る
Toshendra Sharma

著 Toshendra SharmaFounder & CEO, AgentCredia · Updated November 13, 2026

すべての人に同じポリシーでは、もう足りない

多くのアプリケーションは、インターフェースを操作し、アカウントにサインインした一人の人間を前提に設計されてきました。アクセス制御もその前提に従っていました。セッションが有効なら、そのリクエストは通ります。自動化されて見えるなら、CAPTCHA かブロックが出ます。

そのモデルは崩れつつあります。今では同じアプリケーションが、人、人間の代わりに AI アシスタントを使う人、自律エージェントに代行させる人を相手にしています。あるエージェントは顧客自身の統合です。あるものはドキュメントを取得する AI アシスタントです。あるものはクローラーです。中には、製品を悪用しようとするものもあります。1つの yes-or-no ルールでは、これらすべてにうまく対応できません。

AI エージェントのルーティングとアクセスポリシーは、その単一のルールを、意図的な判断の集合に置き換えます。どの actor に、どの体験を、どの route で、どの条件下で与えるか。(/product) の [Proof of Actor] が、その判断に必要な証拠をアプリケーションに与え、判断そのものはあなたの手に残します。このアプローチの設計原則については、人とAIエージェントのための app policy の設計 を読み、ポリシーが実際の製品ワークフローにどう対応するかは SaaS apps のユースケース をご覧ください。

良いエージェントポリシーの形

有用なポリシーは具体的です。route または workflow、actor class、必要な evidence の強さ、そして response を明示します。たとえば次のようになります。

  • 読み取り専用の catalog route: verified なエージェントを allow し、構造化された response を返す。declared なエージェントは標準の rate limit で allow する。
  • アカウント変更 action: 既存の再認証は全員に適用する。actor が Unknown で、かつ action の影響が大きい場合は review を追加する。
  • support 提出: 開示された AI 支援コンテンツを受け入れ、routing のためにラベル付けする。
  • signup: 既存のチェックを維持し、inferred な actor result だけで判断しない。

これらは、すべてのエージェントを abuse とみなすことなく、また、すべてのエージェントを無条件に信頼することもなく、actor に応答します。このバランスこそが agent-aware access の要点であり、人とAIエージェントのための app policy の設計 の記事では、route ごとの例をさらに詳しく解説しています。

5つの response

Proof of Actor の Route 機能は、ポリシーが選べる 5 つの response を中心に設計されています。

Allow

リクエストを通常どおり進めます。公開ルートや低リスクのルートにおける大半の traffic を含め、ほとんどの traffic はそのまま allow されるべきです。

Adapt

actor に合わせて体験を変えます。人向けの interface ではなく、verified なエージェントには構造化された API response やページの Markdown 版を返します。パターンについては AI エージェントに構造化コンテンツを提供する のガイドをご覧ください。

Challenge

より強いものを求めます。新しい login、追加の credential、アカウント所有者からの確認などです。誤った判断のコストが高い route で challenge を使います。

Review

処理をその場で完了させずキューに送るか、人による確認の対象にします。blocking すると正当な利用者に不利益が出る一方で、無人で完了させるにはリスクが高い場合に review は有効です。

Limit

actor と route に合わせて調整した rate または volume の制限を適用し、自動化された呼び出しが人向けの workflow を圧倒しないようにします。

robots.txt が access policy ではない理由

多くのチームは robots.txt から始めます。クローラーに対する最初のシグナルとしては妥当です。しかし、それはエージェント向けの access policy ではありません。クローラーの運用者は、user agent ごとに異なる behavior を公開しています。Anthropic は自社の bots が robots.txt の directives に従うと述べており（Anthropic crawler documentation）、OpenAI は ChatGPT に質問したユーザーの指示で動作する ChatGPT-User について、操作がユーザー起点であるため robots.txt rules が適用されない場合があると説明しています（OpenAI crawler documentation）。robots.txt は、API、MCP tools、あるいはサインイン済み workflow については何も示しません。

access policy は、リクエストを処理する場所で動作し、RFC 9421 に従って検証された signature などの evidence を読み取り、route ごとに response を選ぶ必要があります。MCP server については、MCP authorization specification が HTTP 経由で client が access token を取得する方法を定義しています。actor policy はその上に文脈を加えるものであり、置き換えるものではありません。

Proof of Actor がポリシーに供給するもの

統合が評価する各リクエストは、ポリシーが読める 4 つの要素を持つ actor result を生成します。

  • Class: Human, Human + AI, Agent, Unknown。
  • Basis: verified, declared, inferred, unknown。これにより、ポリシーは検証済みの signature と自己申告の client 名を別々に扱えます。
  • Evidence summary: 結果が何に基づくかを人が読める形で示す説明。logging と review に役立ちます。
  • Context: どの integration とどの route がその結果を生んだか。

basis が明示されているため、ポリシーは精密に設定できます。「エージェントを allow する」ではなく、「読み取り route では verified なエージェントを allow し、declared なエージェントは rate-limit し、それ以外には Unknown の fallback を適用する」といった形です。request から decision までの流れは How It Works に詳しく載っています。

fallback もポリシーの一部

evidence が足りないときの動作が定義されていなければ、ポリシーの品質はそこで決まってしまいます。Proof of Actor は、そうしたケースを隠さず明示します。

  • Unknown: evidence が判定を支えませんでした。各 route について、Unknown が何を意味するかをポリシーで定義します。Human に変換されることも、デフォルトで悪意あるものとして扱われることもありません。
  • Timeout: 結果が時間内に届きませんでした。統合は、その route で選んだ fallback を適用します。
  • Missing signals: collector が動かなかったか、header がありませんでした。結果にはその事実が反映され、ポリシーはそれに従って扱います。

各 route について、fail open か fail closed か を選びます。fail open は、Proof of Actor がなかった場合と同様に request を進めます。fail closed は、既存のより強いチェックを適用します。低リスクの route は通常 fail open です。機微な action は通常 fail closed です。これは全体一律ではなく、risk tier ごとに設定します。

identity, credential, authorization を分けて考える

エージェント access policy は 3 つの異なる層の上に成り立ちます。これらを分けておくことで、最も大きな誤りを避けられます。

  1. Identity evidence は、どの kind of actor が呼び出しているか、そして何がそれを裏付けるかを示します。これを Proof of Actor が提供します。
  2. Credentials は、どの account が責任を負うかを示します。session、token、または API key がこれを提供します。
  3. Authorization は、その caller がこの action を実行してよいかを示します。permission model がこれを提供します。

verified なエージェント identity があるからといって、そのエージェントが authorized であること、誰かが権限を委任したこと、あるいはその action が安全であることは意味しません。actor result は routing と context の追加に使ってください。permission の付与には authorization model を使ってください。Detection & Limitations のページでは、各種 evidence が何を示せるかを正確に説明しています。

何も壊さずに導入する

エージェント access policy を最も安全に導入する方法は段階的です。

  1. Observe. observation mode で Proof of Actor を導入します。利用者側の挙動は変わらず、結果だけが記録されます。
  2. Understand. どの actor がどの route を使っているか、各 route の unknown rate、既知の情報と一致しない結果を確認します。
  3. Preview. ポリシーを preview で実行し、enforce せずに何を行うかを logging します。
  4. Enforce narrowly. evidence が明確に支える 1 つの route でポリシーを有効化します。結果を監視します。
  5. Expand. 自信が高まるにつれて、より多くの route に広げます。

エージェント対応ポリシーを安全に展開する のガイドでは各段階を順に説明し、エージェントを止めずに機微な action を保護する では高リスクの route を扱っています。

チームが得られるもの

Proof of Actor では、1 つの integration で 3 つの機能を得られます。Detect は actor signals を収集し、verified な assertion と inference を分離します。Understand は actor analytics、trend、各結果の背後にある evidence を表示し、Unknown を可視に保ちます。Route は、このページで説明したポリシーを記述し、選んだ場所に適用するための機能です。private beta 期間中は、routing policy を各 founding team と一緒に設計し、あなた自身の application code 内で実行するため、完全な制御を維持できます。

よくあるポリシー上の誤り

初めてエージェント access を設計するチームは、いくつかの誤りを繰り返しがちです。これを避けるだけで、数週間のやり直しを防げます。

  • すべてのエージェントをデフォルトでブロックする。 正当なエージェントは別経路を使うようになります。多くの場合、それは人向けに作った interface を scrape する形であり、構造化された path よりも防御が難しくなります。
  • declared name を信じる。 自分の名前を名乗るだけの client は、証明ではなく主張をしただけです。未検証の caller と同じ扱いにしてください。
  • すべての場所で同じ fallback を使う。 公開の pricing page の Unknown と、password change の Unknown は同じ状況ではありません。route ごとに答えが必要です。
  • inference から人について決める。 actor result は routing のための context であり、個人に対する verdict ではありません。重大な判断は、自社の controls と review に残してください。
  • 観測を省く。 1日目から enforce すると、false positive は顧客からの苦情で初めて分かります。まず observe し、evidence が明確なところから enforce してください。

各 enforce の前に、security、product、support の責任者と短く policy review を行うだけでも、こうした問題の多くを早期に見つけられます。

Founding developer program から始める

Proof of Actor は private beta です。選ばれた founding development team には、合意した usage limits の範囲で、最大 12 か月の無料 access と、最初のポリシー設計を支援するエンジニアによる直接サポートを提供します。

AI エージェントをアプリケーションがどう扱うべきかを決めているなら、早期 access に申し込む してください。重要な route と、どの判断を行いたいかを教えていただければ、それに合うポリシー作成を支援します。これが APIs と MCP servers にどう適用されるかも確認できます。

Sources

開発者向け

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record
{
  "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を読む

よくある質問

AIエージェントのアクセスポリシーとは何ですか?

リクエストを送る actor の種類に基づいてアプリケーションが適用するルールです。たとえば、読み取り専用ルートでは verified なエージェントを許可し、影響の大きい操作ではより強い credential を求める、といった形です。Proof of Actor は actor の結果を提供し、応答はポリシーが決めます。

Proof of Actor はポリシーを自動で enforce しますか?

いいえ。すべての統合は観測モードから始まり、どの route にも、その workflow に適合するとチームが確信した時点で route ごとにポリシーを有効化します。

actor が Unknown の場合やチェックが time out した場合はどうなりますか?

各 route について明示的な fallback を定義します。たとえば、公開読み取りは allow し、アカウント変更では既存のチェックを維持するといった形です。Unknown と timeout は Human に自動的にはなりません。

すべての AI エージェントをブロックすべきですか?

通常はそうではありません。多くのエージェントは正当な利用者です。ポリシーを使えば、構造化された経路を与え、重要な箇所では制限し、機微な操作にはより強いチェックを残せます。

ポリシーは人について判断できますか?

Proof of Actor の結果は、雇用、与信、重要なサービスへのアクセスなど、個人に関する重大な判断の唯一の根拠にすべきではありません。自社のコントロールと併せて、ルーティングと文脈のために使ってください。

誰があなたの app を使っているかを把握します。

少数のfounding developer向けのprivate betaです。

早期アクセスを取得価格を見る

先に話しますか? 創業者に相談する