AI データ漏洩防止: プロンプト、RAG、メモリ、エージェントを介した機密データの漏洩を阻止する方法

導入

通常、機密データが AI システムからオペラのようなドラマとともに残されることはありません。ドアを蹴破ったり、スポーツカーを盗んだり、警報を鳴らしながら夜の闇に消えることはありません。多くの場合、それは、無害な回答、取得されたドキュメントの塊、ツールの結果、詳細なログ行、または単に過剰なアクセスと十分な監視が与えられなかったモデルによって生成された陽気な要約の中に隠れて、静かに歩き出します。

それが最初にはっきりと言うべきことだ。 AI データ漏洩は SF の問題ではありません。これはエンジニアリングの問題であり、ほとんどのエンジニアリング問題と同様に、システムが実行していると人々が想定していることと、実際に実行が許可されている内容との間のギャップで増大します。チームは内部文書化用の副操縦士を構築します。美しく機能します。その後、誰かがそれをより広範なデータ ソースに向け、同じユーザー権限を維持し、メモリを追加し、いくつかのツールを追加すると、突然、システムは単に無害なテキストを要約するだけではなくなります。それは礼儀正しい泥棒のような自信を持って、私的な資料の倉庫をさまよっています。

危険なのは、モデルが悪であるということではありません。モデルは悪くないよ。モデルは最悪の意味で従順だ。指示、コンテキスト、取得したテキスト、非表示のプロンプト、古いメモリ、ツールの出力を 1 つの実用的なスープに混ぜ合わせて、役に立ちそうなものを生成します。周囲のアーキテクチャがずさんだと、有用性が過剰に共有されてしまいます。データの境界が弱い場合、利便性は漏洩となります。そして、チームがシステム設計よりも即効性のある言葉遣いを信頼している場合、物語は、多くの回避可能な物語が終わる方法で終了します。つまり、驚き、当惑、そして誰も望まなかった会議で終わります。

この記事は、その結果を防ぐことについてです。最新の AI システムにおける実際の漏洩面、単純な防御が失敗する理由、実際に機能する制御、および技術チームが実行および拡張できる小規模だが有用なゲートウェイを構築する方法について見ていきます。ここでの口調は意図的に実用的です。重要なのは、賢明に聞こえることではありません。重要なのは、誰かが熱心なプロンプトを書いたからといって、間違った人にデータを渡さない AI システムの出荷を支援することです。

AI漏洩がなぜこのような普通の方法で起こるのか

従来のアプリケーションは通常、役割をかなり適切に分離します。入力は 1 か所から受信され、ビジネス ロジックは別の場所に存在し、アクセス許可は明示的なコード パスによって強制されます。 AI システムはそれらの境界を曖昧にします。自然言語は入力プレーンとコントロールプレーンの両方になります。取得した知識は証拠と攻撃対象の両方になります。ツール呼び出しは機能と露出の両方になります。製品のスライドでは無害に見えるメモリですら、何がどのくらいの期間保存されるのかについて誰もが規律を持たなければ、ゆっくりとした漏洩になる可能性があります。

これが、通常の製品チームが問題を過小評価している理由です。彼らはモデルをワークフローに統合していると考えています。実際には、複数の信頼ゾーンからのデータをうまく再結合する確率的ミドルウェア層を導入しています。システム プロンプトに「決して秘密を明かさないでください」と表示されれば、それは立派に聞こえます。また、モデルがこれらの秘密を依然として認識し、それを推論し、設計者が予期しない形式でパッケージ化するように操作される可能性があるという根本的な事実も変わりません。

エンタープライズ AI アプリケーションのセキュリティを確保するための Microsoft のガイダンスでは、データ漏洩、即時挿入、ガバナンスのギャップは、組織が AI を導入する際に直面する主な懸念事項の 1 つとして、この点を冷静な企業言語で強調しています。文書は丁寧ですが、メッセージは単刀直入です。 AI が広範囲にアクセスでき、監視が弱い場合、機密情報は漏洩します。これがわかれば、正しい質問は「プロンプトをより厳格にするにはどうすればよいですか?」ではなくなります。正しい質問は、「なぜモデルはこのマテリアルを見ることができる位置にあるのか、そしてプロンプトが書き込まれる前にどの制御が失敗したのか?」ということになります。

