AIエージェントに「鍵」を配るのをやめる｜Okta Agent SSOが示した資格情報から身元への設計変更

AIエージェントに「鍵」を配るのをやめる｜Okta Agent SSOが示した資格情報から身元への設計変更

従業員数十〜数百名規模の会社で、部署ごとにAIエージェントの業務利用が始まっている——そんな段階でよく聞くのが「エージェントにどこまで権限を渡すべきか決めきれず、当面はAPI（システム連携の窓口）キーを共有して回している」という声です。共有スプレッドシートやSlackのDMでAPIキーが行き来している状態を、いつまで続けてよいものか。

2026年8月24日、Oktaはこの問いに一つの答えを出しました。「Okta Brings First-Class Identity to AI Agents With Agent SSO」と題する発表で、Agent SSOという機能の一般提供(GA)を明らかにしたのです。この記事では、この発表が実際に何を変え、何を変えていないのかを、発表文の記載に基づいて整理します。

30秒で要点

• Oktaは2026年8月24日、オープン標準「Cross App Access」を中核のOkta SSOに組み込んだAgent SSOの一般提供を発表した。20,000社超の既存顧客にAgent SSOが追加費用なしで含まれる
• 仕組みは、Cross App Access対応のAIエージェントを人間の従業員と並ぶ「身元(first-class identity)」としてUniversal Directoryに登録し、保存された資格情報の代わりに短命なトークンを発行するというもの
• Agent SSOの守備範囲はこの「接続方式」に限定される。非対応エージェントの発見・所有者の割り当て・アクセス承認・kill switchは別サブスクリプション「Okta for AI Agents」の担当だとOkta自身が明記している
• Cross App AccessはModel Context Protocolの公式拡張として組み込まれ、Anthropic(Claude)・Atlassian・Slack・Notionなどが対応パートナーとして列挙されている

なぜAPIキーの共有が「当面の運用」になりがちなのか

AIエージェントを社内ツールに接続するとき、多くの現場が最初に選ぶのはAPIキーの発行です。人事システムや会計システムに接続するエージェントを1つ作るたびに、キーを1つ発行し、それをエージェントの設定ファイルや環境変数に書き込む。動くところまではこれで十分に見えます。

問題は、この方法がスケールしないことです。エージェントの数が部署ごとに増えていくと、「どのキーが、どのエージェントに、どの権限で渡っているか」を追跡する台帳が必要になります。しかし多くの現場では、この台帳が存在しないか、存在してもExcelファイル1枚で止まっています。誰がキーを発行し、いつ失効させるべきかという運用ルールがないまま、キーだけが増えていく——これが「当面はAPIキー共有で回している」状態の実態です。

「鍵を配る」から「身元を発行する」への転換

Oktaの発表文は、Agent SSOの仕組みをこう説明しています。Cross App Access対応のAIエージェントが企業アプリに接続する際、Okta側はそのエージェントを人間の従業員と並ぶ「first-class identity」としてUniversal Directoryに登録し、保存された資格情報の代わりに短命でID統制されたトークンを発行する、というものです。

この違いを、鍵の比喩で考えると分かりやすくなります。APIキーを共有するというのは、家の合鍵を作ってあちこちに配るようなものです。合鍵は複製されても気づきにくく、失効させるには全ての合鍵を回収する必要があります。一方、Agent SSOが目指しているのは、来訪者ごとに「今日だけ有効な入館証」を発行する仕組みです。入館証には有効期限があり、誰にいつ発行したかの記録がその場で残ります。合鍵を作る発想から、身元を確認して都度証明書を出す発想への転換だと捉えると、この機能が何を解決しようとしているかが見えてきます。

Okta自身、この発表を後押しする根拠として「AIエージェントに人間の従業員と同じセキュリティ統制を適用している組織は34%にとどまる」という数字を挙げています。ただしこの数字はOkta自社レポート「AI Agents at Work 2026」からの引用であり、この記事の執筆時点で調査対象・期間・サンプルサイズという原典の詳細までは確認していません。ベンダー自身の自社調査という性質を踏まえて、参考情報として扱うべき数字です。

