AIエージェントに権限を渡す前に読む認証・認可の書籍ガイド｜暗号の基礎からOAuth・ゼロトラストまで段階順に選ぶ4冊

エージェントを社内システムにつなぐ検証は、最初のうちは管理者権限のAPIキーを環境変数に1本置くだけで進みます。動かすだけならそれで足ります。困るのは本番に近づいたときです。「このエージェントは誰の権限で動いているのか」「読み取りだけに絞れるか」「漏れたら何を止めればよいのか」と聞かれて、答えに詰まります。これはモデルやフレームワークの問題ではありません。認証と認可という、Webが20年以上かけて整理してきた領域の問題です。この記事では、その土台を学べる実在の日本語書籍を4冊、段階順に紹介します。なお本記事は書籍紹介であり広告を含みます。価格・版・在庫・目次は変わるため、最新は各出版社や書店のページでご確認ください。

「権限を渡す」の実体は、トークンとスコープの設計です#

認証と認可を分けて考える#

最初に言葉を揃えます。認証(Authentication)は「相手が誰かを確かめること」、認可(Authorization)は「その相手に何を許すかを決めること」です。人間がログインして画面を操作している間は、この2つが混ざっていても実害が出にくい構造でした。ログインできた人に、その人の画面が出る。それで済んでいたからです。

エージェントが入ると、登場人物が増えます。依頼した人、エージェントを動かしているアプリケーション、呼び出されるAPI。認証の対象は誰なのか、許可の範囲は依頼者の権限と同じでよいのか、それとも狭めるべきなのか。ここを分けて考えられないと、設計の議論が噛み合いません。

APIキーの直渡しが抱える問題は、2012年の時点で整理されています#

APIキーやパスワードをそのままエージェントに預ける構成の問題は、新しい話ではありません。OAuth 2.0を定めたRFC 6749(2012年10月)は冒頭で、第三者のアプリケーションにリソース所有者の資格情報を共有する従来のやり方の問題を列挙しています。要約すると次のとおりです。

• 第三者アプリケーションが、資格情報(典型的には平文のパスワード)を将来のために保存する必要がある
• 第三者アプリケーションが過度に広いアクセスを得てしまい、リソース所有者は期間や対象を限定できない
• リソース所有者は、特定の第三者だけのアクセスを取り消せない。取り消すにはパスワードを変えるしかなく、すべての第三者が巻き込まれる
• 第三者アプリケーションのどれか1つが侵害されると、パスワードとそれで守られたデータ全体が侵害される

「第三者アプリケーション」を「エージェント」に読み替えると、いま起きている問題そのものです。RFC 6749はこれに対して、認可のレイヤを設け、クライアントの役割をリソース所有者の役割から分離する、という方針を取りました。クライアントは所有者の資格情報ではなく、範囲と有効期間が限定されたアクセストークンを受け取ります。

MCPの認可仕様は、OAuth 2.1のドラフトを土台にしています#

エージェントとツールをつなぐ規格であるMCPも、この流れの上にあります。MCP仕様(2026-07-28版)のAuthorizationのページには、次のことが書かれています。

• 認可はMCPの実装にとって任意(OPTIONAL)。対応する場合、HTTPベースのトランスポートはこの仕様に従うべきで、STDIOトランスポートはこの仕様に従わず、環境から資格情報を取得すべきとされている
• 保護されたMCPサーバーはOAuth 2.1のリソースサーバー、MCPクライアントはOAuth 2.1のクライアントとして振る舞う。認可サーバーはOAuth 2.1を実装しなければならない(MUST)
• MCPクライアントはRFC 8707のresourceパラメータを実装し、どのMCPサーバー向けのトークンかを明示しなければならない。MCPサーバーは、トークンが自分を対象に発行されたものかを検証しなければならず、それ以外のトークンを受け入れたり中継したりしてはならない
• アクセストークンはAuthorizationヘッダで送り、URIのクエリ文字列に含めてはならない
• スコープは最小権限の原則に従う。MCPサーバーは401応答のWWW-Authenticateヘッダで必要なスコープを示すべきで、クライアントは意図した操作に必要なスコープだけを要求すべきとされている

