Bedrock Data「Agent DLP」：権限設計と実行時制御

AIエージェントに業務データへのアクセスを許可するとき、多くの会社がまず考えるのは「どこまで見せるか」という入口の設計です。

誰に、どの範囲の権限を渡すか。

ここまでは、人間の従業員に権限を渡すときの発想の延長で考えやすい部分です。

ですが、2026年7月30日にデータセキュリティ企業のBedrock Dataが発表した「Agent DLP」という製品は、権限を渡した後に何が起きるかを見る制御が、それとは別に要るという論点を具体的に示しました。

この記事では、その発表内容を手がかりに、エージェントの権限設計を「入口」だけで終わらせないための考え方を整理します。

なお本稿は、AIエージェントとデータストアの間のアクセス制御・監視という論点に絞ります。

ID基盤や認証方式そのものの選定、特定製品の導入可否の評価は対象外です。

Agent DLPが示した実行時制御の具体

Bedrock Dataの発表によれば、Agent DLPはエージェントゲートウェイにインラインで配置される形で動作します。

同社は、独立したプロキシを別に立てるのではなく、ゲートウェイ側のフック（連携のための差し込み口）を使う構成だと説明しています。

同社の説明では、Agent DLPはAmazon Bedrock AgentCore GatewayとLiteLLMに対してネイティブなフックを提供します。

同社は、ゲートウェイを通るツール呼び出しを双方向に検査し、とくにエージェントがMCP（Model Context Protocol）のツールへ送るリクエストと、ツール側が返すレスポンスの両方にポリシーを適用すると説明しています。

発表が判定の種類として挙げているのは、遮断する、内容を変更する、一部を隠す（リダクション）、観察モードで記録するだけに留める、の4区分です。

判定の結果は、対象・アクション・データ種別とあわせて記録されるとされています。

製品ページでは、このうち3つが具体例で示されています。

顧客サポート用のエージェントが顧客情報を取得する呼び出しで社会保障番号とカード番号が返ってきた場合は遮断する、メールアドレスと電話番号を含むレスポンスはその項目を除いて返し、エージェントは残りの情報で作業を続ける、リスクの低い操作は中断せず後から確認できるよう記録するだけに留める、という使い分けです。

これらはいずれもBedrock Dataが示した製品の想定例であり、実際の顧客環境で効果を測った結果ではありません。

CEOのBruno Kurtic氏は、実行時のガバナンスを整えることが、AI活用を「リスクをめぐる議論」から「成長のための戦略」に変える、という趣旨のコメントを発表の中で寄せています。

これはベンダー自身の発言であるため、成果を裏づける独立した証拠というより、Bedrock Data社の製品としての立ち位置の説明として受け止めるのが妥当です。

発表されたテレメトリは何を測っているか

Bedrock Dataは発表にあわせて、自社が扱う匿名化されたテレメトリの集計結果を公開しています。

同社の説明では、技術・金融・医療分野の企業環境から得たデータで、規模は70ペタバイト超、データストアが約18万件、IDが54万件超とされています。

この集計で示された数字のうち、本稿に関わるものは2つです。

ひとつは、OAuth連携アプリやサービスアカウントのように、エージェントが認証に使い得る非人間IDのクラスについて、中央値のアプリが55件のデータストアに到達可能だったというものです。

これは中央値の従業員が到達できる3〜4件の10倍以上にあたる、と同社は説明しています。

ここで注意したいのは、これは「実際に配備されたAIエージェントの中央値が55件だった」という意味ではないという点です。

エージェントが認証に利用し得るIDのクラスについて、その到達可能な範囲を測った数字です。

もうひとつは、何らかのデータに到達できるID全体（人間・非人間の両方を含む）のうち、81%が機微データにも到達可能だったという数字です。

ここからが重要な留保です。

これらはBedrock Data社が自社のテレメトリをもとに公表した数字です。

今回確認した資料には、この集計に対する独立した第三者検証の記載はなく、MIFも独自に検証していません。

加えて、今回確認した発表資料には、対象企業数、観測期間、環境の選定方法、機微データの分類方法といった調査方法の詳細が示されていません。

そしてもっとも大事な点として、これらはIDが「どこまで到達できる状態にあるか」を示す権限側のデータです。