その考え方の変化が重要です。成熟した AI セキュリティは、モデルが最初のトークンに触れる前から始まります。それは、データの分類、取得境界、アクセス制御、ロギング規律、およびツールの承認から始まります。つまり、AIのデータ漏えい防止は、AIバッジをつけたシステムエンジニアリングがほとんどだということだ。

実際の漏れ表面

「AI システム」について、あたかも 1 つの箱であるかのように語るのをやめるのに役立ちます。通常、漏れは 5 つのパスのいずれかを介して発生し、各パスには独自の障害モードがあります。

最初のパスはプロンプト境界です。チームはユーザーのプロンプトを気にし、プロンプトが複数の指示源のうちの 1 つにすぎないことを忘れがちです。モデルは、隠されたシステム命令、取得したドキュメント、要約されたチャット履歴、および外部ツールからのデータを取り込むこともあります。これらのソースのいずれかに敵対的なコンテンツまたは広範すぎるコンテンツが含まれている場合、プロンプトの境界はすでに侵害されています。 LLM アプリケーションのリスクに対する OWASP の取り組みは、チームにプロンプ​​ト インジェクションをパーティー トリックのように扱うのをやめ、コントロール プレーンの問題のように扱うよう強制するため、まさに役に立ちました。

2 番目のパスは取得です。検索拡張生成は、アーキテクチャ図ではきれいに見えます。ベクトル インデックス、クエリ、ランキング ステップがあり、いくつかのチャンクがコンテキスト ウィンドウに表示されます。これらのチャンクには、間違ったテナントからの情報、古いアクセス許可、汚染されたドキュメント、未レビューのエクスポート、またはモデルの隠された指示を伝えるテキストが含まれている可能性があることを思い出すまで、これは制御されているように見えます。回収は劇的なものではないため、漏洩面の中で最も過小評価されていることがよくあります。検索するような感じです。しかし、生成レイヤーを最上位に置いた検索では、インデックス作成の間違いがすぐに開示イベントに変わる可能性があります。

3 番目のパスは記憶です。製品チームが記憶を好むのは、アシスタントの緊張感が薄れるからです。メモリは偶然に増加することが多いため、セキュリティ チームはこれをあまり好まない傾向があります。おそらくセッションキャッシュは長期記憶になるでしょう。おそらく、内部要約ストアが意図したよりも長く詳細を保持し始める可能性があります。おそらく、個人を特定できる情報が、機密性の高いワークロード向けに設計されていない便利な機能に保存されている可能性があります。メモリは、フレンドリーな UX のアイデアが密かに保持ポリシーの問題となる場所です。

4 番目のパスはツールの使用です。チケット発行システム、CRM、コード リポジトリ、カレンダー、SQL ゲートウェイ、または内部 API を呼び出すことができるモデルは、もはや単なるテキスト エンジンではありません。アクション系です。それは生産的になる可能性があります。また、過剰な許可はコストが大幅に高くなるということも意味します。ソフトウェアと AI エージェントの ID と認可に関する NIST の最近の取り組みは、多くのチームが無視しようとしている点に対処しているため、ここで貴重です。AI システムが動作できるようになると、ID と認可は優れたアーキテクチャのトピックではなくなり、中央の制御ポイントになります。

5 番目のパスは出力とテレメトリです。取得、メモリ、ツールが適切に制御されている場合でも、システムから回答、トレース、デバッグ ログ、評価データセット、分析ダッシュボード、およびコピーされたチャット記録が漏​​洩する可能性があります。チームはよく「UI では機密を公開していません」と言いながら、同じコンテンツがログ、トレース、サポート エクスポート、またはレッド チーム リプレイ セットに保存されていることを忘れています。チャットボット バブルではなく可観測性スタックで発生した場合でも、リークはリークのままです。

