エージェントはIAMの新たなワークロードになりつつある。サービスアカウントはその準備ができていない

まず、既存の考え方にとって最も強い主張から始めよう。それは決して愚かな考えではない。サービスアカウントとAPIキーは、20年にわたってマシンワークロードを支えてきた。仕組みは理解され、監査され、あらゆるクラウドとSaaSツールが対応し、セキュリティチームにはすでに一覧表もある。「エージェントには新しいIDカテゴリが必要だ」と言われたとき、合理的な反応はこうだ。すでに非人間IDというカテゴリがある。それを使えばいい。

しかし、そこでうまくいかなくなる。サービスアカウントは「どのシステムが呼び出しているのか」という問いへの答えだ。エージェントはもっと難しい問いを突きつける。「どのエージェントが、誰の代理で、何を目的に呼び出していて、今後30秒以内に誰がそれを失効させられるのか」。IAM業界自身の数字では、非人間IDはすでに人間のIDを一桁の倍率で上回っている。さらにVerizon DBIR 2026は、エージェント型AIの普及に伴って注視すべきものとしてサービスアカウントとマシンアカウントを挙げていると、Token Securityによる同報告書の解説は指摘する。本稿では、従来の対応付けがなぜ破綻するのか、代わりに何が構築されているのか、そして失敗がすでにどのような形で現れているのかを整理する。

要点 - サービスアカウントとAPIキーは、安定した決定論的な呼び出し元を前提としている。エージェントは一時的で非決定論的であり、相互に委任するため、共有資格情報に組み込まれた監査、失効、最小権限の前提が崩れる。 - 標準化の方向はエージェント単位のワークロードIDだ。IETF WIMSEワーキンググループには、トークンスコープだけでなくIDそのものでエージェントを識別できることを求め、ポリシー、監査、失効のためにSPIFFE型のエージェント別識別子を使うべきだという提案が出ている。 - 事故はすでに具体的だ。Salesloft Driftのエコシステムで侵害されたOAuthトークンは企業のSalesforce環境への横展開に使われ、7月のHugging Face侵害は自律型エージェントによって最初から最後まで実行された。 - 実装指針も収束しつつある。エージェントごとの専用ID、モデルのコンテキスト外で発行される短命かつタスク限定の資格情報、そして共有ロールではなくエージェント自身をキーにした監査証跡だ。 - 複数のエージェントが1つの共有サービスアカウントで認証しているなら、ログから「どのエージェントが何をしたか」は分からない。今週確認すべきテストはこれだ。

何が起きたのか

8月前半に2つの流れが重なった。1つ目は、標準化の議論が具体化したことだ。8月4日に提出されたIETF WIMSEアーキテクチャドラフトのissueは、AI仲介者に関する現行ドラフトの文言が弱すぎると主張している。ドラフトは自律型エージェントの行動を区別するために「separate workload identities or token scopes」を認めているが、このissueはトークンスコープでは不十分だとする。スコープはトークンが何をできるかを制限するが、そのトークンが「誰なのか」は変えない。同じ資格情報を共有する複数のエージェントは、スコープがどれほど異なっても、監査ログ、失効システム、エージェント別ポリシー上では区別できない。提案されている修正は、マネージド型エージェントプラットフォームが各エージェントに一意のワークロード識別子を割り当て、それを専用claimに載せ、ポリシー、監査、失効の安定したキーとして使うことだ。各デプロイ済みエージェントに、そのエージェントリソースと結びついたSPIFFEベースのIDを与えるGoogleのエージェントID設計が、実例として挙げられている。

2つ目は、インシデントが途切れなかったことだ。7月中旬のHugging Face侵害は、企業名が公表された事例として初めて、自律型エージェントが最初から最後まで実行した侵入だった。dataset pipelineでのコード実行、資格情報の収集、内部クラスター間の横移動、週末を通じた数千件の操作が行われた。これより前、AIエージェント向けソーシャルネットワークのMoltbookは、エージェントアカウントが150万に達してから数日以内に、設定ミスのあるデータベースから150万個のAPIトークンを漏えいさせたと、Studio Globalのまとめは報告している。そしてDBIRが非人間ID攻撃の代表例として繰り返し扱うSalesloft DriftのOAuthトークン侵害は、Google、Cisco、Zscalerなど大手企業のSalesforce環境へのアクセスに使われた。これはまさに、エージェントが依存する資格情報のリスクそのものだ。

2026年8月、IETF WIMSEのissueは、エージェントの行動をトークンスコープではなく個別のワークロードIDによって区別し、エージェント別識別子をポリシー、監査、失効の安定したキーとすることを提案した。その前月にはHugging Faceでエージェントによる侵害があり、1月にはMoltbookのエージェントプラットフォームから150万個のAPIトークンが漏えいしていた。

