無料AIツールに隠されたリスク：ChatGPTやその他のLLMが安全でない理由

チャットボットがプライベートであるかのように装うのはやめよう

セキュリティチームはいまだに「ChatGPTを注意深く使う」ことについて、まるで開発者が公開チャットボットにプロプライエタリなコードを貼り付けることが主なリスクであるかのように話している。その枠組みは何年も前のものだ。本当の問題は構造的なものです。ChatGPT、Gemini、Claude、そしてオープンウェイトのアシスタントのような大規模言語モデル（LLM）は、決定論的なソフトウェアではありません。データから学習し、パターンを記憶し、バイナリのようにパッチを当てるのではなく、言語を通して操作できる確率的なシステムなのだ。このことだけでも、「LLMセキュリティ」は単なるAppSecのチェックリストではなく、独自のセキュリティ領域であることがわかる。(センチネルワン)

企業内には根強い嘘もある：「社内のブレーンストーミングのためだ。現実はそうではない。内部データ（監査メモ、法律草案、脅威モデル、収益予測）は、セキュリティの承認なしに、公開またはフリーミアムAIツールに毎日コピーされている。企業のAI利用に関する最近の調査では、従業員が機密コード、内部戦略文書、顧客データを、ChatGPT、Microsoft Copilot、Gemini、および同様のツールに、しばしば個人アカウントや管理されていないアカウントから積極的に貼り付けていることが判明した。企業データは HTTPS 経由で環境を離れ、会社が所有または管理していないインフラに流れ着きます。これは、仮想的なリスクではなく、現実のデータ流出です。(アクシオス)

別の言い方をすれば、エグゼクティブは「アシスタントに助けを求めている」と考えている。彼らが実際に行っているのは、機密情報を、監査できない不透明な計算とロギングのパイプラインに継続的に流すことだ。

LLMセキュリティー」とは何か

"LLMのセキュリティ "は、しばしば "悪いプロンプトをブロックし、モデルを脱獄させない "と誤解される。これはほんの一例に過ぎない。ベンダー、レッドチーム、クラウドセキュリティ研究者による最新のガイダンスは、より広範な定義に収束しつつある：LLMセキュリティとは、モデル、データ、実行サーフェス、モデルがトリガーすることを許可されたダウンストリームアクションのエンドツーエンドの保護である。(センチネルワン)

実際には、セキュリティの境界は多岐にわたる：

• トレーニングデータと微調整データ。 ポイズニングされたサンプルや悪意のあるサンプルは、攻撃者が細工した特定のプロンプトの下でのみトリガーされるバックドア動作を埋め込むことができます。(センチネルワン)
• モデルの重さ。 微調整されたモデルの窃盗、抽出、クローニングは、知的財産、競争上の優位性、そしてそのモデルのメモリに埋め込まれた規制対象となりうるデータを漏洩する。(センチネルワン)
• プロンプトのインターフェイス。 これには、ユーザープロンプト、システムプロンプト、メモリコンテキスト、検索されたドキュメント、ツールコールの足場が含まれる。攻撃者は、これらのレイヤーのいずれかに隠された命令を注入し、ポリシーを上書きしてデータ漏洩を強制することができる。(OWASP財団)
• 行動面。 LLMは、プラグイン、内部API、課金システム、DevOpsツール、CRM、財務システム、発券システムを呼び出すことが多くなっている。危ういモデルは、悪いテキストだけでなく、現実世界の変化を引き起こす可能性がある。(ハッカーニュース)
• インフラを提供する。 これには、ベクター・データベース、オーケストレーション・ランタイム、検索パイプライン、そして "自律エージェント "が含まれる。エージェント型システムは、プロンプトインジェクションやデータポイズニングのような基本的なLLMリスクを継承し、エージェントが行動できるため影響を増幅する。(イノヴィア)

Wizや他のクラウドセキュリティ研究者は、これを「フルスタック問題」と表現し始めた：AIインシデントは現在、古典的なクラウド侵害（データ窃盗、特権の昇格、金銭的不正使用）のように見えるが、LLMのスピードとLLMの表面積である。(クノーシス)

規制当局も追いついてきている。米国国立標準技術研究所（NIST）は現在、敵対的なMLの行動（プロンプトインジェクション、データポイズニング、モデル抽出、モデル流出）を、AIリスク管理における中核的なセキュリティ上の懸念事項として扱っている。(NIST出版物)
見てください： NIST AIリスク管理フレームワーク そして 敵対的機械学習分類法（NIST AI 100-2e2025）.

無料 "の不快な真実

無料LLMは慈善事業ではない。ユーザーを惹きつけ、価値の高いドメインのプロンプトを集め、製品を改善し、企業のアップセルに転換する。あなたのプロンプト、バグ探しの方法論、インシデント・レポートの草稿、それらすべてが、他の誰かのモデルの燃料となる。(サイバーニュース)