これら 5 つの表面が見えるようになると、問題はそれほど神秘的ではなくなります。私たちは言語モデルを道徳的に純粋なものにしようとしているわけではありません。私たちは、単一の不注意な決定によってすべての扉が一度に開かれないようなシステムを設計しています。

素朴な防御策が失敗する理由

スライドでは安心感を与えても、実際のシステムではひどく失望する防御策がいくつかあります。

最初の弱い防御はスターン システム プロンプトです。モデルに機密情報を明かさないように言うことは、何も言わないよりは良いことです。自転車を紐でロックする方が、「やめてください」と書かれたメモを付けて路上に放置するよりも良いのと同じです。ただし、プロンプトは権限の境界ではありません。これはデータ最小化ポリシーではありません。遡って検索を絞り込むことはありません。モデルがコンテキスト内のシークレットを参照することを妨げるものではありません。これは単に、危険な状況がすでに作成された後にモデルが動作するように説得しようとしているだけです。

2 番目の弱い防御策は、ベンダーの楽観主義です。チームはプロバイダーにガードレールがあると想定しているため、問題は外部委託されています。これは心安らぐファンタジーです。ベンダー保護は便利ですが、テナント モデル、内部ドキュメントの分類、保持義務、隠された管理エンドポイント、またはモデルに多すぎるコンテキストをまだ注入している 3 四半期前の奇妙な小さなミドルウェア ショートカットについては知りません。管理された安全機能はリスクを軽減できますが、独自のアーキテクチャを置き換えることはできません。

3 番目の弱い防御策は、「従業員を信頼している」です。もちろん従業員を信頼しています。それは問題ではありません。人々はプレッシャーの下で迅速な決断を下します。シャドウ AI とオーバーシェアリングに関する Microsoft の議論は、厄介な真実を指摘しているので有益です。優秀な従業員でも、機密情報を間違ったモデルに入れたり、承認されたモデルを間違ったデータ ソースに接続したり、チャット記録が一時的ではないのに一時的なものであると思い込んだりする可能性があります。人々への信頼はシステムの境界に代わるものではありません。

4 番目の弱い防御策は、出力時にのみいくつかのフィルターをオンにすることです。出力フィルタリングは重要ですが、それは最後のネットであり、基礎ではありません。モデルが参照しすぎたり、取得しすぎたり、記憶しすぎたり、間違ったツールを呼び出したりする可能性がある場合、出力フィルタリングは、パイプが壊れたままの状態で床をモップで拭こうとすることになります。

ここでのパターンは単純です。弱い防御はモデルに行動を要求します。強力な防御は、そもそもモデルが表示、記憶、取得、または呼び出すことができるものを減らします。

モデルが好奇心旺盛で不注意であるかのようにパイプラインを構築する

最もクリーンなメンタル モデルは次のとおりです。モデルを、好奇心旺盛で、有能で、速いが、境界では完全には信頼できないものとして扱います。それはモデルに悪意があるという意味ではありません。これは、何を明らかにしても安全かについて広範な暗黙の判断を持ってモデルを信頼すべきではないことを意味します。

その観点から見ると、より安全な AI パイプラインはデータの分類から始まります。すべてのドキュメントが同じように検索可能である必要はありません。すべてのユーザーが同じソースをクエリできる必要はありません。すべてのクラスのデータを同じアシスタント モードで使用できる必要はありません。 AI レイヤーが、分類が曖昧で権限がずさんに継承されるデータ沼の上にある場合は、まだ AI の問題は発生していません。 AI メイクをすると、ストレージとアイデンティティの問題が発生します。

分類の後には取得ポリシーが続きます。 RAG システムは、単に「上位 K 個の関連チャンク」をフェッチすべきではありません。関連性があり、テナントが正しく、権限が正しく、鮮度が正しく、現在のタスクにとって安全な上位 K 個のチャンクをフェッチする必要があります。それは余分な仕事なので、余分な仕事のように聞こえます。しかし、ある顧客の内部命名規則が別の顧客のおそらくプライベートな回答に現れた理由をクライアントに説明するよりもコストはかかりません。

