ニュース

DASFとは？AIエージェント35のリスクを定義した安全基盤

2026.03.21 公開 12分で読める

この記事の結論

Databricks DASF v3.0がAIエージェント向けに35の新リスクと6つの制御策を追加。Lethal Trifecta、MCPサーバーの脅威、マルチエージェントの危険性を解説。

「AIエージェントにデータベースへのアクセス権を渡したら、想定外のテーブルまで読みに行ってしまった」

正直、これは珍しい話ではない。RAGシステムのように「読むだけ」のAIとは違い、エージェントは外部APIを叩き、コードを実行し、メールまで送れる。便利だが、セキュリティの勘所がまるで違う。従来のアクセス制御がそのまま通用しない世界に、多くの開発チームが足を踏み入れている。

2026年3月20日、Databricksがこの問題に真正面から向き合うフレームワークを公開した。DASF（Databricks AI Security Framework）v3.0のAgentic AI拡張だ。35の新しいセキュリティリスクと6つの制御策を定義し、AIエージェントを本番環境で安全に運用するための指針を示している。

この記事では、DASFの中身を「そもそも何？」「なぜ必要？」「どう使う？」の順で解きほぐしていく。

そもそもDASFとは何か

DASF（Databricks AI Security Framework）は、AIシステム全体のセキュリティリスクを体系的に整理したフレームワークだ。MITRE ATLAS、OWASP、NIST、Cloud Security Allianceといった業界標準にマッピングされており、特定ベンダーに閉じた話ではない。

v3.0で「Agentic AI」が13番目のシステムコンポーネントとして追加された。これまでの12コンポーネント（データ収集、モデル学習、推論など）に加えて、自律的に行動するAIエージェント固有のリスクを初めて体系化した点が大きい。

バージョン	リスク数	制御策数	主な追加内容
DASF v1.0	55	53	基本的なAIセキュリティリスク
DASF v2.0	62	64	RAG、ファインチューニングの脅威
DASF v3.0	97	73	Agentic AI（35リスク+6制御策）

フレームワーク全体はホワイトペーパーとして公開されており、Google Sheets / Excel形式のコンペンディアムも用意されている。セキュリティチームがそのまま自社のリスク評価に使える実務的な設計だ。

なぜ今、エージェント専用のセキュリティ定義が必要なのか

端的に言えば、エージェントは「読むだけ」のAIと根本的に異なるからだ。

従来のRAGシステムは、ベクトルDBを検索して回答を生成する。アクセス先は事前に定義されているし、書き込み権限は基本的に不要。ところがエージェントは違う。ユーザーのリクエストを受け取ると、自分でタスクを分解し、どのツールを使うか判断し、実行し、結果を評価して次の行動を決める。

DASFが指摘する新しいリスクカテゴリが「Discovery and Traversal（発見と横断）」だ。バグを突いているわけではない。エージェントは設計通りに動いている。だが、解を見つけるために本来そのユーザーがアクセスすべきでないデータパスやツールインターフェースまで踏み込んでしまう。ユーザーが自分の権限ではなく、エージェントの権限を継承してしまう問題が起きる。

Lethal Trifecta（致命的三要素）

Meta の「Agents Rule of Two」や Simon Willison の「Lethal Trifecta」を引用しつつ、DASFは3つの条件が同時に揃うと危険度が急上昇すると整理している。

機密システムや非公開データへのアクセス — エージェントが制限付きデータを取得できる
信頼できない入力の処理 — ユーザープロンプト、外部Webサイト、受信メールなど信頼境界外のデータを扱う
状態の変更や外部通信 — メール送信、SQL実行、コード書き換えなど、ツールやMCP接続で状態を変えられる

3つ全てが揃った状態で、信頼できないデータに間接的プロンプトインジェクションが埋め込まれると、エージェントは「confused deputy（混乱した代理人）」になる。正当な権限で悪意ある操作を実行してしまう。

対策はシンプルだ。3本の足のうち1本を外す。権限を絞る、人間のチェックポイントを挟む、ツール選択前に意図を検証する——どれか1つでも攻撃チェーンが断ち切れる。

35のリスクはどう分類されているのか

DASFは35のリスクを、エージェントの実際の動作に対応する3つのサブコンポーネントと、エージェント間の動態に分類している。

13A: エージェントコア（思考と記憶）

エージェントの推論ループそのものを標的にするリスク群だ。

Memory Poisoning（Risk 13.1） — 偽のコンテキストを注入し、現在および将来の判断を狂わせる
Cascading Hallucination Attacks（Risk 13.5） — マルチターンのループで小さなエラーが反復ごとに増幅し、破壊的なアクションに至る
Intent Breaking & Goal Manipulation（Risk 13.6） — エージェントを本来の目的から逸脱させる