職場のAI利用に関する報告によると、アップロードされている機密資料のかなりの割合には、未発表のコード、社内のコンプライアンスに関する言葉、法的な交渉の言葉、ロードマップの内容が含まれている。場合によっては、アップロードは内部統制を避けるために個人のアカウントで行われ、データはあなたのものでなく、他人の保持ポリシーによって管理されることになる。(アクシオス)

これには3つの理由がある：

1. コンプライアンスの暴露。 医療データ（HIPAA）、財務予測（SOX法）、顧客の個人情報（GDPR/CCPA）など、規制対象のデータが法的境界外のインフラに漏れている可能性があります。それは監査で即座に発見できる。(アクシオス)
2. 企業スパイのリスク。 モデル抽出と逆変換攻撃はより良くなっている。攻撃者はLLMにクエリーを繰り返し、トレーニングメモリーや独自のロジックの断片を再構築することができる。これには、機密性の高いコードパターン、漏洩した認証情報、内部決定ルールなどが含まれる。(センチネルワン)
3. 監査可能な保存境界がない。 UI で "チャット履歴" をクリアしても、データが消えるわけではありません。多くのプロバイダーは、（不正使用監視、品質向上などのために）何らかの形でロギングと短期的な保持を開示しており、プラグイン/統合は、あなたが見ることができない独自のデータ処理を持っているかもしれません。(サイバーニュース)
   見てください： 無料AIツールに隠されたリスク そして LLMのセキュリティリスクに関するSentinelOne.

要するに、あなたの副社長が脅威モデルを「無料のAIアシスタント」に貼り付けると、契約もDPAもSLAもない、あなたの最も機密性の高い資料を処理するサードパーティを作り上げたことになる。

脅威モデル化すべきLLMセキュリティの10の失敗モード

大規模言語モデル・アプリケーションに関するOWASPトップ10と最近のAIインシデント報告は、同じ不快な現実に収束している：LLMのデプロイはすでに本番で攻撃を受けており、その攻撃は既知のクラスにきれいにマッピングされている。(OWASP財団)
見てください： OWASPのLLM申請トップ10.

この表は "未来の仕事 "ではない。すべての行は、SaaS、金融、防衛、セキュリティ・ツールの本番システムですでに観察されている。(センチネルワン)

シャドーAIはすでにインシデント対応業務であり、理論ではない

ほとんどの組織では、AIが社内でどのように活用されているのか、完全には把握できていない。従業員は、監査を要約したり、コンプライアンス・ポリシーを書き換えたり、顧客とのコミュニケーションの草案を作成したりするために、公開LLMに黙って依頼している。複数の文書化されたケースでは、機密性の高い社内セキュリティ文書が、管理されていない個人アカウントからChatGPTや同様のサービスに貼り付けられ、事後的なインシデント・レビューが引き起こされている。このようなレビューには数週間のフォレンジック時間が費やされましたが、それは情報漏えいが確認されたからではなく、法務チームとセキュリティチームが答えなければならなかったからです：「というのも、法務チームやセキュリティチームは、「契約していないベンダーに、規制対象のデータが漏れたのか？(アクシオス)

レガシーDLPで解決できない理由

• ChatGPTや同様のツールへのトラフィックは、通常の暗号化されたHTTPSのように見えます。
• SSL傍受による完全な迅速検査は、ほとんどの企業において法的にも政治的にも放射能汚染されている。
• ブラウザのローカル制御を強制したとしても、多くのAI機能は現在、他のSaaSツール（文書エディタ、CRMアシスタント、電子メール要約ツール）に組み込まれている。ユーザーがAIだと気づいていない「AI機能」によってデータが漏れているかもしれないのだ。(アクシオス)

この現象はしばしば "シャドーAI "と呼ばれる。この名称は誤解を招く。従業員は無謀なことをしているのではなく、ガバナンスよりも速く動いているだけなのだ。シャドーAIはシャドーSaaSのようなものだ。

セキュリティ・エンジニアのための最小限の防御策

以下のコントロールは、今日のセキュリティ・スタックで実現可能である。SFは必要ない。

プロンプトを信頼できない入力として扱う

• システムプロンプト」（モデルのポリシーと動作指示）をユーザー入力から分離する。信頼できない入力にシステムポリシーを上書きさせてはいけません。これは、プロンプトインジェクションと "すべての以前のルールを無視する "スタイルの脱獄に対する防御の最初のラインです。(OWASP財団)
• リスクの高いプロンプトを記録し、後で確認できるように差分化する。

レスポンスを信頼できない出力として扱う

