LLM セキュリティとボット攻撃: 実践的なテスト計画

どのような攻撃を止めようとしていますか?

LLM セキュリティは、モデル周辺のアプリケーションとその応答をカバーします。プロンプト インジェクションは、信頼できない入力を命令のように動作させようとします。ボットの悪用では、自動化を使用してワークフローを悪用しますが、場合によっては特別なプロンプトが表示されません。同じアプリケーションで両方が発生する可能性がありますが、疑わしい言語を検出するコントロールが、正当に見えるリクエストの繰り返しを必ずしも停止するとは限りません。

OWASP の自動脅威プロジェクトには、有効なアプリケーション機能の悪用が明示的に含まれています。その LLM リスク ガイダンスでは、過剰な推論がサービスの低下と経済的損失につながると説明しています。インシデントの優先順位付けを行う際には、これらの区別を使用します。問題がモデルの動作、アカウント アクセス、承認、またはリソース管理に属するかどうかを判断する前に、影響を受ける資産と結果を特定します。

証拠: OWASP による Web アプリケーションへの自動化された脅威 [1]LLM10:2025 無制限の消費 [2]

スキャナーを選択する前にテスト境界を書き込みます

Rubrex が提案する評価ワークフローについて、アプリケーションのバージョン、環境、エントリ ポイント、モデル構成、取得ソース、および有効なツールに名前を付けます。保護された各リソースの所有者を特定します。サポート ユーザーが別のテナントのチケットを確認したり、読み取り専用アシスタントがメッセージを送信したりするなど、絶対に発生してはいけない結果を 1 文で記述します。

合成アカウント、ドキュメント、およびツールの宛先を備えたテスト環境を使用します。リクエストの上限、支出の上限、実行ウィンドウ、および停止条件についてシステム所有者と合意します。設定されたクォータが低くても、トラフィックのフラッディングを発生させることなく強制を実行できます。通常の顧客タスクの小さなセットをコントロールとして保持し、後の試行をリセットできるように開始時のデータ状態を記録します。これはアプリケーションのテスト計画であり、無関係なサービスをスキャンする許可ではありません。

実際のツール権限に対してプロンプト挿入をテストします。

OWASP では、モデルベースのガードレールを、制約付きツール、検証、最小権限と並んで 1 つのレイヤーとして扱うことを推奨しています。その過剰なエージェンシー ガイダンスにより、アクションが許可されるかどうかの決定をモデルに委ねるのではなく、下流システムに承認が与えられます。強力な命令は便利なコンテキストですが、権限チェックの代わりにはなりません。

サポート テストの例では、ユーザーが概要のみを要求したにもかかわらず、合成で取得されたメモがアシスタントにチケットの所有者を変更するよう求めます。ライブ書き込みツールをインストルメント化されたテスト実装に置き換えます。モデルが書き込みを要求したかどうか、ツール境界で書き込みが許可されているかどうか、レコードが変更されたかどうかを記録します。モデルの拒否と拒否されたツールの要求は異なる観察です。両方を保存します。

次に、承認されたテスト アカウントを通じて正規のアップデートを送信します。提案された修正がすべての更新をブロックする場合、使用可能な保護を実証するのではなく、製品契約を変更したことになります。承認が必要なアクションの場合は、承認されたターゲットと引数が実行されるものであり、それらを変更するには新たな決定が必要であることを確認してください。

証拠: LLM 即時注入防止チートシート [3]LLM06:2025 過剰な主体性 [4]

モデルやツールのコストが発生する前にボットの悪用を制御する

OWASP の API リソース消費ガイダンスでは、ワークロードとサードパーティの支出に対する明示的な制限を求めています。 LLM アプリケーションの場合、取得、モデル呼び出し、ツール操作、再試行など、タスク全体のコストを評価します。 1 つの受け入れられたリクエストが無制限のダウンストリーム作業をトリガーする可能性がある場合、受信リクエストの数を制限するだけでは不十分です。

Rubrex は、許可制限と実行制限を個別に文書化することを推奨しています。入場時に、リクエストを認証済みアカウントまたはテナントに関連付け、その許容量を確認します。実行中、入力サイズ、出力バジェット、同時作業、ツール ステップ、および再試行が制限されます。期限を適用し、すでにキューに入れられている作業またはプロバイダーに送信された作業のキャンセルの意味を定義します。可能な場合はプロバイダーの支出管理を使用します。請求アラートだけでは消費は止まりません。

算術チェックの例として、テスト ポリシーでタスクごとに 3 つのモデル呼び出しと呼び出しごとに最大 2 回の再試行が許可されている場合、予算では最大 9 つのモデル呼び出しの試行を考慮する必要があります。これは、推奨される運用設定やコストの見積もりではありません。これは、リクエストごとのクォータとアプリケーションが実際にスケジュールできる作業との間の不一致を明らかにする方法です。取得と外部ツールの予算を個別に含めます。

証拠: API4:2023 無制限のリソース消費 [5]LLM10:2025 無制限の消費 [2]

実行例: クォータ競合、修正、再テスト

リンクされたモデルフリーの Node.js フィクスチャを 2026 年 10 月 3 日に実行しました。これは 2 つの同時リクエストと 1 つの合成ユニットの許可を使用します。脆弱なシナリオでは、バリアにより、どちらかのリクエストが継続する前に、両方のリクエストが同じ一時停止に達することが強制されます。アウトバウンドリクエスト、実際のユーザーレコード、有料モデルコール、ライブサイトターゲットはありません。プロバイダー呼び出しはメモリ内のスタブによってカウントされます。