次にツールの認証が行われます。モデルには幅広の魔法のツールベルトを取り付けてはいけません。アクセス許可の範囲がタスク、ユーザー、テナント、および現在のワークフロー状態に限定されている狭いツール セットを受け取る必要があります。ツール呼び出しも観察可能である必要があります。モデルがレコードの検索、エクスポートの生成、システムへの書き込み、またはワークフローのトリガーができる場合、アクションの証跡は、元のデモを作成した人間以外でも検査できる必要があります。

記憶にも同じ規律が必要です。短期的な文脈は短くしてください。長期記憶を明示的に保ちます。保存されたメモリにラベル、有効期間、および削除パスを与えます。どのカテゴリの情報を決して保存しないかを決定します。サポート エクスポートにテキストの一部が含まれていることを不快に思う場合は、単に誰かが「パーソナライゼーションが向上する」と言ったからといって、それを永続的な記憶にしないでください。

最後に、出口に出口制御を置きます。機密性の高いパターンの検出、ポリシーのチェック、高リスクの出力クラスの構造化された許可リスト、および人間による選択的な承認は、モデルに対する不信の兆候ではありません。それらはシステムの成人期の兆候です。

実際に重要な RAG 境界

RAG は、AI 製品がおもちゃからビジネス システムに卒業する場所であることが多く、まさにそれが、通常よりも疑惑に値する理由です。

最初の境界はテナントの分離です。テナントを混在させ、後でソフト フィルタリングに依存する検索ストアでは、事故が待っています。データが本当に価値の高いものである場合、最も明確な答えは、多くの場合、取得を開始する前に物理的または論理的に分離することです。あまりエレガントではありませんが、それでも立派な答えは、ランキング結果がモデルに渡される前に適用される積極的なメタデータ フィルタリングです。最悪の答えは、広範囲に検索し、モデルが関連性を推測することを信頼し、間違った断片がつなぎ合わされないことを期待することです。

2 番目の境界は文書の信頼性です。すべてのインデックス付きドキュメントに同じ権限が与えられるわけではありません。信頼できる社内チームによって書かれたものもあります。一部は他のシステムからエクスポートされました。一部はユーザーが提供する場合があります。一部は古いかもしれません。中毒を起こしている人もいるかもしれません。検索システムにおけるデータ抽出攻撃に関する研究がここで重要になるのは、検索が単に事実を取得するだけではないことを思い出させるからです。悪意のある命令や隠れたトリガーをインポートする可能性があります。信頼レベルの概念を持たない検索レイヤーは、非常に高価なオートコンプリート エンジンにセキュリティ レビューアとして機能するよう要求します。

3 番目の境界はチャンクの衛生状態です。チームはチャンク サイズ、オーバーラップ、モデルの埋め込みについて話すのが大好きです。そもそもチャンクが存在すべきかどうかについて彼らが話すことはあまりありません。インデックス作成前に編集されるべきシークレットが含まれていますか?内部コメント、資格情報、またはデバッグ残余は含まれますか?抽象的な要約では不要な識別子は保持されますか? RAG パイプラインが最初にすべてを取り込み、後でセキュリティの質問をする場合、それは実際には安全な RAG パイプラインではありません。それは希望の持てるものです。

4 番目の境界は引用規律です。モデルは、理想的には、どのチャンクが答えに寄与したか、およびどのポリシーがそれらのチャンクをコンテキストに組み込むことを許可したかを知る必要があります。引用が美しいからではなく、説明可能性がインシデント対応に役立つからです。何か悪いことが起こったとき、「モデルはどこかで見たはずだ」という言葉は満足のいくものではありません。

エージェントが爆発範囲を拡大する

単純なチャット システムは漏洩する可能性があります。エージェントは漏洩して動作する可能性があります。