同仕様が参照しているOAuth 2.1は、IETFのdatatrackerで確認するかぎり執筆時点でもInternet-Draft(draft-ietf-oauth-v2-1-16、datatracker上の最終更新は2026年9月2日)で、RFCにはなっていません。つまり「MCPの認可を理解する」には、OAuth 2.0の枠組みを知ったうえで、その後に積まれたベストプラクティスとドラフトの差分を追う、という二段構えが必要になります。

選び方の早見表#

4冊は同じ「セキュリティ」の棚に並んでいても、前提と目的が違います。先に全体を示します。

急いでいる方の本命は3冊目です。ただし、署名とハッシュの違いが曖昧なまま3冊目に入ると、JWTやトークン保護の章で止まります。その場合は1冊目の該当章だけ先に読むのが近道です。

1. 用語の土台をつくる(暗号と認証のしくみと理論がこれ1冊でしっかりわかる教科書)#

1冊目は、暗号技術と認証技術を基礎から解説する本です。光成滋生さんの著書で、技術評論社の「図解即戦力」シリーズとして2021年9月に刊行されました。A5判312ページです。公式の書誌ページでは、公開鍵暗号や署名などの理論を基礎から詳しく解説し、TLS 1.3やHTTP/3、FIDOなどの新しい技術も紹介する、と説明されています。対象読者には「暗号と認証の基礎を学習したい人」「Web担当者やセキュリティ担当者など」が挙げられています。

構成は全9章48節です。1章「暗号の基礎知識」、2章「アルゴリズムと安全性」、3章「共通鍵暗号」、4章「公開鍵暗号」、5章「認証」、6章「公開鍵基盤」、7章「TLS」、8章「ネットワークセキュリティ」、9章「高機能な暗号技術」。

エージェントの権限設計という目的で効くのは、次の箇所です。

• 1章の03「認証」。パスワードによる認証と攻撃手法に続いて、認証の分類、認可、OAuthという項目が並びます。認証と認可を別の概念として最初に区別してくれます
• 5章「認証」の25「ハッシュ関数」、28「メッセージ認証符号」、29「署名」。29には「MACと署名」「公開鍵認証」「FIDO」の項目があります。共有鍵で作るMACと、秘密鍵で作り公開鍵で検証する署名の違いは、トークンを誰が検証できるのかという設計判断に直結します
• 6章「公開鍵基盤」と7章「TLS」。証明書の失効、TLS 1.3、前方秘匿性を扱います。4冊目のゼロトラストが前提にしている知識です

向いているのは、「署名と暗号化は何が違うのか」「ハッシュ化したから安全、は何に対して安全なのか」を自分の言葉で説明できない方です。この区別が曖昧なままだと、トークンの検証やシークレットの保管について、レビューで指摘ができません。

扱っていない範囲も書いておきます。目次で確認できるかぎり、OAuthは1章の1項目として登場するだけで、フローやスコープ設計を学ぶ本ではありません。JWTやOpenID Connectも目次の見出しには出てきません。2章から4章(有限体、RSA暗号、楕円曲線暗号など)と9章(準同型暗号、秘密計算、ゼロ知識証明、量子コンピュータ)は理論の比重が高い章なので、権限設計が目的なら1章、5章、6章、7章を先に読み、残りは必要になったときに戻る読み方で足ります。

図解即戦力 暗号と認証のしくみと理論がこれ1冊でしっかりわかる教科書(技術評論社)

広告

著者: 光成滋生 / 出版社: 技術評論社(図解即戦力) / 2021年9月刊 / A5判312ページ。暗号の基礎知識、共通鍵暗号、公開鍵暗号、認証、公開鍵基盤、TLSなど全9章。ハッシュ関数、メッセージ認証符号、署名、FIDO、証明書の失効、TLS 1.3を扱います。OAuthのフローやスコープ設計、JWT、OpenID Connectを学ぶ本ではありません。

Amazonで見る楽天で見るYahoo!ショッピングで見る

