agent authorization の意味
Agent authorization は、AI agent が何を実行できるかを決める判断です。どの route を呼び出せるか、どの data を read できるか、どの action をどの程度の volume で実行できるかを定めます。これは agent identity とは異なります。agent identity は、どの agent か、またはどの operator の agent かが request を送っているのかを特定することです。
この 2 つは、しばしば同時に届くため、混同しやすいものです。signed request は送信者が誰かを示します。しかし、その送信者に account の変更、order の作成、data の export が許されるかまでは示しません。identity は evidence であり、authorization は policy です。署名付き AI agent request が何を証明し、何を証明しないか に関する記事で、この違いを詳しく説明しています。
この区別が重要な理由
アプリケーションでは、human user について authentication と authorization をすでに分けています。login で誰であるかを証明し、role と permission で何ができるかを決めます。agent でも同じ分離が必要ですが、さらに注意が必要です。
- identity が強くても、permission がないことがある。 完全に有効な HTTP message signature を持つ crawler でも、write endpoint を呼び出す固有の権利はありません。
- permission があっても、強い identity がないことがある。 customer の API key を使う agent は、その key によって authorized です。どの agent software がそれを保持しているかを示すものがなくても同じです。
- agent の背後にいる人が重要になる。 agent が誰かのために動くとき、問題はその person がその authority を与えたかどうかになります(delegated authority を参照)。
これらを 1 つの check にまとめると、2 つの failure mode が生まれます。人による login がないために正当な automation を block してしまうか、よく特定できる agent に、本来させるべきでない action を信頼して任せてしまうかです。
authorization の一般的な表し方
多くの application は、すでに持っている仕組みで agent を authorized にしています。
- credential と scope。 API key や、必要な integration に scope を限定した OAuth 2.0 token です。MCP server でも同じ model を使います。MCP authorization specification では、保護された server を OAuth 2.1 resource server として扱います。
- route 単位の policy。 知られている agent に read-only route を開き、write route には account に紐づいた credential を求めます。
- risk tier。 影響の小さい action は広く許可し、影響の大きい action にはより強い credential、confirmation、review を求めます。
- operator、credential、route ごとの rate limit と quota。
agent identity の evidence は、これらの判断における 1 つの input になります。実践的な進め方については、人と AI agent 向けに app レベルの policy を設計する を参照してください。これにより、verified な operator を匿名の client とは異なる扱いにできますが、permission 自体は引き続き your policy から与えられます。
よくある誤解
- 「verified agent なら許可される」。verification は request に属性を与えるだけです。実際に何ができるかは、あなたの policy が決めます。
- 「human だと証明されない agent は block すべき」。多くの agent は正当な参加者です。より適切な問いは、各 kind の actor に route ごとに何を許可するかです。
- 「authorization は behavior から推定できる」。behavior は、どの kind の actor かに対する confidence を上げたり下げたりできます。しかし、それだけで permission を与えるべきではありません。
Proof of Actor での扱い
Proof of Actor は evidence に関する問いに答えます。つまり、どの kind の actor が存在するか、その basis は何か(verified、declared、inferred、unknown のいずれか)、そして何が分かっていて何が分かっていないかです。permission を決めることは、意図的に行いません。Agent の result は、verified であっても authorization を意味しません。Route では、application が actor result と自身の credential、scope、risk tier を組み合わせて、各 interaction を allow、adapt、challenge、review、limit します。まずは observation mode で開始し、何かを enforce する前に outcome を確認できます。
decision が app にどう組み込まれるか をさらに学び、APIs と MCP servers の use case を確認するか、early access に申し込む ことができます。
出典
- RFC 6749: The OAuth 2.0 Authorization Framework: client 向けの scoped token
- MCP specification 2026-07-28: Authorization: MCP server 向けの OAuth ベース authorization
- RFC 9421: HTTP Message Signatures: signed request が何を確立するか