その違いが重要なのです。モデルが、どのツールをどの順序で、どのパラメーターを使用して、どの取得されたコンテキストに対して呼び出すかを決定できるようになると、攻撃対象領域はさらに広がり、それに伴って事故の対象領域もさらに広がります。問題はもはや「アシスタントが言ってはいけないことを言ってしまうか？」だけではありません。問題は、「アシスタントは、クエリすべきではないものをクエリし、それを保持すべきではないメモリと組み合わせて、その結果を、そのベースで実行することを意図していないワークフローに渡すことを決定するでしょうか?」になります。

そのため、エージェントのセキュリティをプロンプト エンジニアリングに単純化することはできません。エージェントのアイデンティティと認可に対する NIST の現在の関心は、官僚的なお飾りではありません。これは、ツールを使用する AI システムには、モデル自体の外部でも判読できる ID、権限範囲、承認ロジックが必要であるという認識です。

実際には、いくつかの時代遅れで厳格な習慣が大いに役立つことを意味します。読み取りツールと書き込みツールを分離します。リスクの低い検索とリスクの高いアクションを分離します。有効期間が短い認証情報を使用します。危険なアクションには明示的な承認パスが必要です。エージェントがツール呼び出しが必要だと判断した理由を記録します。また、王室のパスポートのように、同じ広範なアクセス トークンがワークフローのあらゆる段階に渡って存在することを許可しないでください。

小さな反例で要点を明確にします。社内の AI アシスタントがナレッジ ベースを検索し、問題のチケットを読み取り、顧客の応答を草案し、最終的にその応答を送信できるとします。弱い設計では、同じエージェントがすべてのステップをエンドツーエンドで実行できます。より強力な設計では、アシスタントが取得して下書きできるようになりますが、アウトバウンド メッセージを送信する前に、監査された別の承認ステップが必要になります。デモではどちらのシステムも同様に洗練されているように見えます。現実世界が存在することを期待しているかのように振る舞うのは 1 つだけです。

実際に実行できるリファレンス実装

最良のポリシーは、コードとの接触を維持するポリシーです。そこで、核となるアイデアを示す小さな Python ゲートウェイを構築してみましょう。受信テキストから明白な秘密を編集し、取得したチャンクをテナントと分類でフィルタリングし、ツール呼び出しをリクエストごとの許可リストに制限し、送信される応答を送信前にスキャンします。

これは完全なエンタープライズ セキュリティ製品ではなく、そのふりをするものでもありません。これは、正しい建築習慣を強制するコンパクトな骨格です。

__コード_0__

from __future__ import annotations

from dataclasses import dataclass
import fnmatch
import json
import re
from typing import Iterable


SECRET_PATTERNS = {
    "aws_access_key": re.compile(r"\bAKIA[0-9A-Z]{16}\b"),
    "jwt": re.compile(r"\beyJ[A-Za-z0-9_-]+\.[A-Za-z0-9._-]+\.[A-Za-z0-9._-]+\b"),
    "private_key": re.compile(r"-----BEGIN (RSA|EC|OPENSSH|DSA)? ?PRIVATE KEY-----"),
    "email": re.compile(r"\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}\b", re.I),
}


@dataclass(frozen=True)
class UserContext:
    user_id: str
    tenant_id: str
    role: str
    allowed_labels: tuple[str, ...]
    allowed_tools: tuple[str, ...]


@dataclass(frozen=True)
class Chunk:
    chunk_id: str
    tenant_id: str
    label: str
    text: str


def redact_text(text: str) -> str:
    result = text
    for label, pattern in SECRET_PATTERNS.items():
        result = pattern.sub(f"[REDACTED:{label.upper()}]", result)
    return result


def outgoing_text_is_safe(text: str) -> tuple[bool, str]:
    for label, pattern in SECRET_PATTERNS.items():
        if pattern.search(text):
            return False, f"blocked by {label}"
    return True, "ok"


