エージェントに人間のアカウントを使わせてはいけない理由
- 年、エンタープライズにおける AI エージェント導入の最大の技術的・ガバナンス的課題は「アイデンティティ」である。生成 AI のプロトタイプ段階では、エージェントは開発者個人の認証情報（Personal Access Token、個人 OAuth トークン）を借りて動作するケースが多かった。しかし本番運用に入ると、この設計は即座に破綻する。退職者の PAT でエージェントが動き続け、監査ログにはその退職者の名前が残り、インシデント発生時に誰の責任なのか追跡不能になる、という事態が業界全体で頻発した。
- 年後半、ある国内大手製造業の子会社では、退職した開発者の GitHub PAT を用いて稼働していた社内ドキュメント生成エージェントが、退職から 4ヶ月後に想定外の社内機密リポジトリへアクセスし続けていたことが内部監査で発覚した。当該 PAT は退職手続きで失効させる対象リストに含まれておらず、エージェントのオーナーシップも明確になっていなかった。幸い情報漏洩には至らなかったが、監査ログから該当アクションを洗い出すだけで 3週間を要した。
この種のインシデントを構造的に防ぐために生まれた概念が Non-Human Identity（NHI）である。エージェント、サービスアカウント、ワークフロー、ボット — 人間ではない主体に固有のアイデンティティを発行し、ライフサイクル管理・権限スコープ・監査ログをすべて人間用のそれと分離する。NHI は 2026年のエンタープライズセキュリティにおける必須概念であり、Okta・CyberArk・GitGuardian・Entro などが競って製品を投入している。
OAuth for Agents: スコープ思想の拡張
NHI の発行自体は難しくない。難しいのは「エージェントが何をしてよいか」を精密に定義することだ。人間用の OAuth スコープは粒度が粗く、たとえば GitHub の repo スコープは該当リポジトリへのフル読み書き権限を一括で与える。この粒度でエージェントに権限付与すると、プロンプトインジェクションで本来の意図から逸脱した操作が行われた際に被害が拡大する。
OAuth for Agents と呼ばれる仕様拡張では、スコープを「ツール × アクション × 対象リソース × 時間」の4次元で定義する。たとえば GitHub のプルリクエスト作成エージェントなら「repos:myorg/app-a:pull_requests:create、有効期限 2時間、呼び出し元 IP レンジ限定」というスコープを発行する。これにより、エージェントが侵害されても横展開できる範囲が物理的に限定される。
Okta for Agents（2026年 GA）はこの思想を製品化し、エージェントごとの OAuth クライアントを自動発行する。発行時に「どのツールを、どの頻度で、どのユーザー代理で使うか」をポリシーとして宣言的に記述し、違反操作は自動ブロックされる。重要なのは「代理（on-behalf-of）」の概念で、エージェントは常に「誰の代理として動いているか」を明示する必要がある。匿名エージェントはポリシーで許容されない。
スコープ制限 API キー: ツール単位で発行する
外部 SaaS との連携においては、エージェントが使う API キーをツール単位で分離することが基本原則となる。Slack 通知、Jira チケット作成、Salesforce 更新、S3 読み書き — それぞれ別の API キーを発行し、1キー漏洩時の被害を局所化する。鍵の保管には HashiCorp Vault や AWS Secrets Manager などの Secret 管理基盤を用い、エージェント起動時に短期トークンを動的発行する方式が標準だ。
さらに進んだ実装では、API キー自体を発行せず、Workload Identity Federation（WIF）を用いる。GCP、Azure、AWS の主要3クラウドはいずれも WIF に対応しており、エージェントのランタイム証明書を外部 Identity Provider で検証することで、恒久的な鍵を持たせずにクラウド API を呼ばせられる。鍵の漏洩リスクをアーキテクチャレベルで消す設計であり、2026年の新規プロジェクトでは WIF 採用が第一選択肢になっている。
mTLS（相互 TLS）によるエージェント間・エージェント対サービス間通信の保護も並行して必須である。サービスメッシュ（Istio、Linkerd）やゼロトラストゲートウェイ（HashiCorp Boundary、Cloudflare Access）でエージェント間通信を暗号化し、クライアント証明書で主体認証する。HTTP ヘッダの API キーだけに依存した設計は、2026年のエンタープライズ基準では「レガシー」と見なされる。
監査ログ: 自律行動を後追いできる設計
エージェントの最大の特徴は「自律性」であり、同時にこれが監査の最大の課題でもある。人間のオペレータなら「意図」を問えるが、エージェントの意図は LLM の推論過程に埋もれており、事後的な再現が困難だ。したがって監査ログは「入力プロンプト・使用モデル・選択ツール・引数・結果・影響範囲」をすべて構造化して記録する必要がある。
推奨ログスキーマは、行動 ID（UUID）、親行動 ID（呼び出しチェーン）、エージェント NHI、代理対象ユーザー、発行トークンハッシュ、プロンプト本文（機密マスク後）、LLM モデルとバージョン、選択ツール、ツール引数、ツール実行結果、実行時間、変更された外部リソース一覧。これを WORM（Write Once Read Many）ストレージに保存し、改竄不能性を担保する。AWS S3 Object Lock、GCP Bucket Lock が典型的な実装だ。
監査ログには保存期間設計も重要である。日本の金融業界では FISC 安全対策基準に準拠し、最低 7年保存が求められる場合がある。大量のエージェント行動ログをこの期間保持するとストレージコストが問題になるため、ホットログ（直近 90日、高速検索可）、ウォームログ（1年、通常検索）、コールドログ（7年、オンデマンド復元）の3階層に分けるのが標準パターンだ。
インシデント事例: プロンプトインジェクション経由の権限昇格
実在の企業名は伏せるが、2025年後半に筆者が関与したインシデントレビューを紹介したい。ある SaaS 企業の内部ナレッジ検索エージェントが、Jira チケット経由で受信した特殊な文字列により本来アクセス権のない HR システムの API を呼び出す事態に至った。原因は複合的で、第一にエージェントの OAuth スコープが「全社 Jira + 全社 HR 読み取り」と過剰に広かったこと、第二に Jira チケット本文をユーザー入力として扱いつつ「指示」としても解釈する設計上の穴、第三に監査ログが「Jira 読み取り」を記録していたものの HR API 呼び出しが同一アクション ID として紐付いておらず、検知に 11日を要したことだ。
教訓は明確である。スコープは必要最小限、ユーザー入力と指示は明確に分離（システムプロンプトとユーザーコンテンツを構造的に分ける）、監査ログは呼び出しチェーンを通じて一意の ID で紐付ける。そして最重要なのは「エージェントに与える権限のレビューを人間の権限レビューと同じ厳格さで実施する」ことだ。多くの組織では後者が形骸化している。
ベンダー選定の実務指針
- 年現在、NHI 管理の主要プレイヤーは Okta、CyberArk、Entro、Astrix、GitGuardian、HashiCorp が挙げられる。選定の観点は4つ。第一にエージェント行動ログとの統合（SIEM 連携、行動異常検知）、第二に OAuth for Agents 仕様への対応度、第三にポリシー記述言語の宣言性（YAML ベース、Rego ベース等）、第四に既存 IdP との同居可能性。
多くの日本企業はすでに Microsoft Entra ID（旧 Azure AD）を人間用 IdP として導入済みであり、NHI をそこに載せるか別基盤にするかで議論が分かれる。筆者の推奨は「人間と NHI は同じ IdP に統合するが、ポリシーは別ストアで管理する」ハイブリッド構成である。可観測性は統一し、権限ポリシーは NHI 専用の宣言的ストアで運用することで、両者の変更サイクルの違い（人間は入退社単位、NHI は日次・時間単位）を吸収できる。
おわりに: アイデンティティがエージェント時代の最優先課題
AI エージェントが社内システムを自律操作する時代、アイデンティティ設計はセキュリティの中核であると同時に、エージェント導入そのものの成否を決める要因になる。スコープ過剰・監査ログ欠損・鍵漏洩 — どれ一つ起こしてもエージェント運用は停止を余儀なくされる。逆に、NHI を起点にした健全な運用基盤を整えられた組織は、エージェントの能力を安全に拡張し続けられる。2026年はエージェント本番化元年であり、同時にアイデンティティ設計の成熟度が問われる年でもある。