※価格・在庫は変動します。最新の情報は各販売サイトでご確認ください。

2. エージェントに叩かれる側の穴を知る(体系的に学ぶ 安全なWebアプリケーションの作り方 第2版)#

2冊目は、Webアプリケーションの脆弱性が生まれる原理と対策を扱う本です。徳丸浩さんの著書で、SBクリエイティブから2018年6月に刊行されました。B5変型判688ページです。版元ドットコムの書誌情報では、PHPのサンプルへの攻撃を通して脆弱性が生まれる原理と具体的な対処方法を学ぶ構成で、OWASP Top 10 - 2017に対応し、Web APIやJavaScriptに関する解説と脆弱性診断入門の章を新設した、と紹介されています。

構成は全9章です。1章「Webアプリケーションの脆弱性とは」、2章「実習環境のセットアップ」、3章「Webセキュリティの基礎 ～ HTTP、セッション管理、同一オリジンポリシー」、4章「Webアプリケーションの機能別に見るセキュリティバグ」、5章「代表的なセキュリティ機能」、6章「文字コードとセキュリティ」、7章「脆弱性診断入門」、8章「Webサイトの安全性を高めるために」、9章「安全なWebアプリケーションのための開発マネジメント」。

認証・認可の本を並べた中に、なぜ脆弱性の本が入るのか。理由は単純で、エージェントに渡すトークンをどれだけ丁寧に設計しても、受け取る側のアプリケーションが認可をチェックしていなければ意味がないからです。

この目的で読む箇所は次のとおりです。

• 3章の3.1「HTTPとセッション管理」、3.2「受動的攻撃と同一オリジンポリシー」、3.3「CORS」。ブラウザ前提の防御が、ブラウザを介さないエージェントからの呼び出しでは前提ごと変わることを理解する土台になります
• 4章の4.5「『重要な処理』の際に混入する脆弱性」と4.6「セッション管理の不備」、4.16「Web API実装における脆弱性」
• 5章「代表的なセキュリティ機能」。5.1「認証」、5.2「アカウント管理」、5.3「認可」、5.4「ログ出力」の4節構成で、この記事のテーマに最も近い章です

とくに5.3「認可」と5.4「ログ出力」は、社内APIをエージェントに開放する前に読む価値があります。「画面にボタンを出さない」ことで権限を制御していたシステムは、APIを直接呼ばれると防御になりません。IPAの「安全なウェブサイトの作り方」も、第1章の11種類の脆弱性のひとつとして「アクセス制御や認可制御の欠落」を挙げています。OWASP Top 10の2025年版でも、A01は「Broken Access Control」です。認可の不備は、昔からある問題であり、いまも上位にある問題です。

古くなっている箇所も正直に書きます。刊行は2018年で、対応をうたっているのはOWASP Top 10の2017年版です。OWASPの公式ページによれば現行の版は2025年版で、間に2021年版も出ています。2章の実習環境も、目次のとおりVirtualBoxやOWASP ZAPなど刊行当時のツール構成が前提です。サンプルコードはPHPです。それでも、脆弱性が生まれる原理の説明は言語や年代に強く依存しません。原理を学ぶ本として読み、ツールの手順や脆弱性の順位付けは現行の一次情報で上書きする、という使い方が現実的です。

向かないのは、OAuthやトークンベースの認可を学びたい方です。目次を見るかぎり、この本の中心はセッション管理を使うWebアプリケーションで、OAuthは章や節の見出しに出てきません。トークンの委譲は3冊目の担当です。

体系的に学ぶ 安全なWebアプリケーションの作り方 第2版 脆弱性が生まれる原理と対策の実践(SBクリエイティブ)

広告

著者: 徳丸浩 / 出版社: SBクリエイティブ / 2018年6月刊 / B5変型判688ページ。HTTPとセッション管理、同一オリジンポリシー、CORS、機能別の脆弱性、認証・アカウント管理・認可・ログ出力、脆弱性診断入門など全9章。サンプルはPHP。OWASP Top 10は2017年版への対応で、実習ツールの手順は当時のものです。OAuthやトークンの委譲は主題ではありません。