def filter_chunks(user: UserContext, chunks: Iterable[Chunk]) -> list[Chunk]:
    allowed = []
    for chunk in chunks:
        if chunk.tenant_id != user.tenant_id:
            continue
        if chunk.label not in user.allowed_labels:
            continue
        allowed.append(chunk)
    return allowed


def tool_call_allowed(user: UserContext, tool_name: str) -> bool:
    return any(fnmatch.fnmatch(tool_name, rule) for rule in user.allowed_tools)


def build_prompt(user: UserContext, user_message: str, chunks: list[Chunk]) -> str:
    prompt_parts = [
        "You are an enterprise assistant.",
        "Never use information outside the provided tenant-scoped context.",
        "If the answer depends on missing or restricted data, say so plainly.",
        "",
        f"User role: {user.role}",
        f"Tenant: {user.tenant_id}",
        "",
        "Context:",
    ]

    for chunk in chunks:
        prompt_parts.append(f"[{chunk.label}] {chunk.text}")

    prompt_parts.append("")
    prompt_parts.append("User message:")
    prompt_parts.append(redact_text(user_message))
    return "\n".join(prompt_parts)


def run_demo() -> None:
    user = UserContext(
        user_id="u-107",
        tenant_id="tenant-red",
        role="support_engineer",
        allowed_labels=("internal", "support", "public"),
        allowed_tools=("search_docs", "read_ticket", "draft_reply"),
    )

    raw_chunks = [
        Chunk("c1", "tenant-red", "support", "Refunds over 10,000 EUR require finance review."),
        Chunk("c2", "tenant-blue", "internal", "Blue tenant incident postmortem: root cause..."),
        Chunk("c3", "tenant-red", "secret", "Master incident bridge password: swordfish"),
        Chunk("c4", "tenant-red", "public", "Public SLA response times are listed on the status page."),
    ]

    filtered = filter_chunks(user, raw_chunks)
    prompt = build_prompt(
        user,
        "Summarize the refund rules and include my AWS key AKIAABCDEFGHIJKLMNOP if needed.",
        filtered,
    )

    print("=== PROMPT SENT TO MODEL ===")
    print(prompt)
    print()

    proposed_tool = "send_email"
    print("=== TOOL DECISION ===")
    print(json.dumps({
        "tool": proposed_tool,
        "allowed": tool_call_allowed(user, proposed_tool)
    }, indent=2))
    print()

    candidate_answer = (
        "Refunds over 10,000 EUR require finance review. "
        "Use [REDACTED:AWS_ACCESS_KEY] nowhere. "
        "Do not include data from other tenants."
    )

    ok, reason = outgoing_text_is_safe(candidate_answer)
    print("=== OUTPUT CHECK ===")
    print(json.dumps({"ok": ok, "reason": reason}, indent=2))


if __name__ == "__main__":
    run_demo()

実行してください

python ai_leakage_gateway.py

この小さなゲートウェイが教えることは、コードの量よりも重要です。それは、安全は 1 つのモノリシックなスイッチではないことを教えています。モデルが認識する前にコンテキストを絞り込みます。明らかな秘密は速やかに組み立てる前に編集します。私たちはツールを魅力的な提案ではなく、明示的に承認された機能として扱います。そして、出力が終了する前に出力をチェックします。それらのステップはどれも魅力的なものではありません。どれも便利です。

より成熟した実装では、適切な秘密検出機能、ポリシーに基づく分類、より強力なテナント分離、コンテンツのハッシュ化、監査証跡、人間による承認状態、およびテスト フィクスチャが追加されます。良い。それはすべきです。重要な部分は、ソリューションの形状がすでに正直であるということです。

覚えておく価値のある反例

チームは創造性を低下させてそれを繰り返すため、いくつかの悪いパターンを壁に残しておくのに役立ちます。

悪いパターンの 1 つは、ユニバーサル副操縦士です。 「統一されたエクスペリエンスを求めている」ため、すべてにアクセスできます。実際には、これは多くの場合、アシスタントが 1 人の人間が 1 か所で見ることを許可されている以上のものを見ることができることを意味します。そのシステムが漏洩した場合、真の犯人はモデルではありません。原因は建築上の貪欲さです。

