llm-wiki/concepts/ai-agent-identity-security.md

title, created, updated, type, tags, sources, confidence

title	created	updated	type	tags	sources	confidence
AI Agent Identity Security	2026-06-29	2026-06-30	concept	agent security reliability privacy	raw/articles/okta-cross-app-access-partners-2026.md raw/articles/openai-codex-agent-approvals-security-2026.md raw/articles/microsoft-learn-agent-architecture-sdlc-2026.md	medium

AI Agent Identity Security

AI agent identity security は、AI エージェントやアプリ間連携が企業データへアクセスするときに、誰の権限で、何へ、どの範囲で、どの操作をしたのかを追跡・制御する設計領域。Okta の Cross App Access（XAA）発表は、MCP 認証拡張としての Enterprise-Managed Authorization を含め、エージェント時代の認可を OAuth とアイデンティティ管理の延長で標準化しようとする動きとして読める。

問題の出発点は、AI エージェントの接続が静的 API key やユーザーごとの同意画面に依存しがちなこと。これだと、常時特権、見えない同意、監査できないアプリ間移動が起こりやすい。XAA は、すべての接続を中央のアイデンティティポリシーに通し、アクションをログに残し、必要最小限のスコープ付き token を使う方向を示している。

見るべき軸

• Agent as requesting app: Claude、Cursor、Docker、VS Code、Zoom など、作業を始めるエージェントや開発者道具が、別アプリへのアクセスを要求する主体になる。
• Resource app / MCP server: Asana、Atlassian、Figma、Linear、Slack、Supabase、Datadog などが、エージェントに文脈や業務データを渡す側になる。
• Policy and audit: アクセスが許可される前に企業ポリシーで検査し、操作の監査証跡を残す。これは loop-engineering の persistence と verification をセキュリティ境界へ移したものでもある。
• Least privilege for agents: 常時広い権限を持つ bot token ではなく、必要な範囲に絞った identity-based token を使う。
• Local sandbox / approval boundary: Codex の安全運用ドキュメントは、cloud では隔離 container、CLI/IDE では OS sandbox と approval policy を組み合わせ、既定で network access を切り、workspace 外の編集や network 利用を承認対象にする設計を説明している。workspace-write、read-only、network proxy、domain allow/deny などの設定は、企業の cross-app 認可だけでなく個人の agent loop でも「どこまで自動実行してよいか」を明示する制御面になる。
• Repository governance as identity boundary: Microsoft Learn の agent architecture / SDLC module は、agent task を input / output / success criteria で定義し、PR template、checks、CODEOWNERS、rules、environment gate を通じて「どの変更が誰の承認で通るか」を設計する。これは agent-oriented-cli-design の tool-level clarity と同じく、agent の行動を監査可能な境界へ置く方法である。

なぜ重要か

エージェントが社内システム、開発環境、デザイン、会議、監視、データベースを横断し始めると、便利さと同じ速度で攻撃面も広がる。ai-assisted-reverse-engineering のように専門道具へ書き込み権限を渡す場合や、wiki-maintenance-loop のように自動で source を保存・分類する場合でも、「どの agent が何をしたか」を後で説明できることが信頼性の条件になる。

この論点は ai-developer-liability とも接続する。事故や漏えいが起きたとき、単にユーザーの操作やモデル出力だけでなく、開発者がどの権限境界、ログ、承認、取り消し手段を設計していたかが問われる可能性がある。

Open Questions

• 個人用 Hermes / Discord / wiki 自動化では、企業向け XAA の考え方をどこまで軽量化して使えるか。
• MCP server と agent gateway の認可ログを、開発者が後から読める形でどこに保存するべきか。
• 便利な cross-app agent workflow と、ユーザーが理解できる同意・取り消し UI をどう両立するか。