Amazonで見る楽天で見るYahoo!ショッピングで見る

※価格・在庫は変動します。最新の情報は各販売サイトでご確認ください。

3. 委譲の仕組みを身につける(OAuth徹底入門)#

3冊目が本丸です。Justin RicherさんとAntonio Sansoさんの共著、須田智之さんの訳、Authlete, Inc.の監修で、翔泳社から2019年1月に刊行されました。B5変型判464ページです。原著はManningから刊行された『OAuth 2 in Action』で、Manningの公式ページでは2017年3月の刊行とされています。

版元ドットコムの紹介文によれば、全16章を4つの部に分けた構成です(紹介文の表記は「パート」、目次の表記は「第1部」から「第4部」で、この記事では目次の表記に揃えます)。第1部(第1章、第2章)がOAuth 2.0のプロトコルの概要、第2部(第3章から第6章)がOAuth 2.0のエコシステム全体の構築、第3部(第7章から第10章)が各構成要素の脆弱性とその回避方法、第4部(第11章から第16章)がOAuth 2.0を核とした次の世代のプロトコルや周辺の標準です。

エージェントの権限設計に直接効く章を挙げます。

第1章の1.2「古き悪しき手法～クレデンシャルの共有～」と1.3「アクセス権の委譲」。見出しのとおり、先ほどRFC 6749の冒頭で見た資格情報の共有という問題と、その代わりになる委譲の考え方を扱う箇所です。APIキーの直渡しをやめる理由をチームに説明する材料になります。

第2章の2.3「クライアント、認可サーバー、リソース所有者、保護対象リソース」と2.4「トークン、スコープ、認可付与」。MCPの認可仕様に出てくる役割の名前は、ここで定義される語彙と同じものです。仕様書が読めなかった原因が語彙にあるなら、この章で解消します。

第3章から第5章は、クライアント、保護対象リソース、認可サーバーをそれぞれ構築する章で、4.3「トークンの情報をもとにしたリソースの提供」、5.5「スコープのサポートの追加」といった節が並びます。RFC 6749の3.3節が定めるとおり、スコープの実体は空白区切りの文字列のリストで、文字列の意味は認可サーバーが定義します。つまり文字列を決めただけでは何も守られず、トークンのスコープを見て拒否する処理が保護対象リソース側に実装されて初めて効きます。「スコープを切ったから安全」ではなく、「スコープを見て拒否するコードがあるから安全」です。

第3部の第7章から第10章は、クライアント、保護対象リソース、認可サーバー、トークンのそれぞれについて、よく狙われる脆弱性を扱います。7.4「リダイレクトURIの登録」、9.3「リダイレクトURIの不正操作」、10.2「Bearerトークンの使用に関するリスクと考慮点」などです。Bearerトークンは「持っている者が使える」トークンなので、エージェントのログやコンテキストにトークンが混入した場合の影響を考える出発点になります。

第4部では、11.2「JWT」、11.4「トークン・イントロスペクション」、11.5「トークン取り消し」、第12章「動的クライアント登録」、第13章「OAuth 2.0を使ったユーザー認証」が並びます。13.1の見出しは「なぜ、OAuth 2.0は認証プロトコルではないのか？」です。OAuthでログインを実装しようとして混乱した経験のある方には、この章が効きます。

この本が古くなっている箇所#

ここは丁寧に書いておきます。原著は2017年、日本語版は2019年の刊行で、前提はOAuth 2.0です。その後、OAuth 2.0のセキュリティに関するベストプラクティスがRFC 9700(2025年1月)としてまとめられ、OAuth 2.1のドラフトはそれを取り込んでいます。ドラフトがOAuth 2.0からの変更点として挙げているのは、たとえば次の項目です。

• 認可コードグラントではPKCEを使うことが前提になった
• リダイレクトURIは文字列の完全一致で比較しなければならない
• Implicit grantとResource Owner Password Credentials grantは仕様から外された
• Bearerトークンをクエリ文字列で送る使い方は外された
• パブリッククライアント向けのリフレッシュトークンは、送信者に紐づけるか、1回限りの使用にしなければならない