もう 1 つの悪いパターンは、共有ストレージからの生のエクスポートに静かにインデックスを作成する「セキュア RAG」デモです。このデモは、ベクトル ストアがテナント境界を取得時に強制するのか、それとも答えが草案された後にのみ強制するのかを誰かが尋ねるまでは素晴らしいものに見えます。答えがあいまいであれば、リスクもまったく曖昧ではありません。

もう 1 つは、誰も所有していないメモリ機能です。製品は継続性を向上させると考えています。セキュリティは、寿命が短いことを前提としています。法的には、保持が別の場所で定義されていると想定されます。サポートは、6 か月後、古いスニペットが依然として再表示される可能性があることを発見しました。このようにして、無害な機能がガバナンスの失敗となるのです。

次に、ロギングトラップがあります。エンジニアは、開発中に豊富なトレースを追加し、後でそれらをクリーンアップすると約束しながら、決して実行しないことがよくあります。その結果、製品の UI は立派なものになる一方で、可観測性スタックは機密性の高い資料の博物館となります。これは最も退屈な漏れ経路の 1 つであり、最も一般的なものの 1 つです。

優れたエンジニアリングは、こうした間違いとは正反対に見えることがよくあります。狭く見えますね。もっと明確に。魔法力は若干弱め。それは欠陥ではありません。それは、現実との接触を生き延びることを期待しているシステムの象徴です。

組織の管理は人々が認めたい以上に重要である

コードですべてを解決することにはロマンがあり、まったく不当なことではありません。しかし、AI 漏洩防止は規律の問題でもあります。

チームに承認済みのツール ポリシーが必要なのは、ポリシー ドキュメントがスリリングだからではなく、シャドウ AI が現実であるためです。プロンプトとアップロードのための基本的なデータ処理ルールが必要です。どの内部システムが AI 機能の提供を許可され、どの内部システムが許可されないかを決定する方法が必要です。リスクの高いユースケースのレビューパスが必要です。彼らはリテンションを所有する誰かを必要としています。モデルとツールの在庫を所有する人が必要です。そして、「このワークロードはまだ広範な AI アクセスに対応する準備ができていません」と言える謙虚さが必要です。

組織がすべての AI 機能を生産性への緊急ショートカットとして扱っている場合、世界で最も優れた技術的管理は依然として困難になります。 「未承認のツールは使用しないでください」とただ叫ぶだけではなく、企業が安全な代替手段を提供することでセキュリティが容易になります。 Microsoft のガイダンスはこれを正しく理解しています。人々は摩擦を避けて行動します。安全なパスが惨めで、安全でないパスが速い場合、安全でないパスは忠実な支持者を獲得します。

そうだ、ガードレールを建てよう。しかし同時に、エンジニアやナレッジワーカーが協力することで罰せられていると感じないよう、安全なワークフローを十分に活用できるようにします。

ハンズオン ラボ: デモを実際のポリシー ゲートウェイに変える

理論から自分のチームが触れられるものに移行したい場合、これは週末規模の演習として最適です。

上記の Python ゲートウェイから始めて、それに実際のポリシー ファイルを与えます。

__コード_0__

{
  "tenant_red": {
    "support_engineer": {
      "allowed_labels": ["public", "support", "internal"],
      "allowed_tools": ["search_docs", "read_ticket", "draft_reply"]
    },
    "finance_admin": {
      "allowed_labels": ["public", "support", "internal", "finance"],
      "allowed_tools": ["search_docs", "read_ticket", "draft_reply", "read_finance_record"]
    }
  }
}

次に、次のようにゲートウェイを拡張します。

1. ユーザーとロールはハードコーディングされるのではなく、ポリシーからロードされます。
2. テナントとラベルの両方が一致しない限り、取得チャンクは拒否されます。
3. ブロックされたすべてのツール呼び出しは理由とともにログに記録されます。
4. 秘密の形式の文字列を含む送信応答は返されずに隔離されます。
5. メモリは、許可リストに登録された会話タイプに対してのみ書き込まれます。