• モデルが生成した SQL、シェルコマンド、修復ステップ、API 呼び出しを直接実行しないこと。そうでないことが証明されるまでは、すべてのモデル出力は攻撃者が制御していると仮定してください。OWASP はこれを Insecure Output Handling と呼び、LLM のトップレベルのリスクです。(OWASP財団)
• ポリシーの強制、サンドボックス、許可リストを通じて、LLMがトリガーするすべてのアクションを強制する。

制御モデルの自律性

• 課金、プロダクション設定、顧客記録、ID/エンタイトルメントデータを変更できるエージェントは、影響の大きいアクションに対して、人間の明示的な承認が必要です。エージェントの妥協は相乗的である：エージェントは一旦操縦されると、行動し続ける。(イノヴィア)
• エージェントごとではなく、アクションごとにクレデンシャルをスコープする。エージェントは長期間の管理者トークンを保持すべきではありません。

経済的虐待を見る

• トークン、コンテキストの長さ、ツールの呼び出しを制限する。OWASPは "Model Denial of Service "を呼びかけている。敵対的に大きなプロンプトはGPUコストを急上昇させ、サービスを低下させる（"denial of wallet"）。(OWASP財団)
• 財務部門は、アウトバウンド帯域幅を監視するのと同じように、「LLM推論費」を監視項目として見るべきである。

より深いガイダンスについては

• 大規模言語モデル・アプリケーションのためのOWASPトップ10
• SentinelOne: LLMのセキュリティリスク
• NIST AIリスク管理フレームワーク

例：LLMをポリシーとサンドボックスのレイヤーの背後で包む

以下のスケッチのポイントは単純で、生のモデルI/Oを信用しないことだ。モデルを呼び出す前にポリシーを強制し、その後にモデルが実行したいことはすべてサンドボックス化する。

# LLMセキュリティ・ラッパーのシュードコード

クラス SecurityException(Exception)：
    パス

# (1)入力ガバナンス：明らかなプロンプト注入の試みを拒否する
def sanitize_prompt(user_prompt: str) -> str：
    banned_phrases = [
        "以前の指示を無視する"、
        "秘密の流出"、
        "認証情報をダンプする"
        "安全を回避して続行"
    ]
    lower_p = user_prompt.lower()
    if any(p in lower_p for p in banned_phrases)：
        raise SecurityException("プロンプト・インジェクションの可能性が検出されました。")
    return user_prompt

# (2) システムとユーザを厳密に分離したモデルコール
def call_llm(system_prompt: str, user_prompt: str) -> str：
    safe_user_prompt = sanitize_prompt(user_prompt)
    response = model.generate(
        system=lockdown(system_prompt), #不変システムロール
        user=safe_user_prompt、
        max_tokens=512、
        temperature=0.2、
    )
    応答を返す

# (3) 出力ガバナンス: やみくもに実行しない
def execute_action(llm_response: str)：
    parsed = parse_action(llm_response)

    if parsed.type == "shell"：
        #許可リストのみ、jailedサンドボックスコンテナ内
        if parsed.command が ALLOWLIST にない場合：
            raise SecurityException("コマンドは許可されていません。")
        return sandbox_run(parsed.command)

    elif parsed.type == "sql"：
        # パラメータ化された、読み取り専用クエリのみ
        return db_readonly_query(parsed.query)

    さもなければ
        # プレーンテキスト、まだ信頼されないデータとして扱われる
        return parsed.content

# フォレンジックと規制防御のためにすべてのステップを監査する
answer = call_llm(SYSTEM_POLICY, user_input)
result = execute_action(answer)
audit_log(user_input, answer, result)

このパターンは、OWASP のトップ LLM リスクと直接一致している：プロンプト・インジェクション(LLM01)、安全でない出力処理(LLM02)、トレーニング・データ・ポイズニング(LLM03)、サービス拒否モデル(LLM04)、サプライチェーンの脆弱性(LLM05)、過剰なエージェンシー(LLM08)、過剰な依存(LLM09)です。(OWASP財団)

AIによる自動ペンテストがフィットする場所（Penligent）

この時点で、「LLMのセキュリティ」はガバナンス劇場のように聞こえなくなり、再び攻撃的なセキュリティのように見え始める。私たちのモデルは安全ですか？管理された方法で、公開されたAPIやインターネットに面した資産をテストするのとまったく同じ方法で、それを壊そうとするのだ。

これがニッチだ 寡黙 AI駆動システム（LLMアプリ、検索支援生成パイプライン、プラグイン、エージェントフレームワーク、ベクターDB統合）を魔法の箱としてではなく、攻撃対象として扱う自動化された説明可能な侵入テスト。

具体的には、Penligentのようなプラットフォームなら可能だ：

