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 個のチャンクをフェッチする必要があります。それは余分な仕事なので、余分な仕事のように聞こえます。しかし、ある顧客の内部命名規則が別の顧客のおそらくプライベートな回答に現れた理由をクライアントに説明するよりもコストはかかりません。

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

記憶にも同じ規律が必要です。短期的な文脈は短くしてください。長期記憶を明示的に保ちます。保存されたメモリにラベル、有効期間、および削除パスを与えます。どのカテゴリの情報を決して保存しないかを決定します。サポート エクスポートにテキストの一部が表示されるのを望まない場合は、ポリシー、所有権、および削除パスが明示的である場合にのみ、永続メモリとして保存してください。

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

RAG 実際に重要な境界線

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ai_leakage_gateway.py

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 ゲートウェイから始めて、それに実際のポリシー ファイルを与えます。

policy.json

{
  "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エージェントのアイデンティティと認可: 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、Generative AI のセキュリティ状況をナビゲートする: https://docs.aws.amazon.com/pdfs/whitepapers/latest/navigating-security-landscape-genai/navigating-security-landscape-genai.pdf
• Microsoft、AI-Powered Enterprise のセキュリティ保護ガイド: 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

  システムにすでに圧力がかかっている場合はどのように見えるか

AI データ漏洩の防止は、チームが静かな四半期を望んでいたまさにその瞬間に緊急性が高まる傾向があります。機能がすでに顧客の前に提供されているか、プラットフォームがすでに内部依存性を持っており、システムはその洗練された理論と実行時の動作が丁寧に別々の生活を送っていることを明らかにするために、その特定の週を選択しました。これが、多くの本格的なエンジニアリング作業が和解から始まる理由です。チームは、システムが行うと信じていることと、負荷や変更が加えられた状態、そして誰もが少し創造的になり、賢さが少し低下するような期限の下でシステムが実際に行うことを調和させる必要があります。

エンタープライズ AI システムで最も重要なケースは、通常、マルチテナントの知識を備えた副操縦士、メモリを備えた内部アシスタント、およびエクスポートを備えたツールを使用するエージェントです。このような状況は、技術的、予算、信頼、ロードマップ、そして場合によっては評判にも影響を及ぼします。技術的な問題は、複数のチームがそれに依存した瞬間に政治的に大きくなり、なぜそれが未だに壁の中でアライグマのように行動するのか誰も完全に説明できません。夜はうるさく、場所を特定するのは難しく、無視すると費用がかかります。

そのため、動作圧力と配送の現実というレンズを通して問題を読むことをお勧めします。設計は理論的には美しくても、運用的には破滅的なものになる可能性があります。別の設計は、ほとんど退屈なものであっても、測定可能で修理可能であり、トレードオフについて誠実であるため、製品を何年も使い続けることができます。真剣なエンジニアは、2 番目のカテゴリーを好むようになります。これにより、壮大なスピーチが減りますが、誰もが受動態で話し、誰が近道を承認したかを誰も覚えていないような緊急の振り返りも減ります。

常に老化を続ける習慣

最初の永続的な方法は、1 つの代表的なパスを常に測定し続けることです。チームは多くの場合、曖昧なテレメトリを収集しすぎたり、意思決定品質のシグナルが少なすぎたりします。本当に重要な道を選び、それを繰り返し測定し、議論が装飾的なストーリーテリングに流れないようにしてください。 AI データ漏洩防止の回避策として有効な手段は、通常、取得範囲、メモリ保持ルール、ツールごとの承認、および出力スキャンです。それらが可視化されると、残りの決定はより人間的になり、神秘的ではなくなります。

2 番目の永続的な習慣は、証拠と約束を分離することです。エンジニアは、システムがその結論を得る前に、ある方向性が正しいと言うよう圧力をかけられることがよくあります。そのプレッシャーに抵抗してください。特にトピックが顧客やお金に近い場合は、最初に狭い証明を作成します。検証されていない大きな野心よりも、検証された小さな改善の方が商業的価値があります。これは、四半期末のレビューで仮説が期限に変わり、組織全体が楽観主義をスケジュール作成の成果物のように扱うようになるまでは、当然のことのように思えます。

3 番目の永続的な習慣は、所有者の言語で推奨事項を書くことです。 「パフォーマンスを向上させる」または「境界を強化する」という文章は、感情的には心地よいものですが、運用上は役に立ちません。月曜日の朝に実際に生き残るのは、誰が何を、どの順序で、どのロールバック条件で変更するかを述べた段落です。多くのテクニカル ライティングが失敗するのはここです。スケジュール可能であることよりも、先進的に聞こえることを望んでいます。

時間を節約する反例

最も一般的な反例の 1 つは次のようなものです。チームはローカルで大きな成功を収め、システムが理解されたと想定し、測定規律をアップグレードすることなく、アイデアをさらに要求の厳しい環境に拡張します。これは工学的に言えば、ホテルのプールで泳ぎ方を覚えてから、海の天気について自信を持って TED トークをするのと同じことです。水ではなくなるまでは水です。

もう 1 つの反例は、ツールのインフレです。新しいプロファイラー、新しいランタイム、新しいダッシュボード、新しいエージェント、新しい自動化レイヤー、古いラッパーとの調和を約束する新しいラッパー。これらはどれも本質的に悪いことではありません。問題は、誰も明確に名指ししていない境界線の補償を求められたときに何が起こるかということだ。その後、システムはさらに装備され、より印象的になり、場合によってはより理解できるようになります。購入者はこれをすぐに感じます。そのような表現がなくても、積み重ねが決断の代償として高価なものになったことを彼らは嗅ぎ分けることができます。

3 番目の反例は、人間によるレビューを自動化の失敗として扱うことです。実際のシステムでは、多くの場合、人間によるレビューが自動化を商業的に受け入れられる状態に保つための制御となります。成熟したチームは、どこを積極的に自動化するか、どこで承認や解釈を可視化するかを知っています。未熟なチームは、スライド内で「すべて」が効率的に聞こえるため、マシンにすべてを実行させたいと考えます。その後、最初の重大なインシデントが発生し、突然手動レビューが変換体験の誠実さによって再発見されます。

弊社が推奨する配信パターン

仕事が順調に進んでいる場合、最初の成果物は、チームに輪廻議論をやめるのに十分な技術的な読み取りを提供することでストレスを軽減するはずです。その後、次の制限付き実装で 1 つの重要なパスが改善され、再テストによってエンジニアリングとリーダーの両方が方向性を理解できるようになります。その順序は、正確なツールの選択よりも重要です。それは、技術スキルを前進に変えるものだからです。

実際的な観点から言えば、最初のサイクルは狭いことをお勧めします。つまり、アーティファクトを収集し、1 つの厳密な診断を作成し、1 つの限定された変更を出荷し、実際のパスを再テストし、次の決定を平易な言葉で書くというものです。分かりやすい言葉が重要です。買い手が明確さを後悔することはほとんどありません。購入者は、領収書が届く前に感動したことを後悔することがよくあります。

ここでもトーンが重要になります。強力な技術的な作業は、以前にプロダクションに対応したように聞こえるはずです。穏やかで、正確で、誇大宣伝に養われるというよりは、それを少し楽しんでいます。そのトーンは操作信号を伝えます。これは、チームがシステム エンジニアリングの古い真実を理解していることを示しています。マシンは高速であり、ロードマップは脆弱であり、詩的であり続けることを許可されていたすべての仮定に対して、遅かれ早かれ法案が到着します。

実際の技術レビューからのフィールドノート

AI のセキュリティとランタイム制御では、デモが実際の配信、実際のユーザー、実際の運用コストを満たしたときに、作業が本格化します。それは、きちんとしたアイデアがシステムのように動作し始める瞬間であり、システムは有名なドライなユーモアのセンスを持っています。彼らはキックオフデッキがどれほどエレガントに見えるかなど気にしません。彼らは、境界、障害モード、ロールアウト パス、そしてスタックに関する新しい神話をでっち上げずに次のステップを説明できる人がいるかどうかを重視しています。

AI Data Leakage Prevention: How to Stop Sensitive Data Escaping Through Prompts, RAG, Memory, and Agents の場合、実際的な問題は、ロードマップ、プラットフォーム、またはセキュリティ レビューにすでにプレッシャーを感じている購入者に対して、より強力な配信パスを作成できるかどうかです。その購入者は、霧の中に磨き上げられた講義を必要としません。彼らは使用できる技術的な読み取りを必要としています。

最初に検査するもの

まず、代表的なパスの 1 つから始めます。それは、テナントを意識した取得、ツール呼び出しエージェント、顧客対応の副操縦士、および承認が必要なワークフローです。その道は測定するには十分に狭く、真実を明らかにするには十分に広くなければなりません。最初のパスでは、拒否されたツール呼び出し、取得範囲、承認待ち時間、データ公開パス、監査の完全性をキャプチャする必要があります。これらの信号が利用できない場合、プロジェクトは依然として白衣を着た意見がほとんどであり、意見はそれ自体を戦略として宣伝してきた長い歴史があります。

最初の有用な成果物は、脅威モデルのメモ、ポリシー マトリックス、および悪用パスに対する小さな回帰ハーネスです。計画会議で誰もが期待したとおりに動作するのではなく、システムが動作するとおりに示す必要があります。トレース、リプレイ、小さなベンチマーク、ポリシー マトリックス、パーサー フィクスチャ、または反復可能なテストは、多くの場合、別の抽象的なアーキテクチャの議論よりも早くストーリーを伝えます。良い工芸品は驚くほど失礼だ。彼らは希望的観測を中断します。

時間を節約する反例

高くつく間違いは、最初の有用な証明よりも大きな解決策で応答することです。チームはリスクや遅延を認識すると、すぐに新しいプラットフォーム、書き換え、全面的なリファクタリング、またはヨガをしているような名前の調達しやすいダッシュボードに手を出します。場合によっては、そのスケールが正当化されることもあります。多くの場合、これは測定を延期する方法です。

より良い動きはより小さく、より鋭いです。境界に名前を付けます。証拠を捕らえます。重要なことを 1 つ変更します。同じパスを再テストします。次に、次の投資がより大きな投資に値するかどうかを決定します。このリズムは変革プログラムほど劇的ではありませんが、予算、リリース カレンダー、および制作上のインシデントに影響されても存続する傾向があります。

弊社が推奨する配送パターン

最も信頼性の高いパターンには 4 つのステップがあります。まず、代表的な成果物を収集します。次に、これらのアーティファクトを 1 つの難しい技術診断に変換します。 3 番目に、1 つの限定された変更またはプロトタイプを出荷します。 4 番目に、同じ測定フレームで再テストし、次の決定をわかりやすい言葉で文書化します。この種の作業では、ポリシー ゲート、敵対的プロンプト、取得フィクスチャ、およびトレース サンプルは、通常、一般的な方向性に関する別の会議よりも価値があります。

分かりやすい言葉が重要です。購入者は出力を読んで、何が変化したのか、何が依然としてリスクが残っているのか、何を待てばよいのか、次のステップで何を購入するのかを理解できる必要があります。推奨事項をスケジュールしたり、テストしたり、所有者に割り当てることができない場合でも、それは装飾的すぎます。装飾的なテクニカルライティングは楽しいものですが、制作システムがその心地よさをもたらすとは知られていません。

結果が役に立ったかどうかを判断する方法

AI Data Leakage Prevention: Prompt Injection, RAG Security, Memory Hygiene, and Agent Guardrails の場合、結果により配信速度、システムの信頼性、商用化の準備の 3 つのうち少なくとも 1 つが改善されるはずです。これらのどれも改善されない場合、チームは何かを学んだ可能性がありますが、購入者はまだ有用な結果を受け取っていません。その区別が重要です。学ぶことは崇高なことです。有料のエンゲージメントもシステムを動かすはずです。

最も強力な成果は、より狭いロードマップ、危険なパスの自動化の拒否、モデルの境界の改善、よりクリーンなネイティブ統合、書き換えがまだ必要ではないという慎重な証拠、またはリーダーが実際に資金を提供できる短い修復リストなどです。真剣なエンジニアリングとは、より良い意思決定の連続であり、ツールの仮装コンテストではありません。

SToFU はそれにどうアプローチするか

SToFU は、これを最初に配信の問題として扱い、次にテクノロジーの問題として扱います。私たちは関連するエンジニアリングの深さをもたらしますが、その取り組みは、経路、境界、リスク、測定、そして行う価値のある次の変更などの証拠に基づいて行われます。重要なのは、ハードワークを簡単に思わせないことです。重要なのは、次の重大な行動を実行できるほど明確にすることです。

それは、購入者が通常最も重視する部分です。彼らはどこでも意見を採用できます。彼らに必要なのは、システムを検査し、実際の制約に名前を付け、適切なスライスを構築または検証し、通話終了後の混乱を軽減する成果物を残すことができるチームです。騒がしい市場では、明確さはソフトスキルではありません。それはインフラです。