AIエージェントが新たな攻撃対象に
セキュリティ研究者が、AIコーディングアシスタントが情報の持ち出しツールへと変貌し得ること、そして既存の検知コントロールではこれを見抜けないことを実証しました。これは理論上の懸念ではありません。Mozillaの0Dinチームが2026年6月29日に詳細な概念実証として発表した、文書化され再現可能な手法です。
この発表は、同じ週に発生したAmazon Q Developerの重大なCVE、新しいエンタープライズMCP仕様の正式な分析、サイバーセキュリティチームを標的とした偽AIワークスペースによるソーシャルエンジニアリングキャンペーンの報告、そして従来型のアイデンティティガバナンスではAIエージェントを構造的に制御できないとする分析といった、5つの独立した研究と同時期に公開されました。これらは4日間のうちに発表され、いずれも同じ構造的な失敗を指摘しています。すなわち、ガバナンスされたコンテンツ層を持たないAIエージェントは、情報持ち出しの経路となるということです。
この問題は段階的なものではありません。エンタープライズは、アイデンティティとは何か、どのように振る舞うかという比較的安定したモデルを前提に、20年にわたりセキュリティコントロールを構築してきました。しかし、エージェントはそのモデルに当てはまりません。一度認証されると、人間のアイデンティティから権限を継承し、単一のセッションで複数のエンタープライズシステムを横断します。人間が明示的にアクセスを許可していないリソースにも触れ、既存のセキュリティツールが一元的に把握できない断片的なログしか残しません。今週の研究は、この構造的な問題を具体化し、場合によっては期限付きで示しています。MCP 2026-07-28の7月28日公開は、新プロトコルの攻撃対象領域が本格的に有効化される前に、組織がガバナンスギャップに対応するための明確な期間を設定しています。
Kiteworksのセキュアデータ交換は、まさにこの問題に対応するために設計されています。AIエージェントがKiteworksのガバナンスされたAPI層を通じてエンタープライズコンテンツへアクセスする際、すべての操作はポリシーで制御され、すべてのデータアクセスが記録されます。正規・侵害済みを問わず、明示的に許可された範囲外のコンテンツには一切アクセスできません。今週の研究が共通して描写するのは、このガバナンス層が存在しない環境です。どの攻撃ベクトルでも結果は同じで、機密性の高いエンタープライズデータが、アクセス境界が強制されていないAIシステムを通じて、権限のない第三者へ流出しています。
主なポイント
1. AIコーディングエージェントは間接的なプロンプトインジェクションにより情報持ち出しツール化される。
Mozillaの0Dinチームは、通常のGitHubリポジトリに紐づく細工されたDNS TXTレコードを利用してClaude Codeを乗っ取り、リバースシェルを生成し、APIキーやトークン、環境シークレットをエージェントの内蔵セキュリティ層を一切トリガーせずに静かに持ち出せることを実証しました。
2. Amazon Q Developerには攻撃者にクラウド認証情報を渡す重大な脆弱性が存在した。
Wizが公開したCVE-2026-12957（CVSS 8.5）では、コードリポジトリに埋め込まれた悪意あるMCP構成ファイルが、開発者がリポジトリを開いた際に自動実行され、攻撃者管理下のサーバーにクラウド認証情報やローカルファイル、シェル実行へのアクセスを与えてしまうというものでした。ユーザーへのプロンプトや警告は一切ありません。
3. 新しいMCP 2026-07-28仕様は、すべてのセキュリティ責任を開発者に委ねる。
プロトコルがステートレス設計へ移行したことで、テナント間アクセス制御、シークレット管理、権限昇格チェックはすべて個々の実装者に委ねられ、プロトコル層での強制はありません。この仕様は7月28日に公開され、12カ月の廃止猶予期間が始まります。
4. 攻撃者は説得力のある偽AIワークスペースを構築し、エンタープライズデータを収集している。
Push Securityは「Poisoned Tenant」キャンペーンを報告しました。これは、脅威アクターがサイバーセキュリティ担当者を名指しで標的とし、OpenAIの正規通知アドレスから招待を送信することで、偽のOpenAI組織へ誘導する手法です。すべてのメール認証チェックを通過します。
5. 従来型のアイデンティティガバナンスは、マシンスピードで動作するエージェントには対応できない。
新たな「ガーディアンエージェント」モデルの分析によれば、人間の認証イベントを前提としたIAMインフラでは、過剰な権限を継承し、単一セッションで複数のエンタープライズシステムを横断し、一貫した監査証跡を残さない自律型エージェントを制御できません。
組織のセキュリティを信じていますか。本当に証明できますか？
Read Now
Claude Code攻撃：3段階の間接化、1つのリバースシェル
Mozilla 0Din攻撃は、3つのシステムに攻撃要素を分散させることで成立します。リポジトリ自体には悪意ある命令やコードは含まれていません。開発者がリポジトリをクローンすると、Claude Codeは正規のインストール手順を実行します。攻撃が発動するのは初回セットアップ時で、Claude Codeが初期化前に呼び出すとエラーを返すPythonパッケージを使うよう指示されます。
エラーメッセージは「Run: python3 -m axiom init」と表示されます。Claude Codeはエラーを読み取り、リカバリーコマンドを実行します。initを実行すると、DNS TXTレコードから設定値を取得し、それをコマンドとして実行するシェルスクリプトが呼び出されます。この値はbase64でエンコードされているため、リバースシェルのシグネチャがディスクや転送中に平文で現れることはありません。インタラクティブシェルが開発者のマシン上で起動し、攻撃者はそこにロードされたすべての認証情報、APIキー、トークン、環境シークレットへアクセスでき、シェル終了後も持続的なアクセスのためのバックドアを設置できます。
Mozillaの研究者によれば、「リバースシェルは、Claude Codeが実際に評価したものから3段階の間接化を経て到達する：信頼したエラーメッセージ、値を取得するスクリプト、そして直接見ていないDNSレコード」です。静的解析ではDNSルックアップしか見えず、ネットワーク監視では名前解決しか見えません。エージェントは正規のセットアップ手順としか認識しません。いずれも単独では悪意あるものに見えません。攻撃者はDNS TXTレコードを変更するだけでペイロードを随時更新でき、リポジトリ自体の変更は不要です。Claude Codeでリポジトリを開くすべての開発者が危険にさらされます。
これはClaude Codeの内蔵セキュリティ層すべてをバイパスします。これはClaude Code固有の問題ではなく、エラーメッセージを正規の命令として扱うすべてのAIコーディングエージェントに共通する構造的な特性です。ペイロード配信手段であるDNS TXTレコードは、エージェントの脅威モデルの範囲外にあります。AIコーディングエージェントで未知のリポジトリをセットアップする開発者は、既存のエンドポイントやネットワーク制御ではカバーしきれない大幅に拡大した攻撃対象領域で作業していることになります。AIデータ保護には、エージェントが環境データとどのように相互作用するかのモデリングが不可欠です。単に処理を依頼されたコンテンツだけでは不十分です。
Amazon Qと自動実行の問題
Wizが2026年6月26日に公開したAmazon Q Developerの脆弱性（CVE-2026-12957、CVSS 8.5）は、同じ構造的な失敗を別の角度から示しています。根本原因は、拡張機能がワークスペース内に埋め込まれたMCP構成ファイルをユーザーの許可なく自動的に実行してしまう点です。開発者がリポジトリを開くと、そこに悪意あるMCP構成ファイルが含まれていれば、拡張機能がそれを静かに実行し、攻撃者管理下のMCPサーバーにローカルファイルやクラウド認証情報、シェル実行へのアクセスを許可してしまいます。ユーザーへのプロンプトや警告、異常を示す表示は一切ありません。
AWSは4月20日に通知を受け、5月12日にパッチを発行し、今週アドバイザリを公開しました。VS Code、JetBrains、Eclipse、Visual Studio、Amazon Q言語サーバーで修正が提供されています。Wizは、この自動実行パターンはAmazon Q固有のものではなく、ClaudeやCursorなど他のAIコーディングツールでも類似の挙動が確認されていると指摘しています。Wizが特定した具体的な攻撃ベクトルは、偽のコーディングテスト（開発者を標的とする北朝鮮系脅威アクターに関連）、タイポスクワットされたオープンソースパッケージ、人気オープンソースプロジェクトへの悪意あるプルリクエストです。
開発者がミスを犯す必要はありません。通常通りリポジトリを操作するだけで十分です。構成ファイルがエージェントによって自動実行される場合、コンテンツ層でのポリシー評価は行われず、単に実行されるだけです。データポリシーエンジンの概念、すなわちエージェントが操作する前にコンテンツをポリシーで評価するという考え方が、この攻撃では存在しないことが悪用されています。「自動実行、シェル生成、環境継承の組み合わせが、広く使われる開発者ツールに重大な脆弱性を生み出した」とWizは述べています。「1つの悪意あるリポジトリで、開発者のローカルマシンだけでなく、クラウドインフラまで侵害される可能性があるのです。」
MCP 2026-07-28仕様のギャップ
2026年7月28日、MCP 2026-07-28が正式に公開され、現行バージョンの12カ月の廃止猶予期間が始まります。最大の変更点は、MCPがプロトコル層でステートレスになったことです。これにより、エンタープライズ規模のクラウドネイティブなデプロイが可能になりますが、セキュリティチームにとっては、現行プロトコルが提供していたセッション層のセキュリティ保証が新バージョンでは失われることを意味します。
Akamaiによるリリース候補の分析では、ステートレス設計によって新たに生じる攻撃対象領域が複数指摘されています。トラッキング識別子が予測可能な場合、ワークフローの乗っ取りやテナント間アクセスが現実的になります。新たなMCP固有のHTTPヘッダー（MCP-MethodとMCP-Name）はデータ漏洩の経路となり得ます。開発者がAPIキーやトークン、PIIなどの機密入力をこれらのヘッダーに誤ってマッピングすると、リクエスト経路上のすべてのロードバランサー、プロキシ、ログシステムからそれらのシークレットが見えてしまいます。MCP Appsのプロトコル拡張としての導入は、保存型XSSリスクを生み出します。長時間実行される非同期タスクは、攻撃者にとっては作成コストが低く、サーバー側には高負荷となるDoSベクトルとなります。
Akamaiの結論は明快です。「これらの変更は単なる段階的な改善ではありません。セキュリティ責任の所在そのものを根本的に再構築するものです。」現行プロトコルがセッション層で強制していた判断は、新バージョンでは完全に個々の開発者やプラットフォーム運営者に委ねられます。Akamaiの脅威研究シニアディレクターMaxim Zavodchik氏はSecurityWeekに「プロトコルがステートレスモデルへ移行し、リッチなUIアプリや非同期タスクを導入することで、重要なセキュリティ境界は今や開発者の実装次第となった」と述べています。
エンタープライズコンテンツ上でAIエージェントを運用する組織にとって、今最も重要なのはこのガバナンスギャップです。新プロトコルはデータガバナンスやデータ分類、アクセス制御を強制しません。エージェントが取得したコンテンツの記録も残しません。これらのセキュリティ特性はすべて、アプリケーション層で開発者またはプラットフォーム運営者が実装する必要があります。7月28日は明確な分岐点であり、組織は新プロトコルの攻撃対象領域が有効化される前に、ガバナンスされたコンテンツ層を整備する必要があります。KiteworksのSecure MCP Serverは、AI統合ポイントでこのガバナンス層を提供し、MCP 2026-07-28がプロトコル自体に含めていないポリシー強制を実現します。
Poisoned Tenant：AI時代のソーシャルエンジニアリング
Push Securityが報告した「Poisoned Tenant」キャンペーンは、同じ目的に対して異なるアプローチを取っています。技術的なエクスプロイトでAIエージェントを侵害するのではなく、偽のAIワークスペース（正規企業を装ったOpenAI組織）を作成し、標的従業員を招待します。招待メールはOpenAIの正規通知アドレス（noreply@tm.openai.com）から送信され、すべてのメール認証チェックを通過します。技術的には正規のOpenAIからの招待であり、唯一の不正要素は招待先の組織が偽物であることだけです。
Push Securityは、複数の従業員が「Push Security Inc.」というOpenAI組織への招待を受け取ったことでこのキャンペーンを発見しました。これは攻撃者がGmailアカウントで作成したもので、Push Security自身によるものではありません。攻撃の研究のために1件の招待を受け入れた結果、Push Securityの研究開発担当VPであるLuke Jennings氏は、偽組織に追加され、その中にはCEOを装う攻撃者管理のアカウントが1つだけ存在していました。招待された従業員にはOwner権限が割り当てられていました。請求アカウントにはVisaクレジットカードが紐付けられ、正当性が装われていました。プロジェクトには既存のチャットはなく、従業員が入力する機密コンテンツを収集するためのインフラだけが用意されていました。
Push Securityはこのキャンペーンの目的を鋭く分析しています。「単に信頼できるメールチャネルを使ってスパムをばらまきたい攻撃者なら、標的の名前で組織を作ったり、個別従業員を調査したり、クレジットカードを紐付けたりはしません。そうした投資は、従業員が実際に組織に参加し利用を始めて初めて報われます。そしてAIプラットフォーム上では、プロンプトに入力されるデータは極めて機密性が高い場合があるのです。ソースコード、社内文書、顧客データ、セキュリティ調査、戦略計画など。」フィッシングはAIプラットフォームを収集インフラとして拡大しています。攻撃者の目的は認証情報だけではありません。標的が自ら最も機密性の高いコンテンツを提出する環境を構築しているのです。ここでの知的財産の流出リスクは深刻で、偽ワークスペースに提出されたソースコードや戦略計画は、データが組織の管理を離れた時点で回復不能な損失となります。
セキュリティ意識向上トレーニングは必要ですが、それだけでは不十分です。ガバナンス上の課題は、エンタープライズAIアクセスが、入力・出力の両方をセキュリティチームが可視化できる管理下の環境を通じて行われているか、そしてプラットフォーム自体が組織の管理下にあるか、第三者プロバイダーから無監督で借用されていないかという点です。
ガーディアンエージェントとアイデンティティガバナンスギャップ
2026年6月26日にHacker Newsで公開された分析は、「ガーディアンエージェント」モデル、すなわち他のAIエージェントを監査・ガバナンス・終了させるために導入されるAIシステムについて論じています。議論は構造的なもので、従来のIAMは認証イベントを中心に構築されてきました。人間が認証情報を提示し、アクセスが許可または拒否され、セッションが記録されます。しかしエージェントはこの流れに従いません。
エージェントは通常、長期間有効なトークンやAPI認証情報で一度認証されると、セッションやシステム、コンテキストをまたいで継続的に動作します。ガバナンスチェックポイントを経由しません。営業部長の代理で実行する場合、その人物のOAuthトークン、委譲された権限、そして役割変更で蓄積された過剰なアクセス権をすべて引き継ぎます。エージェントは人間が本来行うべき操作と、指示された操作を区別しません。与えられた権限のまま、CRMシステム、コードリポジトリ、ドキュメントストア、内部APIなど、あらゆるアプリケーションを単一セッションで横断します。これらは本来、人間ユーザーが全く異なるコンテキストで利用することを想定してスコープされた認証情報です。
専用のエージェントガバナンスがない環境では、分析で「アイデンティティのダークマター」と呼ばれる現象が生じます。これは、環境内に実在しリスクをもたらしているにもかかわらず、ガバナンスツールからは見えないアイデンティティ活動です。エージェントはアクセス申請ワークフローを経由せず、アイデンティティガバナンスシステムへのオンボーディングもありません。既存アイデンティティから認証情報を継承し、即座に実行を開始します。その結果、正式なガバナンス記録や所有権マッピング、行動ベースラインのない自律型アイデンティティが増加し続けます。ゼロトラストアーキテクチャでは、すべてのエンティティの継続的な検証が求められますが、検証には可視性が不可欠であり、多くの組織ではAIエージェントが認証後に何をしているかを把握できていません。属性ベースアクセス制御（ABAC）は、継続的な検証を実現する技術的手段です。アクセス判断はエージェントのアイデンティティ、コンテンツの機密性、実行コンテキストを毎回評価し、単一の認証イベントでセッション全体を許可するのではなく、都度判断します。
ガーディアンエージェントは、認証境界ではなく実行層で動作することでこれに対応します。継続的なアイデンティティインベントリ、行動ベースライン、実行時の最小権限強制を維持し、従来のIAMツールが提供できなかったガバナンス層を実現します。ガバナンスされたコンテンツ交換との類似は明確で、実際に権限が行使される場所にセキュリティ強制ポイントを移動させることで、アクセス制御を「今エージェントが何をしているか」に基づいて適用できるようにします。これは、数カ月前に与えられた本来の権限に基づくものではありません。
共通の課題：強制されたコンテンツ境界の不在
5つの開示、4日間、1つの構造的失敗。Claude Code攻撃、Amazon Qの脆弱性、MCP仕様のギャップ、Poisoned Tenantキャンペーン、ガーディアンエージェント分析のいずれも、実質的な能力を持ちながらガバナンスされたコンテンツ層を持たないAIエージェントをエンタープライズが展開していることを指摘しています。
Kiteworks 2026年データセキュリティ＆コンプライアンスリスク：年次予測レポートは、AI関連リスクがエンタープライズセキュリティプログラム全体で主要な懸念事項となっていること、そしてAIの導入スピードとガバナンスインフラの構築スピードの間に恒常的なギャップが存在することを明らかにしました。今週の研究は、このギャップが攻撃者の視点からどう見えるかを示しています。攻撃ベクトルが細工されたDNSレコードであれ、悪意あるMCP構成ファイルであれ、偽AIワークスペースへの招待であれ、過剰権限を継承した無管理のエージェントであれ、結果は同じです。機密性の高いエンタープライズデータが、アクセス境界が強制されていないAIシステムを通じて権限のない第三者へ流出します。これらのインシデントが規制対象データを含んでいれば、すべてHIPAAやGDPR、同等のフレームワーク下で報告義務のあるデータ侵害となり、コンプライアンスリスクがセキュリティリスクに加わります。
Kiteworks Compliant AIは、このギャップをデータ層で解決します。エンタープライズAIがKiteworksのガバナンス環境を通じて動作する場合、すべてのエージェント操作はポリシー強制の対象となり、すべてのデータアクセスが完全な監査証跡とともに記録されます。エージェントがどのような認証情報を持ち、どんな命令を受けていても、明示的に許可された範囲外のコンテンツには一切アクセスできません。DLPやデータ分類機能はAPI層で適用され、事後対応ではありません。7月28日のMCP仕様期限は、単なるベストプラクティス以上の緊急性を持ちます。新プロトコルはコンテンツガバナンスをアプリケーション層に明示的に委譲しており、7月28日までにその層を整備していない組織は、プロトコルが保護しない環境でエージェントを稼働させることになります。
CISOダッシュボードは、セキュリティリーダーに対し、エンタープライズAIがいつ、誰によって、何にアクセスしているかを把握する可視性を提供します。今週の研究が描く環境では、この可視性はオプションではありません。AIエージェントの行動をガバナンスするための前提条件です。AIエージェントの導入に関する正式なリスク評価を行う組織は、ガバナンスされたコンテンツ層の不在を最優先の課題として扱うべきです。他のすべてのコントロールは、この層の存在を前提としています。
規制環境下でのAIエージェントのデータアクセスガバナンスについて詳しく知りたい方は、カスタムデモを今すぐご予約ください。
よくあるご質問
Mozilla 0Din攻撃は、攻撃がエージェントが同時に検証しない複数のシステムに巧妙に分割されている場合、内蔵セキュリティコントロールがバイパスされ得ることを示しています。この手法では、悪意あるペイロードはDNS TXTレコード内に存在し、リポジトリやエージェントが直接読むファイルにはありません。エージェントは正規のエラーメッセージに従い、正規のリカバリーコマンドを実行します。そのコマンドがスクリプトを呼び出し、DNSルックアップを行います。エージェントはペイロード自体を認識せず、各ステップが正規のものに見えます。攻撃は、エラーメッセージを命令として信頼するエージェントの特性を突いており、リポジトリコンテンツをスキャンする標準的なコントロールでは検知できません。この脅威を理解しようとする組織は、開発者が利用するAIコーディングツールにAIデータ保護ポリシーがどのように適用されているか、単に処理対象のコンテンツだけでなく、ツール自体にも目を向けるべきです。ゼロトラスト生成AIの原則、すなわち環境入力を検証なしに信頼しないという考え方がここに直結します。AIコーディングエージェントの侵害シナリオを明示的にカバーしたインシデント対応計画を策定することで、こうした攻撃が検知された際のエスカレーション経路をセキュリティチームに明確に示すことができます。
パッチはCVE-2026-12957自体には対応していますが、Wizは根本的な自動実行パターン、すなわちワークスペースを開いた際にユーザーの許可なくMCP構成ファイルが実行されるという挙動がAmazon Q固有のものではないと指摘しています。他のAIコーディングツールでも類似の挙動が確認されています。AIコーディングアシスタントを運用する組織は、これらのツールに同様の自動実行挙動がないか監査すべきです。より広い観点では、このインシデントはサードパーティリスク管理が、開発者が利用するAIツールにも及ぶことを示しています。チーム間で共有されたり外部から調達されたリポジトリは、AIコーディングエージェントが開発環境で稼働している場合、新たなリスククラスをもたらします。ベンダーリスク管理プログラムには、AIツール層を独立したリスクカテゴリとして含めるべきです。ツールが生成するサードパーティコードだけでなく、ツール自体のリスクも評価対象としましょう。サプライチェーンリスク管理の実践をAI開発ツールにも拡張することで、従来の依存関係やパッケージに焦点を当てたソフトウェアサプライチェーンレビューでは見落としがちなギャップを埋めることができます。
まずはインベントリから始めましょう。MCP接続を利用するすべてのAIエージェントの導入状況、それらのエージェントがアクセス可能なコンテンツ、そしてその権限の根拠を把握します。新仕様のステートレス設計では、テナント間アクセス制御、シークレット管理、権限昇格防止はプロトコル層で強制されません。これらはMCPサーバーを構築・運用する側が実装する必要があります。データガバナンスポリシーで、エージェントがどのコンテンツに、どの条件下で、どのようなログ記録とともにアクセスできるかを7月28日までに明確化する必要があります。規制データ（PHI、財務記録、防衛関連情報など）上でAIエージェントを運用している組織にとって、この仕様変更は単なるセキュリティイベントではなくコンプライアンスイベントです。KiteworksのSecure MCP Serverは、プロトコルの仕様に関わらずAI統合層でガバナンス境界を強制できるため、エコシステム全体の対応を待てない組織にとって実用的な解決策となります。エージェントのアクセスログを初日からSIEMプラットフォームに連携することで、新しいステートレスプロトコルが標準で備えていないリアルタイム異常検知能力をセキュリティチームに提供できます。
従来型フィッシングは、ユーザーに悪意あるリンクをクリックさせたり、偽サイトに認証情報を入力させたりする手法です。Poisoned Tenantキャンペーンは正規のプラットフォームインフラを利用します。招待自体は本物で、メールはOpenAIの正規通知アドレスから送信され、すべてのメール認証チェックを通過し、プラットフォームも正規のOpenAIサービスです。不正なのは招待先の組織だけです。悪意あるリンクや送信者のなりすましを検知するメールセキュリティコントロールでは、技術的に不審な点がないため検知できません。Push Securityは、従業員に予期しない組織招待の検証を徹底させ、SaaS組織のメンバーシップを監視することを推奨していますが、これはより広いアーキテクチャ上の課題も示唆しています。エンタープライズAIアクセスは、セキュリティチームが従業員の提出内容を可視化できる管理環境を経由させるべきです。セキュアコラボレーションプラットフォームは、ポリシー強制や監査ログによる可視性を提供し、標準的なChatGPTワークスペースにはない透明性を実現します。これにより、情報持ち出しイベントの発生を攻撃者から知らされる前に把握できます。SaaS組織のメンバーシップアクションすべてにMFAを強制することで、このキャンペーンでのOwner権限付与も、機密データが提出される前に検知できたはずです。
ガーディアンエージェントは、エンタープライズ環境で動作するAIエージェントのアイデンティティと行動をガバナンスする制御層です。従来のIAMツールが認証境界でアクセスを管理するのに対し、ガーディアンエージェントは実行層で動作し、すべての自律型アイデンティティの継続的なインベントリを維持し、行動ベースラインを構築し、ツール呼び出しやデータアクセス、クロスシステム移動に対して実行時の最小権限ポリシーを強制します。このコンセプトは実運用での採用が進みつつあります。実現の前提条件は、エージェントアイデンティティにゼロトラストデータ交換の考え方を適用すること、すなわちすべてのエージェント操作を認証だけでなく検証することです。6月26日の分析では、これには実行層向けの制御プレーンが必要であり、既存のIAM、PAM、CIEMツールでは、エージェントが複数システムを横断するセッションを追跡し、各ステップでポリシーを強制することは想定されていないと指摘しています。AIデータガバナンスプログラムで、AIエージェントを明確なコンテンツアクセス境界を持つガバナンス対象アイデンティティとして扱うことが、ガーディアンエージェント制御を実効性あるものとする組織的前提条件です。エージェントの認証情報スコープにデータ最小化を適用し、担当タスクに必要なアクセス権だけを継承させることで、ガーディアンエージェントツールの成熟を待たずとも被害範囲を最小化できます。
追加リソース
- ブログ記事
AIプライバシー保護を手頃に実現するゼロトラスト戦略 - ブログ記事
77%の組織がAIデータセキュリティで失敗している理由 - 電子書籍
AIガバナンスギャップ：2025年に91%の中小企業がデータセキュリティでロシアンルーレット状態に - ブログ記事
あなたのデータに「–dangerously-skip-permissions」は存在しない - ブログ記事
規制当局は「AIポリシーの有無」ではなく「実効性の証明」を求めている