エージェントが実際に55件のデータストアへアクセスしたこと、そこからデータ漏えいが起きたこと、Agent DLPがそれを防いだことを示す数字ではありません。

到達可能範囲の管理と、実行時のデータフロー監視を分ける

この区別を踏まえると、発表内容から読み取れる論点は次のように整理できます。

これらの数字が直接示しているのは、エージェントが利用し得る非人間IDに、広い潜在的な到達範囲が付与されている場合がある、ということです。

一方、Agent DLPが対応しようとしているのは、その潜在的な到達範囲の中で、個々のツール呼び出しが実際にどのデータを送受信するかという、別の問題です。

Bedrock Data自身も、到達可能性を把握する機能（posture）と、実行時に制御する機能（runtime control）を、別の制御として並べて説明しています。

そのうえで、この2つを分けて考えることには実務上の意味があると私たちは考えています。

ID・アクセス管理が示すのは、そのIDが「何に到達できるか」です。

実行時のツール呼び出しが示すのは、個々の処理で「実際に何を要求し、何が返されたか」です。

エージェントは短時間に多数のツール呼び出しを行えるため、到達可能性の管理と、実際に流れたデータの監視を、別の制御として設計する必要が出てきます。

MIFの考え方：権限設計のどこに実行時の執行を置くか

私たちは、AIの意思決定を「認識→提案→選択→承認→実行→長期自律」という段階に分けて考えることを、エージェント権限設計の出発点にしています。

これをこの論点に当てはめると、あるリソースに到達してよいという許可と、個々のツール呼び出しで実際にやり取りされるデータの制御は、別の問題だということになります。

入口の設計（どのデータストアに到達できるようにするか）を丁寧に決めても、それだけでは実行時に何が流れたかは分かりません。

だからこそ、実行時に何が送受信されたかを検知し、必要なら止められる設計が、入口の設計とセットで要ります。

ただし、Agent DLPのような製品の位置づけは正確に押さえておく必要があります。

これはツールの実行権限や認可の全体を管理する仕組みではなく、ゲートウェイを通るツール呼び出しのデータフローにポリシーを適用する、実行時の制御層です。

IDの認証、最小権限の付与、ツール単位の認可を置き換えるものではなく、それらを補完するものとして読むのが妥当です。

私たちは、AIが誤りうる前提で仕組みを組むという考え方を、自社の制作工程にも当てはめています。

機械的な検証を重ねたうえで、価値判断が要る一点だけに人の承認を置き、それ以外は仕組みに任せる、という組み方です。

エージェントのデータアクセスも同じ発想で、全ての操作を人が逐一見るのではなく、リスクの高い判定だけを人の確認につなぐ形が現実的だと考えています。

実務での留意点：検査の対象範囲と、公開されていない数値

まず確認しておきたいのが、検査の対象範囲です。

Agent DLPはゲートウェイを通過するツール呼び出しに対して配置されるため、社内のすべてのエージェント通信が自動的に対象になるとは限りません。

直接APIに接続しているツール、別のゲートウェイを経由する経路、その他の送信経路がある場合、それらが同じ検査点を通るのかを別途確認する必要があります。

これは発表されているアーキテクチャから私たちが導いた推論であり、Bedrock Dataがそう述べているわけではありません。

またAgent DLPに限った話でもなく、インライン型の制御を導入するとき一般に確認すべき論点です。

次に、検知の精度についてです。

今回確認した公開資料には、検知精度・誤検知率・見逃し率についての評価値は示されていません。

1回の呼び出しあたりの遅延については、Bedrock Dataが10ミリ秒未満と公表していますが、独立した性能評価は示されていません。

Bedrock Data自身も、まず観察モードでエージェントが何に触れているかを把握し、その後にデータ種別ごとにリダクションや遮断へ絞り込んでいく運用を案内しています。

したがって慎重な進め方は、最初から自動遮断を広く適用するのではなく、観察モードから始め、代表的なトラフィックでポリシーを調整したうえでリダクションや遮断へ広げていく形になります。

もうひとつ整理しておきたいのが、「どの対策が、どこに実装されるものか」という切り分けです。

ここを曖昧にすると、製品を導入しただけで安心してしまう、あるいは逆に社内ルールだけで済ませようとして製品側の機能を使わない、といったすれ違いが起きます。