それを正直にやってみると、何か役に立つことに気づくでしょう。この問題はすぐに「迅速なエンジニアリング」のように感じられなくなり、問題が実際何であるか、つまりモデルを間に挟んだセキュリティとシステム統合の仕事のように感じられ始めます。

愛好家向けのテストタスク

単にうなずくだけではなく、記事をさらに進めて実際のことを学びたい場合は、次のことを試してください。

1. tenant_id 不一致テストを追加し、間違ったチャンクがプロンプトに到達しないことを証明します。
2. 出力フィルターを拡張して、顧客 ID、内部チケット参照、および支払いアーティファクトにフラグを立てます。
3. 書き込み可能なツールを実行する前に人間の承認を必要とする 2 番目のステージを追加します。
4. 短期記憶を 15 分間のみ保存し、自動有効期限切れおよび削除ログを追加します。
5. 2 つのレッドチーム プロンプトを作成します。1 つは直接、もう 1 つは取得したテキスト内に隠され、どのコントロールがどのエラーをキャッチするかを監視します。

結論

AI データ漏洩の防止は、システム プロンプトに配置する完璧な文を見つけることではありません。重要なのは、機密データを早期に分類し、取得範囲を適切に絞り、メモリを制限し、ツールを限定的に許可し、出力が建物から出る前にチェックされるシステムを構築することです。

これは、AI のマーケティング版ほど魅力的ではないように聞こえるかもしれません。良い。魅力は安全性において過大評価されています。ここで成功するチームは、通常、時代遅れなほど正確であることを厭わないチームです。彼らは、モデルが何を認識し、何を実行し、何を記憶し、何を人間がレビューする必要があるかを決定します。彼らはモデルに句読点を通して倫理を発展させるよう求めていません。

そして、それは静かな方法で励みになります。それは解決策が神秘的ではないことを意味するからです。それはエンジニアリングです。そうですね、ハードエンジニアリングをすることもあります。確かに、少々面倒なエンジニアリングです。しかし、それでもエンジニアリングです。つまり、推論、テスト、改善、出荷が可能です。

AI システムがすでに機密情報に触れている場合は、アシスタントを賞賛するのをやめて、その周囲の境界を検査し始めるのに最適な時期です。本当の物語は常にそこにあります。

参考文献

• NIST、人工知能リスク管理フレームワーク: 生成 AI プロファイル: https://doi.org/10.6028/NIST.AI.600-1
• NIST、AI エージェント標準イニシアティブ: https://www.nist.gov/caisi/ai-agent-standards-initiative
• NIST NCCoE、ソフトウェアおよび AI エージェントの ID と認可: https://www.nccoe.nist.gov/projects/software-and-ai-agent-identity-and-authorization
• OWASP、LLM アプリケーションのトップ 10: https://owasp.org/www-project-top-10-for-large- language-model-applications/
• AWS、GENSEC04-BP02: プロンプト インジェクションとジェイルブレイクの試みを防ぐための制御の実装: https://docs.aws.amazon.com/wellarchitected/latest/generative-ai-lens/gensec04-bp02.html
• AWS、生成 AI のセキュリティ状況のナビゲート: https://docs.aws.amazon.com/pdfs/whitepapers/latest/navigating-security-landscape-genai/navigating-security-landscape-genai.pdf
• Microsoft、AI を活用したエンタープライズを保護するためのガイド: AI アプリケーションの開始: https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/microsoft/final/en-us/microsoft-brand/documents/Securing-the-AI-Powered-Enterprise-Getting-Started-with-AI-Applications.pdf
• Yupei Lv 他、PLeak: 大規模言語モデル アプリケーションに対する即時漏洩攻撃: https://arxiv.org/abs/2405.06823
• Yuxin Wen 他、バックドアを介した検索拡張生成におけるデータ抽出攻撃: https://arxiv.org/abs/2411.01705