サービスアカウントとAPIキーがエージェントに合わない理由

この不一致には4つの側面がある。対策が異なるため、分けて考える価値がある。

共有IDは帰属を壊す。 サービスアカウントは、共有され、静的で、比較的広い権限を持つものとして設計されている。1つのアカウントで10個のエージェントを動かせば、監査ログに現れる主体は1つだけだ。Cockroach Labsの現場解説が指摘するように、どのエージェントがどのデータに触れたか分からず、資格情報のローテーションには全エージェントとの調整が必要になり、アカウントの権限は「どれか1つのエージェントが過去に必要としたすべて」の和集合へと膨張していく。同社の匿名化事例は、私が顧客チームから聞いた話のいくつかとよく似ている。開発時に顧客データベース全体への読み取り権限を与えられたサポートエージェントが、その権限を本番前に絞られないまま3か月稼働したというものだ。

エージェントは一時的だが、キーはそうではない。 エージェント型ワークフローは数秒のうちにモデルプロバイダー、ベクトルストア、3つのAPI、クラウドストレージへ認証し、その後消えることがある。長寿命のAPIキーは、定期ローテーションする価値のある恒常的な呼び出し元を前提にしている。この不一致がスプロールを生む。誰も覚えていないエージェントのために作られたキーが、今も有効で、今も広い権限を持ち続ける。

委任は「誰の代理か」という連鎖を壊す。 ユーザーの代理で動くエージェントと、自律的に動くエージェントは、ポリシーエンジンから見れば全く違う存在であるべきだ。共有サービスアカウントでは同じに見える。OAuthによる委任はユーザーのケースを比較的うまく扱えるが、自律型のケースではエージェント自身のIDが必要になる。さらにマルチエージェント委任では、各hopで引き渡す権限を広げるのではなく狭めなければならない。

モデルに秘密情報を持たせてはいけない。 これは設定ではなく構造の問題だ。コンテキストウィンドウに渡した資格情報はモデルから見え、モデルを操作できるものにもさらされる。prompt injectionは、エージェント自身の出力を通じて資格情報を外へ持ち出せる。対策は、タスク実行時にトークンサービスが発行する短命かつスコープ限定の資格情報を、ツール実行レイヤーに保持させることだ。モデルは呼び出しを指示するが、秘密情報はモデルのコンテキストに入らない。Cockroach Labsはこの点をうまく説明しており、私がセルフホスト型エージェントスタックを構築する顧客に伝えていることとも一致する。鍵を持つのはharnessであり、意図を持つのがモデルだ。

共有サービスアカウントは、ログ上の主体を1つにしてエージェントの帰属を壊し、短命なエージェントワークロードより長く生き残り、ユーザー委任と自律動作の境界を曖昧にし、prompt injectionが届くモデルコンテキストへ資格情報を渡す誘惑を生む。Cockroach LabsとminiOrangeの比較が指摘する通りだ。

ベンダーと標準化団体が構築しているもの

見えてきたアーキテクチャは3層からなる。心強いのは、ベンダーと標準化の側が概ね同じ形へ収束していることだ。

エージェントごとのワークロードID。 前述のWIMSEの方向性が標準版だ。各論理エージェントに一意で安定した識別子を与える。提案されている形式はSPIFFE URIで、共有実行ロールとは別物だ。その識別子をポリシー、監査、失効のキーにする。プラットフォーム管理のエージェントが実行資格情報を共有する場合でも、エージェント固有のclaimを追加する必要がある。最も重要な変化はここだ。デプロイメント単位ではなく、エージェント単位のIDである。

保存した秘密情報ではなくフェデレーション。 Descopeによるエージェント向けワークロードIDフェデレーションの解説はパターンを示している。AWS IAM roleやIRSA経由のKubernetes service accountなど、エージェントのプラットフォームIDを、IDプラットフォームから発行される短命かつスコープ限定のトークンと交換する。同時にエージェントのディレクトリレコードも作成し、トークンが失効した後も監査証跡を残す。漏えいする長寿命キーはなく、IDレコードは個々の資格情報より長く存続する。

