# 致命的な 3 大要因を打ち破る: Asana によるエージェント型 AI セキュリティの考え方 > 業界がまだ基本を理解していない中、Asana がどのように責任を持ってエージェント型 AI を構築しているかをご紹介します。 Source: https://asana.com/inside-asana/how-asana-thinks-about-agentic-ai-security ## 致命的な 3 大要因を打ち破る: Asana によるエージェント型 AI セキュリティの考え方 _エージェント型 AI は、業界がまだ解決していないセキュリティリスクのカテゴリをもたらします。 Asana では次のように考えており、AI 機能全体でセキュリティの不変条件を設けています。_ ### **問題** エージェント AI システムは、単に質問に答えるだけではありません。 文書を読み、アクションを実行し、ツール間で調整を行います。 できることが多ければ多いほど、攻撃対象領域は大きくなります。 従来のコードとは異なり、LLM にはこれを根本的に困難にする特性があります。つまり、LLM**は命令とデータを確実に区別できないのです。** LLM に提供されるものはすべて同じストリームに入るため、慎重に作成されたデータは、正当な指示と同じようにモデルを乗っ取ることができます。 これがプロンプトインジェクションの根源であり、Simon Willison 氏はこれを LLM ベースのアプリケーションの「原罪」と[呼ん](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/)でいます。 これは理論上の話ではありません。 研究者は、[Microsoft 365 Copilot](https://simonwillison.net/2025/Jun/11/echoleak/)、[GitHub の MCP サーバー](https://simonwillison.net/2025/May/26/github-mcp-exploited/)、[Slack AI](https://simonwillison.net/2024/Aug/20/data-exfiltration-from-slack-ai/)など多数のツールに対してこの攻撃クラスを実証しています。 Bruce Schneier[は率直にこう述べています](https://www.schneier.com/blog/archives/2025/08/we-are-still-unable-to-secure-llms-from-malicious-inputs.html)。業界はまだ、このクラスの攻撃に対する堅牢な防御を持っていません。 では、業界が基本を理解していない状況で、エージェント型 AI を責任を持って構築するにはどうすればよいのでしょうか？ ### **致命的な3つの要素** Willison 氏は、中核となるリスクを 3 つの能力に分類しています。これらの能力が組み合わさることで、危害をもたらす条件が生まれます。 - **機密データへのアクセス。** エージェントは、機密情報や個人情報を読み取ることができます。 - **信頼できないコンテンツへの曝露。** エージェントは、悪意のある指示が隠されている可能性のある入力を処理します。 - **外部とコミュニケーションを取る機能。** エージェントは、システムの外部に情報を送信できます。 3番目の要素に関する有用な修正点: これは単なる外部へのコミュニケーションではなく、実際には**副作用を生み出す**能力です。 攻撃者のサーバーへのデータの流出は典型的な例ですが、ワークスペース内のすべてのプロジェクトのタイトルを静かに変更したり、機密コンテンツを間違った内部チャネルに送信したりする悪意のある指示も、同じ形の問題です。 「外部とのコミュニケーション」は簡略表現ですが、実際に防御しているのはそのより広い範囲です。 3つの要素のうちの 1 つは管理可能です。 通常、2 つの要素を組み合わせた場合でも同様です。 しかし、3 つすべてが集まると、実行可能な攻撃経路が生まれます。 重要なインサイト: **3 つのうちの 1 つを破壊することで、全体的なリスクが大幅に軽減されます。** プロンプトインジェクションを完全に解決する必要はありません。 誰も解決できていません。 3つの条件が簡単に共存できないようにする必要があります。 [Korny Sietsma 氏はこれに基づき、サンドボックス、タスクの分解、最小権限、ヒューマンインザループなどの軽減策にこの 3 つの要素をマッピングしています](https://martinfowler.com/articles/agentic-ai-security.html)。 これらは基礎ブロックです。 問題は、それらをどのように運用可能にするかです。 ### **コンテキスト、チェックポイント、コントロール** 私たちは、致命的な 3 つの要素に直接対応する 3 つの柱を中心に考えを整理しています。 それぞれが 1 つの脚を制限します。 Asana には、いくつかの AI 機能があります。 AI チームメイトは、ワークスペース内で独自のメンバーシップと権限を持つエージェントとして参加します。 その他の AI 機能はユーザーとして動作し、そのユーザーがすでにアクセスできる範囲が境界となります。 以下の不変項は、サーフェスが最大のエージェントの場合に焦点を当てています。サーフェスごとに実装が異なる場合は、その旨を明記します。 #### **コンテキスト: AI が参照できる情報を管理する** _トライフェクタの脚: 機密データへのアクセス_ エージェント型 AI を有用にするには、コンテキストが必要です。 課題は、万能鍵を渡すことなく、役に立つのに十分な情報を提供することです。 Asana の基本的な不変項は最小権限の原則であり、その具体的な表現はサーフェスによって異なります。 個々のユーザーとは別のメンバーシップを持つ AI チームメイトの場合、境界はチームメイトの権限とユーザーの権限の共通部分です。ユーザーとして動作する AI 機能の場合、境界は単にそのユーザー自身のアクセスです。 いずれの場合も、Asana での他のすべてのやり取りを管理するのと同じサーバー側の認可レイヤーが AI のアクセスを管理します。 AI 機能には、高度なアクセス権限は付与されません。 Asana のアクセス制御システムの外側ではなく、その内部で動作します。 コンテキストの定義には、Asana 内のデータへのアクセスを規制することだけでなく、エージェントがやり取りできる外部の連携も同様に含まれます。 現在、連携にはユーザーによる明示的な認可が必要ですが、Asana ではエージェントごとの詳細な制御経路を開発中です。 これにより、組織は、リスクの高いインプットを処理する AI チームメイトの連携権限を制限することができます。 当社のアーキテクチャの中核にある不変の原則は明確です。AI が_見る_ことができるものの境界は、ハードコードされた製品のデフォルトではなく、データ所有者によって動的に決定されるものでなければなりません。 攻撃者が悪意のある指示を AI のコンテキストに忍び込ませたとしても、AI が実際に_見る_ことができるものは、他のすべてと同じ権限モデルによって制限されます。 #### **チェックポイント: AI が聞く内容をフィルタリングする** _トライフェクタのレッグ: 信頼できないコンテンツへの露出_ これが一番難しい部分です。 ワークマネジメントプラットフォームでは、AI が読み取るのは主にユーザーが作成したコンテンツです。タスク、コメント、添付文書などです。 その一部は組織外からのものです。 読み取りを拒否することはできません。 その代わりに、**チェックポイントを設定します。チェックポイント**とは、信頼できる意図と恣意的なコンテンツを区別し、何か問題があると思われる場合に人間が介入できる場所です。 - **ソースを考慮した指示の処理。** AI 機能は、作成者の信頼性とソースごとにコンテンツにタグを付けるため、モデルは、その過程で遭遇する任意のコンテンツの指示よりも、権限のあるユーザーからの指示を優先することができます。 これにより、プロンプトインジェクションの攻撃対象領域は狭まりますが、完全になくなるわけではありません。モデルは引き続きコンテキストに基づいてすべてを読み取るため、セキュリティ保証は絶対的なものではなく、部分的なものです。 このアプローチの限界については、後ほど説明します。 - **ロギングとフォレンジック調査。** すべてのモデル呼び出しは、その入力、出力、アクター、機能コンテキスト、およびダウンストリームイベントとともにログに記録されます。これには、オートメーションが触れたワークグラフオブジェクトや、出力に表示された URL などが含まれます。 エラー率やコストの急増などの運用シグナルに対しては、自動的にアラートが送信されます。 セキュリティに関連する異常については、これらのログを使用して、事後的に人間による調査を行うことができます。 Willison 氏が指摘するように、ほとんどの攻撃を検知するパターンベースの検知であっても、それだけでは不合格です。可視性と調査能力は、壁ではなく、私たちが構築する耐久性のある基盤です。 - **ヒューマン・イン・ザ・ループ設計。** AI 機能は、静かに不可逆的なアクションを実行するのではなく、人間によるレビューのために作業を表示します。 - **タスクの分解と制限付きアクション。** 複雑なワークフローはより小さなステージに分割され、AI 機能が実行できるアクションは、自由に選択できるものではなく、意図的に制限されています。 これらのいずれも、個別に完全な防御力を持つものではありません。 これらを組み合わせることで、多層防御が形成されます。 #### **コントロール: AI がアクションを実行できる対象を制限する** _トライフェクタの 3 番目の脚: 副作用を生み出す能力_ 3 つ目の脚は、実際の攻撃のほとんどが行われる場所です。 攻撃者が AI に機密データを URL に埋め込ませたり、連携を通じて送信させたり、他の人が依存するレコードを変更させたりすることができれば、攻撃は成功します。 Asana は、この点に関していくつかのカテゴリのコントロールに投資しています。 - **LLM の出力を信頼できないものとして扱う。** 生成されたコンテンツは、Asana AI によって生成されたものであるため、信頼性が高く評価されることはありません。 他のユーザー生成コンテンツと同じ検証およびレンダリングのフローを通過します。 - **インパクトの大きなアクションには、人間による承認が必須。** 特定のアクションカテゴリでは、AI の信頼度やリクエストのルーチン性に関わらず、常に明示的な人間による承認が必要です。 AI チームメイトの場合、アクセス権を引き上げるアクション (権限の変更、メンバーの追加) やデータを破棄するアクション (削除) がこれに含まれます。 AI はこれらを提案することはできますが、自ら実行することはできません。 - **リンク処理のガードレール。** AI が生成したコンテンツに含まれる外部 URL は、ユーザーに届く前に処理されます。 入力に表示されなかった新しい URL は、追加の精査を受け、ラベル変更されたアンカーテキストとしてではなく、完全な、隠されていないフォームで表示されます。そのため、AI を悪用して、情報漏洩エンドポイントを「こちらをクリックして要約をご覧ください」というフレンドリーなメッセージに装飾することはで��ません。 - **汎用のアウトバウンド HTTP はありません。** AI 機能には、オープンエンドの「任意の URL にリクエストを送る」プリミティブはありません。 外部連携は、それぞれの認可を受けたスコープされたチャネルを経由します。 - **アクション監査証跡**。 AI 機能が実行するすべての書き込み、変更、およびアウトバウンドアクションは、それを促したモデル呼び出しとともにログに記録されるため、調査担当者は、AI に何が要求されたかだけでなく、AI が実行した内容を再構築できます。 目標は、外部とのコミュニケーションを不可能にすることではありません。 AI 機能は、リンクを参照し、タスクを更新し、有用なアウトプットを生成する必要があります。 目標は、ユーザーが意図していない_方法で、AI がそれを隠密に_行うことができないようにすることです。 ### **AI が出力する値のパターン** このフレーム内では、同じ具体的なサブ問題が繰り返し発生します。AI 機能が何か (オブジェクト ID、受信者、URL) を生成し、ダウンストリームコードがそれに基づいて動作します。多くの場合、AI 自体よりも広範な権限で動作します。 ハルシネーションとプロンプトインジェクションは同じ場所に存在します。モデルが出力する値が信頼されるのです。 これらの値に対する設計レビューのチェックリストとして、4 つのパートからなるパターンを使用します。 - 検証を実行する前に、そもそも AI が生成できるものを**制限する**。 - AI が生成したすべての値を、他のすべての値と同じ認可レイヤーに対してサーバー側で**検証します**。 モデルは信頼できないクライアントとして扱われます。 - AI がその選択をした_理由_を説明するのに十分な構造化されたコンテキストを保持することで、その選択を**正当化する**。 これにより、後で調査、評価、インシデント対応を行うことが可能になります。 - 値が高リスクである場合、または予想される範囲外である場合は、フリクション、フォールバック、または人間によるレビューを伴う**エスカレーションを行います**。 全体を通じての考え方:**モデルの動作は、主要なセキュリティ制御であってはなりません。** より良いプロンプトや「モデルにそのようなことはしないように指示した」という説明は、多層防御として有用ですが、持続的な制御はモデルを取り巻くシステムに存在します。 ### **基本原則に基づく** これらの選択は臨時のものではありません。 [Asana が公表している AI の基本原則](https://asana.com/ai-principles)に基づいています。 **意思決定に責任を持つのは人間であるという考え方**が、チェックポイント指向の設計の原動力となっています。 AI はアシストしますが、人間はプロセスに関与し、責任を負います。 **当社は安全性を重視しており、**そのため、摩擦を生む場合でも、階層化されたコントロールへの投資を正当化しています。 他のアプローチでは、AI 機能がより複雑な仕事を引き受けるにつれ、リスクが増大します。 **当社は透明性を高めることを重視しています。**それがこの記事を書く理由です。 エージェント型 AI のセキュリティはまだ解決されていません。 しかし、これらのリスクについての私たちの考え方や、私たちが実施しているリスク軽減策についてオープンにすることで、より幅広いコミュニティが共通の課題に取り組む上で前進するのに役立ち、また、私たちの改善につながる精査を促すことにもなります。 ### **現実的な限界** **プロンプトインジェクションは依然として根本的に未解決であり**、間接的なプロンプトインジェクション (ユーザーが直接提供するコンテンツではなく、AI が作業中に取得するコンテンツに埋め込まれた敵対的な指示) は、2026年に業界が最も大きな打撃を受けたバリエーションです。 **ソースを認識するタグ付け**は役に立ちますが、モデルはタグを尊重することを選択する必要があるため、このギャップを完全に埋めることはできません。 当社のチェックポイントはリスクを大幅に軽減しますが、リスクを排除するものではありません。 指示とデータがコンテキストウィンドウを共有する限り、検索、公開フォーム、または連携を通じて取得された悪意のあるインプットが時折見落とされることがあります。 当社はこれを積極的かつ継続的な投資分野として扱い、外部で作成されたコンテンツがエージェント型機能に到達する可能性のあるあらゆる経路をより詳細に精査しています。 [LLM エージェントを保護するためのデザインパターン](https://simonwillison.net/2025/Jun/13/prompt-injection-design-patterns/)に取り組むことで、有望な方向性が示されていますが、業界のコンセンサスはまだ形成途中です。 **脅威の状況は急速に変化しています。** [目に見えない画像ベースのプロンプトインジェクション](https://brave.com/blog/unseeable-prompt-injections/)から、マルチステップの情報流出チェーンまで、新しいベクトルが次々と登場しています。 当社は、新しい脅威が出現したときに新しい軽減策を追加できるように、コントロールを階層化し、組み合わせ可能なように設計しています。 これは軍拡競争であり、一度で解決できる問題ではありません。 [OWASP Top 10 for LLM Applications](https://genai.owasp.org/llm-top-10/)は、継続的に参照するのに便利な資料です。 私たちは、これらのギャップをペースダウンの理由とは考えていません。 慎重になるべき理由だと考えています。 致命的な 3 大要素は、リスクを示しています。 コンテキスト、チェックポイント、コントロールは、行動のためのフレームワークを提供してくれます。 また、どのチームも単独でこの問題を解決することはできないため、脅威の状況が進化する中でこれらの表面を強化するために、リサーチおよびお客様のパートナーとともに積極的に投資を行っています。 #### **リファレンス** - Simon Willison、[「The lethal trifecta for AI agents」、](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/)2025年 6月 - Korny Sietsma 氏、[「Agentic AI and Security」、](https://martinfowler.com/articles/agentic-ai-security.html)Martin Fowler、2025年 10月 - Bruce Schneier 氏、[「We Are Still Unable to Secure LLMs from Malicious Inputs」、](https://www.schneier.com/blog/archives/2025/08/we-are-still-unable-to-secure-llms-from-malicious-inputs.html)2025年 8月 - [Asana AI の基本原則](https://asana.com/ai-principles) - OWASP、[「Top 10 for LLM Applications」](https://genai.owasp.org/llm-top-10/) - [管理者コンソール内のマイクロフレームワーク](/ja/inside-asana/microframeworks-admin-console) エンジニアリング すべての Asana 展開には管理者コンソールがあります。 IT 管理者は、パスワードの要件、役割と権限、Dropbox からファイルを添付できるかどうか、デフォルトで新規プロジェクトを閲覧できるユーザーなどを設定し、会社における Asana の使用方法を構成します。Asana が成長するにつれて、管理者コンソールには長年にわたるカスタムロジックや一時的な ... - [仕様主導の開発: メリットと 3 か月間で学んだこと](/ja/inside-asana/spec-driven-development) エンジニアリング #### スタッフソフトウェアエンジニア 3 か月が経過した時点で、追加された構造が役に立つ場面と邪魔になる場面がより明確になりました。あるエンジニアがデータ移行の準備を進める中で、作業計画に仕様駆動型開発 (SDD) を採用することにしました。 SDD は、早期にギャップを特定し、アプローチのレビューを容易にし、エージェントに明確な方向性を示すことを目的としていました。 その結果生まれた計画は詳 ... - [Enzyme からの移行は 2 週間で完了しました。本来は 5 年かかるはずでした。](/ja/inside-asana/migrating-off-enzyme-2-weeks) エンジニアリング 最近、AI を使って、数年にわたるエンジニアリング作業を 1 スプリント程度で完了させました。 その方法と、それがなぜ可能性についての考え方を変えたのかをご紹介します。5 年間の問題2022年、Asana はフロントエンドのテストスイートを、古くなったテストライブラリの Enzyme から React Testing Library (RTL) に移行する ... - [AI チームメイトがメモリを構築する仕組み：仕事を再利用可能な知識に変換](/ja/inside-asana/ai-teammates-turn-work-into-reusable-information) 人工知能 (AI) エンジニアリング ほとんどの AI 製品は、メモリを個人的な機能として扱い、1 人のユーザーまたは 1 回の会話に関する事実を記憶します。 しかし、チーム間でコラボレーションを行う AI には、根本的に異なる種類のメモリが必要です。 AI システムは、以前に学んだことを土台にしてさらに発展させることができると、より有用になります。 しかし、エンタープライズソフトウェアにおい ... - [致命的な 3 大要因を打破: Asana によるエージェント型 AI セキュリティの考え方](/ja/inside-asana/how-asana-thinks-about-agentic-ai-security) エンジニアリング - [スタフセキュリティエンジニア](/author/varun-prusty) エージェント型 AI は、業界がまだ解決していないセキュリティリスクのカテゴリをもたらします。 Asana では次のように考えており、AI 機能全体でセキュリティの不変条件を設けています。問題エージェント AI システムは、単に質問に答えるだけではありません。 文書を読み、アクションを実行し、ツール間で調整を行います。 できることが多ければ多いほど、攻撃対 ... - [エンジニアリング](/inside-asana/engineering-spotlight)