第6章の6.1「認可における付与方式」を読むときは、この差分を頭に置いてください。なお、版元ドットコムに掲載されている目次の節見出しには、PKCEという語は出てきません。

MCP固有の部分も本にはありません。第12章が扱う動的クライアント登録(RFC 7591)は、MCP仕様の2026-07-28版では非推奨とされ、後方互換のために残されている位置づけです。代わりにClient ID Metadata Documentsへの対応が推奨(SHOULD)されています。保護対象リソースのメタデータ(RFC 9728)やresourceパラメータ(RFC 8707)も、この本の刊行後に重要度が上がった仕様です。

それでもこの本を本丸として推すのは、役割の分離、スコープ、トークンのライフサイクル、脆弱性の類型という骨格が変わっていないからです。差分は、骨格を知っていれば仕様書から読み取れます。骨格なしに差分だけ追うのは、かなり苦しい作業です。

向かないのは、コードを読まずに概念だけ押さえたい方です。第2部がクライアント、保護対象リソース、認可サーバーの構築にあてられており、付録Aも本書で使っているフレームワークの説明です。464ページを通読する時間が取れない場合は、第1章、第2章、第6章、第10章、第11章、第13章に絞る読み方もあります。

OAuth徹底入門 セキュアな認可システムを適用するための原則と実践(翔泳社)

広告

著者: Justin Richer、Antonio Sanso / 訳: 須田智之 / 監修: Authlete, Inc. / 出版社: 翔泳社 / 2019年1月刊 / B5変型判464ページ。クライアント・保護対象リソース・認可サーバーの構築、各構成要素の脆弱性、JWT、トークン・イントロスペクション、トークン取り消し、動的クライアント登録、OpenID Connectを4部16章で扱います。前提はOAuth 2.0で、OAuth 2.1のドラフトやMCP固有の要求は公式仕様で補う必要があります。

Amazonで見る楽天で見るYahoo!ショッピングで見る

※価格・在庫は変動します。最新の情報は各販売サイトでご確認ください。

4. 「人ではない主体」をどう信頼するか(ゼロトラストネットワーク 第2版)#

4冊目は、ゼロトラストネットワークの包括的な解説書です。Razi Raisさん、Christina Morilloさん、Evan Gilmanさん、Doug Barthさんの共著、鈴木研吾さんの訳で、オライリー・ジャパンから2025年6月18日に刊行されました。400ページ、原書は『Zero Trust Networks, 2nd Edition』です。公式の書誌ページでは、すべての通信を信頼せず常に検証するという前提に立ち、ユーザーやデバイスのアクセスを細かく制御し、最小権限で接続を許可するアプローチだと説明されています。第2版では、各種「トラストスコア」の管理方法、開発から運用に至る一貫したゼロトラストの実践、標準・ガイドラインの紹介などが更新された、とされています。

構成は全12章と付録です。1章「ゼロトラストの基本」、2章「信頼の管理」、3章「コンテクストアウェアネスなエージェント」、4章「認可の判断」、5章「デバイスの信頼」、6章「アイデンティティの信頼」、7章「アプリケーションの信頼」、8章「トラフィックの信頼」、9章「ゼロトラストネットワークの実現に向けて」、10章「攻撃者の視点」、11章「ゼロトラストのアーキテクチャ標準、フレームワーク、ガイドライン」、12章「課題と未来」。

先に誤解を解いておきます。3章の題にある「エージェント」は、ゼロトラストの文脈で使われる用語です。目次には3.1「エージェントとは何か？」、3.1.4「エージェントは認証のためのものではない」といった節が並びますが、これをAIエージェントの章だと期待して買うと外れます。目次の見出しに「AI」という語が出るのは12.2.2だけです。ほかには5.7.5「機械学習」がトラストシグナルの1項目として挙がっている程度で、AIエージェントの権限設計を直接論じる本ではありません。