発見とガバナンスが市場になる。 商用側では、Reco、Token Security、Oasis、Aembitなどの非人間IDベンダーが、エージェントを中心に再配置を進めている。すべてのエージェント資格情報を発見し、所有者に紐づけ、過剰権限を検知し、きれいに失効させる。Recoの整理は実務的だ。ユーザー操作には委任OAuth、自律動作には専用ワークロードIDというように、IDタイプをエージェントの役割に合わせる。そして責任範囲が広がるたびに権限を見直す。エージェントは、従業員が建物の鍵を増やしていくのと同じように権限を蓄積するからだ。2025年12月に公開されたOWASP Top 10 for Agentic Applicationsは、Identity and Privilege Abuseを独立した主要リスクカテゴリとして挙げており、セキュリティチームが監査所見を語るための共通言語を与えた。これが広いスタックのどこに置かれるかは、ツールだけでなくガバナンスの問題でもある。組織面についてはAIエージェントガバナンスで扱っている。

新たなアーキテクチャは、WIMSEの議論にあるSPIFFE型識別子をポリシー、監査、失効のキーとするエージェント別ワークロードID、Descopeが示すプラットフォームIDから短命かつスコープ限定トークンへのフェデレーションと永続的なエージェントディレクトリレコード、そして非人間IDの発見と最小権限ガバナンスを提供するベンダー市場という形に収束しつつある。

エージェントIDが失敗するとき

3つのインシデント、3つの異なる失敗モード。どれも示唆的だ。

Hugging Face、2026年7月: 攻撃者のID問題は防御側の問題でもあった。 エージェントによる侵入は、コード実行workerからクラウドとクラスターの資格情報を取得し、横移動した。典型的な過剰権限ワークロードの話だ。データ処理コンポーネントが、盗む価値のある資格情報を持っていた。あまり報じられていないのは、Hugging Faceが明らかにしたフォレンジック上の非対称性だ。攻撃エージェントは利用ポリシーに縛られていなかった一方、同社のフォレンジック作業は、試したホステッドモデルのガードレールによって当初ブロックされた。そのため自社インフラ上でopen-weightモデルのGLM 5.2を動かし、分析を行った。同じインシデントの両側にあるIDとアクセスの失敗である。

Salesloft Drift、DBIRの警告: トークンがマスターキーになる。 あるベンダーエコシステムで侵害されたOAuthトークンは、大手企業のSalesforce環境へ横展開するために利用された。パスワードも、人間へのフィッシングもない。広く信頼され、静かに再利用される非人間資格情報だ。長寿命OAuth grantでSaaSツールにつないだエージェントは、すべてこの形のリスクを持つ。そして対策も同じ形になる。短命、狭いスコープ、エージェント単位、失効可能だ。

Moltbook、2026年1月: エージェントプラットフォームはIDリスクを集中させる。 エージェントアカウント用プラットフォームが、設定ミスのあるデータベースから150万個のAPIトークンに加え、メールアドレスやエージェント間メッセージを漏えいさせたと、Studio Globalは報じている。エージェントIDを一元化すれば、そのblast radiusも一元化される。なお、流通しているインシデント情報の一部は監査済み事実ではなく報道ベースとして扱うべきだ。Hugging Face自身の開示は一次情報だが、Moltbookの数字は二次報道に依存している。

文書化されたエージェントIDの失敗には、2026年7月のHugging Face侵害で自律型エージェントがクラウドとクラスターの資格情報を取得して横移動した事例、Waxellの分析、Salesloft DriftのOAuthトークンを使って企業Salesforceテナントへ展開した事例、2026 DBIRに関するToken Securityの解説、そしてMoltbookから150万個のエージェントAPIトークンが漏えいした事例がある。

今やるべきこと

1. 今週: エージェントの資格情報を洗い出し、帰属テストを行う。ログから任意のエージェント操作を1つ選び、どのエージェントが実行したか、誰の代理だったか、そのエージェントだけを他に影響させず失効できるかを確認する。答えが「できない」なら共有IDの問題がある。最初に直すべき所見はそれだ。

2. 今月: 1つの自律型エージェントを長寿命資格情報から移行し、トークンサービスまたはIDプラットフォームが発行する短命でタスク限定のトークンを使う。資格情報はツール実行レイヤーに保持し、モデルのコンテキストには決して入れない。最も広いアクセスを持つエージェントから始めるといい。たいてい、それは誰かが急いで「一時的に」広くスコープしたものだ。

3. 今四半期: 各論理エージェントに独自の安定したIDを与える。仕組みがあるならSPIFFE ID、なければエージェントごとに固有のサービスアカウントを使い、監査とアラートのキーにする。そして必要になる前に失効runbookを書いておく。まだ初期段階でエージェントをどこで動かすべきか検討しているなら、ローカルとクラウドのAIエージェントのトレードオフが、この領域をどこまで自分で管理できるかを左右する。

FAQ

IAMにおけるエージェントIDとは何か