どのデータストアに最初から到達できるようにするかはID管理・アクセス権限の領分であり、検知されたログを誰がどう扱うかは社内の運用プロセスの役割です。

Agent DLPのような製品が担うのは、その中間にあるデータフローの検査・執行という一点です。

点検の叩き台：4つの観点

以下は、エージェントのデータアクセスをめぐる設計を点検する際の叩き台です。

あくまで一例であり、埋める値や項目の粒度は、自社のリスク許容度・扱うデータの機密度・規制環境に応じて増減させてください。

「主な実装先」の列も、実際に利用する製品構成によって変わります。

観点	点検の問い（例）	主な実装先（一例）
IDと到達可能範囲	エージェントはどのIDで動き、どのツール・データストアへ到達できるか。それは業務上必要な最小限か	ID管理・非人間ID管理・ツール権限
実行時制御の対象範囲	どのツール呼び出しがゲートウェイを通るか。直接接続や別経路が検査を迂回していないか	エージェントゲートウェイ、インターセプター、接続設計
ポリシーと判定	何を観察のみとし、何をリダクション・遮断するか。例外は誰が承認し、ポリシーは誰が更新するか	DLP相当の製品、データ分類、ポリシー管理
監視と対応	どの判定をアラートにし、誰が確認するか。異常時にエージェント停止・認証情報の失効・人手運用への切替をどう行うか	ログ・監視基盤、インシデント対応手順、ID管理

この4つに分けておくと、入口の権限、検査が届く経路、実際の判定、事後の対応が重複なく整理できます。

これらを「正しい設定」として一律に決めることはできません。

自社の業務・データの性質に照らして、埋めるための出発点として使ってください。

まとめ

エージェントに何を許可するかという入口の設計だけで、データアクセスの統制が完成するわけではありません。

Bedrock Dataが公表したテレメトリは、エージェントが利用し得る非人間IDに、広い潜在的な到達範囲が付与されている場合があることを示しています。

ただしこの調査は、実際の漏えい件数や不適切なツール呼び出しの発生率、Agent DLPの防止効果を測ったものではありません。

今回の発表が提示した実務上の論点は、到達可能な範囲を絞る制御と、残った権限の中で実際に流れるデータを検査する制御を、分けて考えることだと私たちは受け取っています。

自社でエージェント導入を進める際は、少なくとも次の4点を確認しておくことをお勧めします。

• エージェントがどのIDで動き、どこへ到達できるか
• どのツール呼び出しが実行時の検査を通るか
• どのデータと操作を許可・記録・変更・遮断するか
• 異常を誰が確認し、どのように停止・失効・復旧するか

実行時のデータ損失防止は、このうちデータフローを検査・執行する一つの制御層です。

ID管理、最小権限、ツール認可、監視、インシデント対応と組み合わせて初めて、エージェントのデータアクセスを継続的に管理できる構成になります。

情報確認について

本記事は2026年8月確認時点で、Bedrock Dataが2026年7月30日に公表した発表「Bedrock Data Launches Agent DLP, Runtime Data Loss Prevention Built for AI Agents」および同社のAgent DLP製品ページを主要な参照元として作成しています。

この発表はBusiness Wireが配信し、Yahoo Financeなどの媒体が転載していますが、いずれも独立した製品検証ではありません。

70ペタバイト超・約18万件のデータストア・54万件超のID、中央値55件と3〜4件の対比、81%といった数値は、いずれもBedrock Dataが自社の匿名化テレメトリをもとに公表したものです。

今回確認した資料には、この集計に対する独立した第三者検証の記載はありません。

MIFも独自に検証していません。

今回確認した発表資料には、対象企業数、観測期間、環境の選定方法、機微データの分類方法、検知精度、誤検知率、見逃し率などの詳細は示されていません。

またこれらの数値は、IDがデータへ到達できる可能性を示すものであり、実際のAIエージェントによる漏えいや不適切なアクセスの発生率、Agent DLPの防止効果を示すものではありません。

製品の機能・対応ゲートウェイ・導入方法・提供条件は変更される可能性があります。

導入を検討される際は、Bedrock Data、Amazon Bedrock AgentCore、LiteLLMの最新の公式情報をご確認ください。