特に厄介なのはCascading Hallucinationだ。1回の推論なら軽微なミスで済むものが、エージェントの「考える→実行する→評価する→次を決める」ループの中で雪だるま式に膨らむ。

13B: MCPサーバーリスク（ツールインターフェース）

エージェントが外部システムと連携するツール側の脅威だ。Model Context Protocol（MCP）が標準化を進めている領域でもある。

Tool Poisoning（Risk 13.18） — ツール定義に悪意ある動作を注入する
Prompt Injection via Tool Descriptions（Risk 13.16） — ツールの説明文にプロンプトインジェクションを仕込み、セキュリティ制御をバイパスする

ツール定義が「信頼できるもの」として扱われがちなのが盲点だ。だが、サードパーティのMCPサーバーを利用する場合、そのツール定義自体が攻撃ベクターになりうる。

13C: MCPクライアントリスク（接続層）

Malicious Server（Risk 13.26） — 悪意あるMCPサーバーへの接続
Client-Side Code Execution（Risk 13.32） — サーバー応答の検証不足によるクライアント側コード実行
Data Leakage（Risk 13.30） — MCPクライアント経由でのデータ漏洩

MCPの採用が広がるにつれて、クライアント-サーバー境界のセキュリティはエージェントの推論そのものと同じくらい重要になる。

エージェント間のダイナミクス

Agent Communication Poisoning（Risk 13.12） — エージェント間通信の汚染
Rogue Agents in Multi-Agent Systems（Risk 13.13） — 監視境界の外で動作する不正エージェント

マルチエージェントシステムが一般化するほど、「1体のエージェントが侵害された場合の影響範囲」が加速度的に拡大する。スケールするほどリスクが複利で増える構造だ。

6つの制御策で何を守るのか

DASFはdefense-in-depth（多層防御）の思想で設計されている。エージェントが「行動する」存在である以上、読み取り専用のアクセス制御では足りない。6つの新しい制御策は、この課題に直接応える。

1. ツールの最小権限（DASF 5, 57, 64）

エージェントには、今のタスクに必要な最小限の権限だけを付与する。RBACやABACで人間のアクセスを制限するのと同じ発想だ。

# 実装例: エージェントのツール権限をタスクスコープで制限
agent_config = {
    "tools": ["query_sales_db", "generate_report"],
    "permissions": {
        "query_sales_db": {
            "allowed_tables": ["sales_summary", "quarterly_targets"],
            "denied_tables": ["employee_salaries", "hr_metrics"],
            "max_rows": 1000,
            "read_only": True
        }
    },
    "scope_duration": "session"  # セッション終了で権限失効
}
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

「営業クエリに答えるときにHRメトリクスツールを呼ぶ必要はない」——当たり前のことだが、エージェントに明示しなければやりかねない。

2. Human-in-the-Loop（DASF 66）

高リスクなアクションの実行前に人間の承認を求める。ただし、DASFは承認疲れ（approval fatigue）のリスクも指摘している。レビュアーに大量の承認要求を送りつければ、それ自体が新しい脆弱性になる。

3. サンドボックスと分離（DASF 34, 62）

エージェントが生成したコードは、使い捨ての隔離環境で実行する。スクリプトの実行権限がホストシステムや外部への通信にまで及ばないようにする。

4. AIゲートウェイとガードレール（DASF 54）

入力・出力の両方にモニタリング、安全性フィルタリング、PII検出を適用する。エージェントが操作されて不適切なデータを表面化させるシナリオに対する防御だ。

5. Observability of Thought（DASF 65）

標準ログは「何が起きたか」を記録する。エージェンティックトレーシングは「なぜそうしたか」を記録する。計画ステップ、ツール選択の推論過程、アクションに至った思考の連鎖。これがなければ、エージェントの判断を監査できないし、推論が侵害されたときに検知できない。

# 実装例: エージェントの思考過程をOpenTelemetryでトレース
from opentelemetry import trace

tracer = trace.get_tracer("agent.reasoning")

def agent_tool_selection(task, available_tools):
    with tracer.start_as_current_span("tool_selection") as span:
        span.set_attribute("task.description", task)
        span.set_attribute("tools.available", str(available_tools))
        
        selected = reasoning_engine.select_tool(task, available_tools)
        
        span.set_attribute("tool.selected", selected.name)
        span.set_attribute("reasoning.chain", selected.reasoning)
        span.set_attribute("risk.level", selected.risk_assessment)
        
        return selected
# 動作環境: Python 3.10+, opentelemetry-api>=1.20
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

6. 最小権限 + スコープ制限の複合制御

