49 lines
12 KiB
Markdown
49 lines
12 KiB
Markdown
---
|
||
title: AI Agent Identity Security
|
||
created: 2026-06-29
|
||
updated: 2026-07-16
|
||
type: concept
|
||
tags: [agent, security, reliability, privacy]
|
||
sources: [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, raw/articles/ios-ai-chatbot-llm-key-leakage-2026.md, raw/articles/unity-terms-agentic-access-2026.md, raw/articles/claude-code-telemetry-audit-2026.md, raw/articles/cloudflare-monetization-gateway-x402-2026.md, raw/articles/github-copilot-browser-tools-ga-2026.md, raw/articles/xai-voice-agent-builder-2026.md, raw/articles/theregister-claude-desktop-double-agent-2026.md, raw/articles/safari-mcp-server-webkit-2026.md, raw/articles/1password-codex-mcp-secret-access-2026.md, raw/articles/email-verification-protocol-draft-2026.md, raw/articles/1password-credential-broker-2026.md]
|
||
confidence: 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 を使う。
|
||
- **Secret custody outside the model**: 1Password Environments MCP Server for Codex は、coding agent を secret の保管庫ではなく「承認された利用主体」として扱う設計例である。Codex は environment を作成し、変数名を扱い、実行を orchestrate できるが、secret value は MCP channel、model context、local file、terminal へ返さず、1Password が承認済み process の runtime memory にだけ注入する。これにより、agent workflow の速度を保ちながら、credential custody、explicit approval、scope、audit を [[agent-harness-engineering]] 側の実行 loop へ組み込める。^[raw/articles/1password-codex-mcp-secret-access-2026.md]
|
||
- **Runtime credential brokering**: 1Password Credential Broker は、GitHub Actions の OIDC / Workload Identity Federation を使い、repo・branch・workflow・environment・commit で workload を検証してから、vault 全体ではなく job が許可された item だけを実行時に渡す設計である。2026-06 の private beta は GitHub Actions に絞られ、自動 rotation までは含まないが、standing vault access を消し、各 access event に workload attribution を付ける点で [[ci-cd-runtime-security]] と agent identity の接点になる。1Password は同じ broker を AI agent にも広げ、agent が long-lived OAuth / refresh token を抱えず、task-scoped short-lived token を受け取り、人間の delegator まで監査できる形を目指すとしている。^[raw/articles/1password-credential-broker-2026.md]
|
||
- **Browser-mediated identity assertions**: Email Verification Protocol draft は、email verification を「メールを送って code を入力させる」方式から、browser が relying party と issuer の間を仲介して signed token を受け渡す方式へ寄せる。issuer は RP identity を直接知る必要がなく、RP は nonce と browser key binding で token を検証するため、friction reduction と privacy separation を同時に狙う標準化案として読める。これは agent 固有ではないが、agent が account creation や delegated workflow を扱う時代には、identity assertion を browser / issuer / RP に分け、過剰な identifier sharing を避ける設計として隣接する。^[raw/articles/email-verification-protocol-draft-2026.md]
|
||
- **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 でも「どこまで自動実行してよいか」を明示する制御面になる。
|
||
- **Browser / device permission boundary**: GitHub Copilot の VS Code browser tools GA は、agent が実ブラウザを開き、click/type/drag、console error、screenshot、scripted flow を使えるようにする一方、人間が開いた tab は `Share with Agent` するまで読めず、agent tab は fresh session で cookie/storage から隔離され、camera/microphone/geolocation は既定拒否になると説明している。browser が agent tool になるほど、tab ownership、session isolation、site allow/deny、workspace trust は identity boundary の一部になる。^[raw/articles/github-copilot-browser-tools-ga-2026.md]
|
||
- **Local browser data boundary**: [[safari-mcp-server]] は local に動き、自身では network call せず、AutoFill などの個人情報にはアクセスしないと説明されている。ただし page content、screenshot、console log は接続先 agent へ渡るため、どの agent を信頼するか、どの site/tab を見せるか、captured data が vendor 側でどう扱われるかは運用上の identity / privacy boundary になる。^[raw/articles/safari-mcp-server-webkit-2026.md]
|
||
- **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 の行動を監査可能な境界へ置く方法である。
|
||
- **Platform-designated agent access**: Unity の 2026-06-30 Terms of Service は、AI agents、LLM、MCP clients / servers が Unity platform とやり取りする場合、Unity が運用または指定する framework 経由に限ると明記している。これは XAA のような cross-app authorization とは別に、resource platform 側が「どの agent gateway なら許すか」を契約と access policy で決める方向を示す。利用者は account / credential 経由で動く automated caller の責任を負うため、[[agent-harness-engineering]] の tool boundary と契約上の identity boundary が重なる。^[raw/articles/unity-terms-agentic-access-2026.md]
|
||
- **Client credential exposure**: iOS の LLM chatbot 調査では、444 本中 282 本が plaintext API key、認証なし backend、再利用可能 token のいずれかで有料 LLM access を露出していた。AI 機能を mobile app に載せるだけでも、key を client に埋め込まない、backend が呼び出し元を検証する、漏れた key を revoke する、といった基本的な identity boundary が実務上の cost / privacy / abuse boundary になる。^[raw/articles/ios-ai-chatbot-llm-key-leakage-2026.md]
|
||
- **Telemetry identity leakage**: Claude Code 2.1.196 audit は、source code 本文を送らなくても git remote URL の hash、GitHub Actions の actor/repository ID、account/org UUID、machine/session ID のような識別子が telemetry に載りうると指摘している。[[ai-agent-telemetry-privacy]] では、agent の権限境界だけでなく、agent vendor へ流れる作業文脈の最小化と opt-out の実効性も identity security の一部として扱う。^[raw/articles/claude-code-telemetry-audit-2026.md]
|
||
- **Payment as access credential**: Cloudflare Monetization Gateway / x402 は、agentic buyer が request に payment proof を添えて web page、API、dataset、MCP tool にアクセスする設計を示す。支払い証明は一種の credential になるが、記事は同時に Web Bot Auth などで agent identity を求められる余地も残している。[[agentic-web-monetization]] では、誰の agent が、どの予算で、どの resource を買ったかを identity / audit 境界として扱う必要がある。^[raw/articles/cloudflare-monetization-gateway-x402-2026.md]
|
||
- **Voice agent as delegated operator**: xAI Voice Agent Builder は、電話番号/SIP、Gmail、Google Calendar、Outlook、Linear、Notion、OneDrive、custom MCP、knowledge base、guardrails、call playback を一体化した no-code voice agent として提示されている。電話応答 agent は単なる chat UI ではなく、顧客本人確認、PII、社内 system 操作、人間への handoff を扱う delegated operator になるため、誰の声・番号・tool 権限で何を実行したかの audit が必要になる。^[raw/articles/xai-voice-agent-builder-2026.md]
|
||
- **Synced assistant settings as identity surface**: Claude Desktop の personalization / preferences は account-wide に同期され、The Register の Pentera Labs 記事ではここに攻撃 prompt を入れることで、別端末の Claude Desktop と command-capable MCP connector へ影響を広げられると説明されている。agent identity security では token だけでなく、sync される instruction、skill、extension 設定も「どの actor が変更し、どの端末へ反映されたか」を監査すべき対象になる。^[raw/articles/theregister-claude-desktop-double-agent-2026.md]
|
||
- **Command execution boundary**: 権限や token が正しくても、agent が shell command をどう生成・実行するかには別の危険がある。[[ai-agent-command-safety]] は、GuardFall のように text guard と shell interpretation がずれる問題を扱う隣接領域である。
|
||
|
||
## なぜ重要か
|
||
|
||
エージェントが社内システム、開発環境、デザイン、会議、監視、データベースを横断し始めると、便利さと同じ速度で攻撃面も広がる。[[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 をどう両立するか。
|