それでも4冊目に置くのは、3冊目までで身につけた「トークンで権限を渡す」という仕組みの上に、「そもそも誰をどこまで信頼するのか」という設計の層が要るからです。社内ネットワークの中にいるから信頼する、という境界防御の発想のままエージェントを置くと、エージェントは社内にいるというだけで広い範囲に届いてしまいます。

この目的で読む箇所は次のとおりです。

• 2章「信頼の管理」の2.5「最小権限」。2.5.1「動的な信頼」、2.5.2「トラストスコア」と続きます。権限を固定で与えるのではなく、状況に応じて見直すという考え方は、エージェントの権限を作業単位で絞る設計と相性がよいものです
• 4章「認可の判断」。4.2「エンフォースメント」、4.3「ポリシーエンジン」、4.4「トラストエンジン」、4.5「データストア」という構成で、認可の判断をどこで行い、どこで強制するかを分けて考えます。4.3.3「誰がポリシーを定義するのか？」、4.3.4「ポリシーレビュー」は、エージェントの権限を誰が承認するのかという運用の議論にそのまま使えます
• 6章「アイデンティティの信頼」の6.6.2「ワークロードアイデンティティ」と、7章「アプリケーションの信頼」の7.6.2「インスタンスの認証・認可」。人ではなくソフトウェアが主体になるときの身元の扱いです
• 8章「トラフィックの信頼」の8.5.2「mTLS」

向かないのは、すぐに実装に使える設定例を求めている方です。考え方とアーキテクチャの本で、特定製品の手順書ではありません。また、1冊目の公開鍵基盤とTLSの知識が前提になります。

なお、この本には初版もありますが、この記事で紹介しているのは2025年6月刊の第2版です。これから買うなら、内容が更新された第2版を選ぶのが自然です。

ゼロトラストネットワーク 第2版 ―境界防御の限界を超えるためのセキュアなシステム設計(オライリー・ジャパン)

広告

著者: Razi Rais、Christina Morillo、Evan Gilman、Doug Barth / 訳: 鈴木研吾 / 出版社: オライリー・ジャパン / 2025年6月刊 / 400ページ。原書は『Zero Trust Networks, 2nd Edition』。信頼の管理と最小権限、認可の判断(ポリシーエンジン、トラストエンジン)、デバイス・アイデンティティ・アプリケーション・トラフィックの信頼、標準とガイドラインを全12章で扱います。3章の「エージェント」はゼロトラスト用語で、AIエージェントの権限設計を直接扱う本ではありません。

Amazonで見る楽天で見るYahoo!ショッピングで見る

※価格・在庫は変動します。最新の情報は各販売サイトでご確認ください。

補足: 人間側のログインを固めるなら#

主題から少し外れるため4冊には入れませんでしたが、エージェントに権限を委譲する人間のアカウントが乗っ取られれば、委譲の設計は根元から崩れます。人間側のログインを強化する文脈では、技術評論社の『パスキーのすべて ―― 導入・UX設計・実装』(えーじさん、倉林雅さん、小岩井航介さんの共著、2025年1月刊、A5判256ページ)が、パスキーの背景、ユーザー体験、WebAuthn API、スマホアプリ向けの実装までを扱っています。1冊目の29「署名」にあるFIDOの項目が、この本への入口になります。

読む順と、途中でやめてよい地点#

4冊を順に通読する必要はありません。目的別に、どこまで読めば手が動くかを示します。

単発の社内ツールにエージェントをつなぐだけなら、3番目までで十分なことが多いはずです。4冊目は、複数のエージェントや複数のシステムをまたぐ構成になったときに効いてきます。

本で足りない部分を一次情報で補う#

4冊のいずれも、エージェントに権限を渡す場面を直接は扱っていません。次の一次情報を併読してください。

MCPのAuthorization仕様とSecurity Best Practices#

前述のとおり、MCPの認可はOAuth 2.1のドラフトを土台に、Protected Resource Metadata(RFC 9728)、Resource Indicators(RFC 8707)などを組み合わせています。あわせて読みたいのが、MCP公式のSecurity Best Practicesです。