Databricksの場合、Unity Catalogによるデータアクセスガバナンス、Agent Bricks Framework、AI Gatewayガードレール、Vector Searchのセキュリティ設定が、これらの制御策と直接マッピングされている。ただし、フレームワーク自体はベンダー非依存で設計されている。

よくある誤解

「うちはDatabricksを使っていないから関係ない」

違う。DASFはDatabricks専用のチェックリストではない。リスクカタログはMITRE ATLAS、OWASP、NISTに準拠しており、97のリスクと73の制御策はどのプラットフォームでも参照できる。コンペンディアム（Google Sheets / Excel）をダウンロードして、自社のエージェントアーキテクチャに当てはめればいい。

「エージェントにファイアウォールを設定すれば十分」

ネットワーク層の防御だけでは不十分だ。エージェント固有の脅威は、正規のAPI呼び出しの中で発生する。Tool Poisoningもプロンプトインジェクションも、ファイアウォールを正常に通過する通信の中に潜んでいる。

「MCPはまだ使っていないから大丈夫」

MCPを明示的に採用していなくても、エージェントが外部ツールを呼び出す仕組みがあれば、13Bと13Cのリスクカテゴリは該当する。ツール定義の汚染やレスポンスの検証不足はプロトコルに依存しない問題だ。

【要注意】エージェントセキュリティで陥りやすい失敗

失敗1: エージェントに管理者権限を付与する

❌ 開発を楽にするためにエージェントにadmin権限を渡す
⭕ タスクごとにスコープを絞った最小権限を設定する

なぜ危険か: Lethal Trifectaの第1条件（機密データへのアクセス）が全開になる。間接的プロンプトインジェクション1発で全データが危険にさらされる。

失敗2: ツール定義を信頼しきる

❌ サードパーティのMCPサーバーのツール定義をそのまま使う
⭕ ツール定義の内容を検証し、許可リスト方式で利用可能なツールを制限する

なぜ危険か: Tool Poisoning（Risk 13.18）の攻撃面になる。ツールの「説明文」にプロンプトインジェクションが仕込まれるケースは、既に研究者によって実証されている。

失敗3: エージェントのログを「何をしたか」だけにする

❌ 入出力のリクエスト/レスポンスだけをロギング
⭕ 思考の連鎖（Chain of Thought）、ツール選択の理由、リスク評価まで記録する

なぜ危険か: エージェントの推論が侵害されたとき、アクションログだけでは異常を検知できない。「なぜそのツールを選んだか」が記録されていないと、事後の監査もインシデント対応もできない。

失敗4: 承認フローを全アクションに適用する

❌ 全てのツール呼び出しに人間の承認を要求する
⭕ リスクレベルに応じて承認が必要なアクションを選別する

なぜ危険か: DASF自身が指摘するように、承認疲れ（approval fatigue）は新たな脆弱性を生む。大量の承認リクエストに慣れたレビュアーが、危険なアクションも機械的に承認してしまう。

結局どう始めればいいのか

3つのステップを推奨する。

ステップ1: 自社のエージェント棚卸し（今日）

まず、今動いているAIエージェント（またはこれから構築するもの）をリストアップする。各エージェントが「何にアクセスでき」「何を変更でき」「どんな入力を受け付けるか」を整理する。Lethal Trifectaの3条件に当てはめるだけで、リスクの濃淡が見える。

ステップ2: DASFコンペンディアムでギャップ分析（今週中）

DASFのGoogle Sheetsコンペンディアムをコピーして、自社の対応状況を記入する。97リスク全てに対応する必要はない。自社のエージェントアーキテクチャに該当するリスクを特定し、優先順位をつける。

ステップ3: 最小権限とObservability of Thoughtを実装（今月中）

最もインパクトが大きいのは、ツールの最小権限設定と思考過程のトレーシングだ。この2つを入れるだけで、攻撃面の縮小とインシデント検知能力が大幅に向上する。

参考・出典

Agentic AI Security: New Risks and Controls in the Databricks AI Security Framework (DASF v3.0) — Databricks公式ブログ（参照日: 2026-03-21）
DASF Agentic AI Extension Whitepaper — Databricks（参照日: 2026-03-21）
Practical AI Agent Security: Agents Rule of Two — Meta AI（参照日: 2026-03-21）
The Lethal Trifecta — Simon Willison（参照日: 2026-03-21）
DASF Compendium (Google Sheets) — Databricks（参照日: 2026-03-21）

この記事を読んで導入イメージが固まってきた方へ

Uravationでは、AIエージェントの要件整理、PoC設計、社内導入、研修まで一気通貫で支援しています。

30分無料相談を予約支援実績を見る

※ 本記事の情報は2026年3月時点のものです。サービスの料金・仕様は変更される可能性があります。最新情報は各サービスの公式サイトをご確認ください。