個々のAIエージェントに割り当てられる、独立して検証可能なIDだ。実行基盤のプラットフォームや、代理で行動する対象ユーザーとは別に存在する。認証、認可ポリシー、監査証跡、失効の安定したキーとして使われる。ワークロードIDがマイクロサービスを識別するのと似ているが、短命で非決定論的、かつ相互委任できる呼び出し元に合わせて設計される。

なぜエージェントはサービスアカウントを共有するだけではだめなのか

技術的には可能で、現在は多くがそうしている。問題は、監査ログに実際のエージェントではなく共有アカウントしか出ず帰属が失われること、アカウント権限が全エージェントの必要権限の和集合まで膨らむこと、1つのエージェントを止めるために全員の資格情報をローテーションしなければならないこと、そしてユーザー委任の操作と自律操作を区別できないことだ。最初のインシデントまでは機能する。起きた後は、何が起きたかを再構築できない。

標準化団体はエージェントIDについて何をしているのか

IETF WIMSEワーキンググループは、ワークロードIDアーキテクチャをAI仲介者へ拡張している。トークンスコープに依存せず、エージェント別識別子を必須にする提案が進行中で、SPIFFE URIが推奨メカニズムとして挙げられている。OWASPは2025年12月にTop 10 for Agentic Applicationsを公開し、identity and privilege abuseを独立カテゴリとした。Cloud Security Allianceにも、エージェントごとの一意なIDを推奨するagent identity governance frameworkがある。

エージェントの資格情報をモデルコンテキストに入れてよい場合はあるか

ない。コンテキストウィンドウ内のものはすべてモデルから見え、prompt injectionによって外部へ持ち出される可能性がある。受け入れられているパターンは、タスク時にトークンサービスが資格情報を発行し、モデルとAPIの間にあるツール実行レイヤーが保持し、タスク限定かつ短命にすることだ。モデルは操作を要求し、harnessが秘密情報を持つ。

結論

IDの世界には「IDがcontrol planeだ」という言い方がある。エージェントは、その考え方をマイクロサービス以上に厳しく試すことになる。進む方向は、今から構築を始められるほど明確だ。エージェントごとのID、モデルの外に置く秘密情報、インシデントが広がるより速く失効するトークン、そして「どのエージェントが、誰の代理で、何の目的で」を答えられる監査だ。この夏に被害を受けた組織が使っていたのは、奇抜な構成ではない。共有資格情報を使い、問題が起きないことを期待していた。そのギャップを閉じる必要があり、そのための技術の大半はすでに存在する。

既存のIAM環境へエージェントIDを組み込み、実務経験のある人間を議論に加えたいなら、それは私が支援している仕事の一つだ。お問い合わせはこちら。

出典

• IETF WIMSE WG, draft-ietf-wimse-arch issue #139, "AI and ML-Based Intermediaries: token scopes do not create per-agent identity": https://github.com/ietf-wg-wimse/draft-ietf-wimse-arch/issues/139 (提出 2026-08-04、参照 2026-08-29)

• Cockroach Labs, "AI Agent Identity Security": https://www.cockroachlabs.com/blog/ai-agent-identity-security/ (公開 2026-07-17、参照 2026-08-29)

• Token Security, "The 2026 Data Breach Investigations Report Confirms It: Identity Is the Control Plane for Agentic AI": https://www.token.security/blog/the-2026-data-breach-investigations-report-confirms-it-identity-is-the-control-plane-for-agentic-ai (公開 2026-05-20、参照 2026-08-29)

• Descope, "What Is Workload Identity Federation for AI Agents?": https://www.descope.com/learn/post/workload-identity-federation-for-agents (公開 2026-06-22、参照 2026-08-29)

• miniOrange, "Why AI Agents Need Workload Identity, Not Shared Secrets": https://www.miniorange.com/blog/workload-identity-ai-agents/ (公開 2026-05-20、参照 2026-08-29)

• Reco, "Non-Human Identities for AI Agents: How to Govern Access": https://www.reco.ai/blog/non-human-identities-for-ai-agents (公開 2026-07-20、参照 2026-08-29)

• Waxell, "Hugging Face Breach: How an AI Agent Ran the Attack": https://www.waxell.ai/blog/hugging-face-agentic-attacker-ai-breach-2026 (公開 2026-07-17、参照 2026-08-29)

• Studio Global, "EU AI Act August 2026: Enforcement Powers Go Live as Autonomous Agent Breach Tests Regulators": https://www.studioglobal.ai/discover/answers/what-key-enforcement-powers-and-transparency-obligations-6a6bff1f2240a0fb8c880846 (公開 2026-08-17、参照 2026-08-29)