脆弱なバージョンでは、各リクエストは残りの許容量を確認し、バリアを待ってからデクリメントします。どちらもチェックに合格します。2 つが許可され、2 つのスタブ呼び出しが発生し、残りの許容値は -1 になります。修正バージョンでは、リクエストは最初の待機の前にそのユニットを同期的に予約します。 1 つのリクエストのみが許可され、もう 1 つはスタブの前で拒否されます。残りの手当はゼロです。

スクリプトをダウンロードし、Node.js 22 でノード quote-race-demo.mjs を実行します。4 つのシナリオが出力されます。結果レコードには、観察された出力、実行時間、日付、および正確なスクリプトの SHA-256 ハッシュが含まれます。ゼロ予算コントロールは両方のリクエストを拒否します。十分な予算のコントロールでは両方が認められます。これらのコントロールは、修正が単にすべてのリクエストをブロックしているだけではないことをチェックします。

これは、1 つのスケジューリングの欠陥と 1 つの単一プロセスの修正を示しています。これは分散クォータ実装ではありません。同期 JavaScript はワーカーまたはレプリカ間でリクエストをシリアル化できません。実稼働アドミッションには、共有ストレージ内のアトミックな予約、再試行のための冪等性、および完了またはキャンセル時の明示的な調整が必要です。変動コスト モデルのリクエストには、控えめな予約と最終的な使用量の調整も必要です。これらの動作を個別に確認してください。このフィクスチャは、テナントの分離、プロンプト インジェクション、または Rubrex 運用インフラストラクチャをテストしません。

• 実行可能なクォータ レース フィクスチャ (Node.js) をダウンロードします。
• 記録された実行とスクリプトのハッシュ (JSON) をダウンロードします。

観察可能な合格条件を備えた小規模なテスト セット

以下のケースは、提案された開始ワークシートであり、Rubrex クライアントの結果や完全な適用範囲の主張ではありません。境界例を製品の書面による契約に置き換えます。各ケースを実行する前に予想される結果を記録し、後で証拠への参照を含めます。

クォータ テストの場合は、隔離された環境で意図的に小さい許容値を設定し、リクエスト量を低く抑えます。権限テストには、2 つの合成テナントと固有の非機密マーカーを使用します。再試行テストでは、偽のツールが動作を完了した後の確認応答の失敗をシミュレートします。これらのフィクスチャを使用すると、実際の停止、実際の顧客データ、または破壊的な副作用に依存せずに境界を検査できるようになります。

データへのアクセスをモデルの判断とは別にする

OWASP のオブジェクト レベルの承認ガイダンスでは、認証された呼び出し元がアクセスするレコードのチェックが必要です。この原則をアシスタントが使用するデータ ソースに適用します。有効なログインは、すべてのドキュメント、キャッシュされた回答、ツールの結果に対するアクセス許可を意味するものではありません。取得では呼び出し元の許可されたスコープを使用する必要があり、ダウンストリーム操作では保護されたオブジェクトにアクセスする場所でそのスコープを再度検証する必要があります。

2 つのテナントの例では、各テナントのテスト マテリアルに異なる無害なマーカーを配置します。アプリケーションでサポートされているドキュメントと会話のパスを実行し、返されたコンテンツと関連するアクセスの決定を検査します。他のテナントによってキャッシュが設定された後、この手順を繰り返します。どのパスがテストされたかを記録します。分離チェックが 1 回成功しただけでは、すべての取得パスまたは保存パスが分離されていることは証明されません。

証拠: API1:2023 オブジェクト レベルの認証が壊れています [6]

発見を誰かが検証できる修正に変える

有用な発見は、何が予想され、何が起こったのか、なぜそれが重要なのか、そしてどの証拠が結論を裏付けるのかを説明します。システムのバージョン、テスト ケース、アカウントの役割、構成、観察された状態、および実行識別子をまとめて保持します。モデルによって生成された疑いを、再現された境界欠陥から分離します。プロンプトの劇的な文言ではなく、到達可能なデータまたはアクションを使用して影響を説明します。

クォータ検出の例では、予想される結果はプロバイダー呼び出し前の拒否です。観察された障害は、アカウントの許容量が使い果たされた後に記録されたプロバイダー呼び出しである可能性があります。候補者修正により、入学前に手当が確保される可能性があります。再テストには、元のケース、最終許容量を中心とした制御された同時実行性、および十分な割り当てを備えた正当なリクエストが含まれている必要があります。結果が修正されたか、部分的に修正されたか、再現されなかったのか、またはテストされていなかったかを記録します。これらのラベルは交換できません。

保護と製品の使いやすさを同時に測定する

評価の読み出しについては、境界違反、拒否されたリクエスト、不完全なタスク、正当なケースに対する誤ったブロック、およびリソースの使用を報告します。各レートの背後にある症例の数と種類を述べます。ベースラインと候補の間の構成の違いを保持します。集計スコアにより、テストで防止する予定だった 1 つの不正行為が隠蔽される可能性があります。

進行中の操作については、誰がアラートを受信し、何を変更できるかを決定します。有効な対応としては、高価なツールを一時停止したり、テナントの許容量を削減したり、機密性の高いパスのレビューを一時的に要求したりすることが考えられます。調査記録はアクセス制御された状態に保ち、顧客との会話全体が一般的なアラート チャネルにコピーされることを避けます。インシデントが確認された後、サニタイズされた回帰ケースを追加し、モデル、プロンプト、取得、またはツールの変更後に関連する境界を再度確認します。

よくある質問