同文書は「Token Passthrough」をアンチパターンとして挙げています。MCPサーバーが、自分向けに正しく発行されたものかを検証せずにクライアントからのトークンを受け入れ、そのまま下流のAPIに渡してしまう構成のことです。リスクとして、レート制限や検証といったセキュリティ制御の迂回、誰の操作かを追えなくなる監査証跡の問題、信頼境界の破壊などが挙げられており、対策としてMCPサーバーは自分向けに明示的に発行されたものではないトークンを受け入れてはならない(MUST NOT)とされています。

「Scope Minimization」の節も実務的です。files:*やadmin:*のような広いスコープを最初にまとめて付与すると、トークンが漏れたときの影響範囲が広がり、取り消しが業務全体を止め、監査ログからユーザーの意図が読めなくなる、と説明されています。対策として示されているのは、低リスクの読み取り操作だけを含む最小の初期スコープから始め、特権的な操作が最初に試みられた時点でWWW-Authenticateのスコープ指定を使って段階的に引き上げるモデルです。

MCPの認可に関する上記の記述は、Model Context Protocolの公式仕様「Authorization」(2026-07-28版)と公式ドキュメント「Security Best Practices」(いずれもfrontmatterのsources)の内容の要約です。仕様は改訂されるため、実装時は必ず最新版の原文を確認してください。

RFC 6749、RFC 9700、OAuth 2.1のドラフト#

RFC 6749はOAuth 2.0の本体で、3冊目の内容と対応します。datatrackerのページには、RFC 8252、RFC 8996、RFC 9700によって更新されたことが示されています。RFC 9700はOAuth 2.0のセキュリティに関するBest Current Practiceで、2025年1月の発行です。OAuth 2.1のドラフトは、第10節「Differences from OAuth 2.0」にOAuth 2.0からの変更点の一覧(規範ではない参考の位置づけ)を載せているので、本を読んだあとの差分確認はここから始めると効率的です。ドラフトは版が進むため、参照するときは版番号と日付を控えてください。この記事で確認したのは-16版です。

IPA「安全なウェブサイトの作り方」とOWASP Top 10#

IPAの「安全なウェブサイトの作り方」は、届出件数の多かった脆弱性や影響度が大きい脆弱性を取り上げた資料で、日本語版は改訂第7版(第4刷は2021年3月31日公開)です。第1章で11種類の脆弱性を取り上げ、巻末にセキュリティ実装のチェックリストが付いています。2冊目の徳丸本と守備範囲が重なっており、無償で読めるので、2冊目を買うか迷っている方はこちらを先に読むのも手です。OWASP Top 10は2025年版が現行で、脆弱性の類型の最新の整理はこちらで確認できます。

本にも仕様にも書かれていない、自分たちで決める部分#

最後に、どの資料も決めてくれない部分を挙げます。

• エージェントを依頼者の権限で動かすのか、専用のサービスアカウントで動かすのか。前者は依頼者の権限を超えませんが、トークンの管理が複雑になります。後者は単純ですが、依頼者が本来見られないデータにエージェント経由で届いてしまう構成になりがちです
• トークンをどこに保管し、モデルのコンテキストやログに混入させないためにどう分離するか
• どの操作を人間の承認に残すか

よくある質問#

まとめ#

エージェントに権限を渡すという作業は、新しい問題に見えて、その骨格は古くからあるものです。資格情報を直接預けると何が起きるかは2012年のRFCに書かれており、認可チェックの欠落は公的機関の資料にも業界の脆弱性ランキングにも長く載り続けています。MCPの認可仕様がOAuth 2.1のドラフトを土台にしているのは、この蓄積を再利用するためだと読めます。

今回紹介した4冊は、その蓄積を日本語で学ぶための入口です。用語の土台、叩かれる側の穴、委譲の仕組み、信頼の置き方。いずれも生成AIの本ではなく、刊行から時間が経っているものは古くなった箇所もあります。それを承知のうえで骨格を本から学び、差分を一次情報で埋める。この順序が、仕様書を最初から読み下すより確実だと考えています。まずは手元のエージェントが使っている資格情報の権限を確認するところから始めてみてください。