Agent SSOが「答えていない問い」

ここで見落としやすいのが、Agent SSOが解決する範囲の狭さです。Oktaの製品責任者Ric Smith氏は発表文でこう述べています。「Agent SSO answers one question: how do Cross App Access agents connect to enterprise applications and MCP servers? Okta for AI Agents answers the rest.(Agent SSOは一つの問いにだけ答える。Cross App Access対応エージェントは、どうやって企業アプリやMCPサーバーに接続するのか、という問いだ。それ以外の全てはOkta for AI Agentsが答える)」

「それ以外の全て」には、次のようなものが含まれます。

• 社内で個別に組まれ、Cross App Accessに対応していない「シャドーAIエージェント」の発見
• 各エージェントに「この人間が責任を持つ」という所有者を割り当てる作業
• エージェントが特定の操作を行ってよいかというアクセス認証の判断
• 問題が起きたときにエージェントの動作を止める「kill switch」

これらは全て、Agent SSOとは別のサブスクリプション「Okta for AI Agents」が担うと、発表文で明記されています。つまり「Agent SSOを入れれば、AIエージェントの権限管理が一通り片付く」という理解は、この製品の設計思想とずれています。

なぜ「導入すれば安心」という誤解が生まれやすいのか

セキュリティ製品の発表を読むとき、多くの担当者は「この製品名を導入すれば、その領域の課題が一通り解決する」という受け取り方をしがちです。これは、製品名が課題領域全体(この場合は「AIエージェントのセキュリティ」)と結びつけて語られることが多いために起きる誤解です。実際には、多くのベンダーが課題を機能ごとに切り分けて製品化しており、1つの製品名は課題領域の一部にしか対応していません。

Oktaがこの発表で「接続方式」と「それ以外」を別サブスクリプションに切り分けたこと自体が、AIエージェントのセキュリティが単一の製品で完結する課題ではないことを示しています。むしろ、ベンダー側が意図的に「ここまでは我々の製品が担い、ここから先は別の製品が必要だ」と明言している点を、そのまま読み取る必要があります。

確かなことと、まだ確かではないこと

確かなこと: Oktaが2026年8月24日にAgent SSOの一般提供を発表したこと。仕組みがCross App Access対応エージェントを「身元」として登録し短命トークンを発行するものであること。Agent SSOの守備範囲が「接続方式」に限定され、シャドーAI発見・所有者割り当て・kill switch等は別サブスクリプション「Okta for AI Agents」が担うとOkta自身が明記していること。Cross App AccessがMCPの公式拡張として組み込まれ、Anthropic(Claude)を含む複数のパートナーが対応先として列挙されていること。

まだ確かではないこと: 「AIエージェントに人間と同じ統制を適用している組織は34%」という数字の調査対象・期間・サンプルサイズ。Agent SSOが実運用でどの程度の導入コスト・移行期間を要するか。Okta for AI Agents側の機能詳細や提供状況は、本記事が確認した発表文の範囲では扱われていません。

自分でも試せる、最小の検証

自社で使っているAIエージェント関連ツールを1つ挙げ、Okta Integration Networkの対応パートナー一覧(発表文に列挙されているAnthropic・Atlassian・Slack・Notionなど)と照合してみてください。対応しているツールであれば「接続方式」をAgent SSO型の仕組みに置き換える余地があります。対応していなければ、Agent SSOの対象外であり、まずAPIキーの発行・失効を管理する台帳を作るところから始める必要がある、という現状把握になります。

判断軸の提示

「〇〇というセキュリティ製品を導入した」という説明を受けたとき、その製品が答えている問いを1つに絞り込んで確認すること。Agent SSOの場合、答えている問いは「接続方式」だけであり、所有者の割り当てやkill switchのような運用面の問いには答えていません。製品名の印象で守備範囲を広く見積もらず、発表文やドキュメントで「この製品が答えていない問い」を先に洗い出す姿勢が、AIエージェントの権限設計では欠かせません。

この記事で扱ったような判断を、自社の状況に照らして整理したい場合は、無料診断ツールで状況を言語化するところから始めることができます。