• あなたの内部アシスタントに対してプロンプトインジェクションと脱獄パターンを試み、どれが成功したかを記録する。
• 信頼されていないプロンプトが、内部の "エージェント "を騙して特権API（財務、配備、発券など）をヒットさせることができるかどうかを調査する。(イノヴィア)
• データ流出経路のプローブ：モデルは、PII、秘密、ソースコードを含む以前の会話やトレーニングデータからメモリをリークしていないか？(センチネルワン)
• ウォレットの拒否」をシミュレートする：攻撃者は、病的なプロンプトを与えるだけで、推論費用を急増させたり、GPUプールを飽和させることができますか？(OWASP財団)
• 成功した悪用事例を、具体的なビジネスインパクト（規制当局への暴露、不正の可能性、コストの増大）と、エンジニアとリーダーシップの双方が行動できる改善ガイダンスにマッピングした、エビデンスに裏打ちされたレポートを作成する。

というような基本的な質問に、ほとんどの組織はまだ答えられないからだ：

• "外部プロンプトによって、内部エージェントが特権課金APIを呼び出すことができますか？"
• "モデルは、顧客のPIIによく似たトレーニングデータの一部を漏らすことができるか？"
• "誰か、ファイナンスが来月しか気づかないような方法で、GPU料金を強制的に爆発させてくれないだろうか？"(OWASP財団)

従来のウェブペンテストでは、このようなフローをカバーすることはほとんどありません。自動化されたLLMを意識したペンテストは、「LLMセキュリティ」をポリシーのスライドから実際の検証可能な証拠に変える方法です。

セキュリティ・エンジニアの次のステップ

1. LLMのタッチポイントを棚卸しする。 あなたの組織でLLMがどこに住んでいるかを分類する：
   • パブリックSaaS（ChatGPT形式アカウント）
   • ベンダー主催の "エンタープライズLLM"
   • 自己ホストまたは微調整された内部モデル
   • インフラとCI/CDに組み込まれた自律エージェント
     これが新しいアタック・サーフェス・マップだ。(アクシオス)
2. パブリックLLMを外部のSaaSのように扱う。 「管理されていないAIツールに秘密はない」は、提案ではなく、ポリシーとして書かれなければならない。フリーのAIツールは、パブリック・フォーラムに投稿するのとまったく同じように扱うようにスタッフを訓練する。(サイバーニュース)
3. 人間の背後には、インパクトの強いゲートがある。 金銭の移動、設定の変更、記録の破棄が可能なAIエージェントは、影響の大きいステップに対して人間の明示的な承認を必要としなければならない。妥協を想定する。封じ込めのために構築する。(イノヴィア)
4. LLMを意識したペンテストをリリースの一部にする。 顧客や従業員に「AIアシスタント」を出荷する前に、敵対的なテストパスを実行してみてください：
   • プロンプトを注入する、
   • 秘密を引き出す、
   • プラグイン権限をエスカレートさせる、
   • スパイク代。
     外部APIのペンテストを扱うように、それを扱うのだ。

プレーブックにおすすめの参考文献

• 大規模言語モデル・アプリケーションのためのOWASPトップ10 - コミュニティがランク付けしたLLM特有のリスク（プロンプト・インジェクション、安全でない出力処理、トレーニング・データ・ポイズニング、サービス拒否、サプライチェーン、過剰なエージェンシー、過度の依存）。(OWASP財団)
• NIST AIリスク管理フレームワーク - は、敵対的なプロンプト、モデルの抽出、データポイズニング、モデルの流出を、単なる研究上の好奇心ではなく、セキュリティ上の義務として定式化している。(NIST出版物)
• SentinelOne: LLMのセキュリティリスク - プロンプトインジェクション、トレーニングデータポイズニング、エージェント侵害、モデル窃盗など、実際の攻撃者のテクニックを継続的にカタログ化。(センチネルワン)
• 無料AIツールに隠されたリスク - 企業における自由なAI利用のデータガバナンスと保持の現実。(サイバーニュース)
• 寡黙 - AI時代のインフラ向けに設計された自動侵入テスト：LLM、エージェント、プラグイン、コストサーフェス。

最後の収穫

LLMのセキュリティは、オプションの衛生管理ではありません。インシデント対応、コスト管理、IP保護、データ・ガバナンス、そして生産上の安全性、これらすべてを同時に実現するものです。脅威モデリングなしにChatGPTを "単なる無料の生産性向上ツール "として扱うことは、"どうせ社内だから "という理由でエンジニアにプレーンテキストの認証情報を電子メールで送信させるのと同じことだ。無料のAIは無料ではない。あなたはデータ、攻撃対象、そして最終的にはフォレンジックにかかる時間という代償を払うことになる。(サイバーニュース)

セキュリティの責任者であれば、もはや「AIはやっていない」と言うことはできない。あなたの組織はすでにAIを導入しているのだ。唯一の本当の選択肢は、それを安全に行なっていることを、雰囲気ではなく証拠で証明できるかどうかだ。