CISAのAIトークン指針、利用そのものが攻撃になり得ると警告
CISAと各国のサイバーセキュリティ機関は、AIの利用量がシステム停止に至る前からセキュリティ脅威になり得ると警告している。CISAのAIトークン指針は、組織の従量課金を意図的に増大させる不正行為であるdenial-of-wallet攻撃を扱う。その重要性は予期せぬ請求額にとどまらない。支出上限や容量枯渇は、AIに依存する業務を中断させる可能性もある。
ExecutiveGovの10月のサイバーセキュリティ報道では、この件を2026年10月23日付としている。中心にある緊張関係は単純だ。企業は複雑なタスクを最後まで処理できるAIシステムを求めるが、活動の継続は資源の消費も伴う。許可されていない、あるいは無駄なタスクを確実に続行するシステムは、別種の信頼性問題を生み出す。
この懸念は、すでにOWASPのセキュリティフレームワークとMicrosoftのエンタープライズ向けセキュリティ文書にも見られる。この指針は、その論点を調達と運用レジリエンスの議論へと持ち込むものだ。エンタープライズの購買担当者、開発者、セキュリティチームは今、共通の問いに直面している。AIワークフローが十分な作業を終えたと判断するのは誰か。そして、その支出を止められるのは誰か。
CISAのAIトークン指針、支出とサービス継続性を結び付ける
重要な変化は、AIの消費をセキュリティ監督に値する運用上の依存関係として扱う点にある。
Canadian Centre for Cyber Securityを通じて公開された共同文書の題名は、AI token consumptionである。トークンは、AIモデルが処理または生成する情報の単位だ。利用量の測定に役立つ一方、トークン数、計算処理、料金の関係はサービスによって異なる。
この文書は、金銭的損害とアクセス枯渇を区別している。Denial-of-wallet攻撃は従量課金コストを意図的に増やす。Denial-of-tokens攻撃は割り当てを消費するか上限を発動させ、正当なアクセスを妨げる。結果は重なり得るが、両者は同じものではない。
指針はまた、正当な需要や非効率なアプリケーションを含む、枯渇を招く通常の運用上の要因も特定している。組織には、プロバイダーとの契約を結ぶ前に、消費量とサービス条件を理解するよう促している。重要インフラの運営者にとっては、AI機能が劣化または利用不能になった場合の継続性も懸念事項となる。
この枠組みが重要なのは、財務上の保護策そのものが可用性の制約になり得るためだ。消費を止めれば予算は守れるが、無差別な停止は重要業務を中断させかねない。消費を続ければ一時的にアクセスは維持できるが、組織はさらなる支出にさらされる。
実務上の含意は、競合する目的の間にある衝突だ。財務部門は予測可能なリスク範囲を求める。運用部門は信頼できるアクセスを求める。プロダクトチームはタスクの完遂を求める。セキュリティ部門は不審な挙動の封じ込めを求める。AI導入には、こうした目的が衝突した際に解決する明示的な方法が必要となる。
日常的な質問と緊急の運用調査に使われる、仮想的な企業向け文書アシスタントを考えてみよう。両方の活動が同一の基盤モデルアカウントに依存している可能性がある。無駄なバックグラウンドタスクは、緊急調査に必要な資源を消費すれば重大な問題となる。
この例は、特定の組織が実際にそのようなインシデントに遭ったことを示すものではない。支出境界をどこに置くかが重要である理由を示している。アカウント全体に設定された上限は、個別ワークフローに設定された上限とは異なる結果をもたらす。
これは、成功したデモンストレーションの解釈も変える。デモは、特定の条件下でアシスタントが選定されたタスクを完了できることを示す。しかし、需要が変化した場合、依存関係が失敗した場合、あるいは許容された活動が過剰になった場合に、サービスがどう振る舞うかを示すものではない。
購買者にとって、これは機能に関する証拠と運用に関する証拠の間に隔たりを生む。前者はシステムが作業を実行できるかを問う。後者は不利な条件下でも組織が利用を継続できるかを問う。
CISAのAIトークン指針は、この二つ目の問いを購買プロセスの外に置きにくくしている。この問題は、サービスの可用性、復旧への期待、障害責任と並んで扱うべきものだ。
個々のワークロードを可視化できない購買者に圧力がかかる
集計されたAI請求額だけでは、個別のワークフローを稼働し続けるべきかどうかは分からない。
直接的な圧力は、アプリケーション、統合、共有サービスを通じてAI機能を購入する組織にかかる。課題は、消費量を事業目的に結び付けることだ。そのつながりがなければ、利用額の増加はインシデント時にほとんど役に立たない。
異常に高額なタスクが正当な場合もある。難しい分析、大量の文書群、矛盾する証拠を解決するための繰り返しの試行が関わるかもしれない。同じ支出パターンが、壊れた統合や意図的な不正利用を反映している可能性もある。
この曖昧さにより、単純な判断は信頼できないものになる。高い消費量は悪意を立証しない。低い消費量も安全な行動を立証しない。重要なのは、その活動が引き続き許可され、相応で、有用であるかどうかだ。
したがって調達チームには、監視に関する安心感を与える表現ではなく、統制境界に関する証拠が必要となる。ダッシュボードは問題を示せても、防止できるとは限らない。アラートは、介入する権限や技術的手段を持たない人に通知されることもある。
Microsoftのunbounded AI consumptionに関する文書は、負荷の大きいプロンプト、反復リクエスト、過剰なエージェント活動による資源枯渇を説明している。モデル呼び出しと下流サービスにまたがる統制として、クォータ、封じ込め、エージェント拡張の制限などを推奨している。Microsoftはまた、広く公表された悪意あるインシデントは依然として限定的であると指摘している。
この最後の留保は、購買者にとって重要だ。信頼できる脅威モデルは備えを支えるが、すべてのコスト増加を攻撃として扱うことを正当化するものではない。適切な購買判断には、実証された仕組みと測定されたインシデント発生率の区別が求められる。
Microsoftの立場は、OWASPのアプリケーションセキュリティフレームワークとの有用な比較も提供する。Microsoftはエンタープライズセキュリティの枠組みの中で統制を説明する。OWASPは、アプリケーション横断で根底にある消費上の弱点を分類する。これらの視点は問題を補強するが、特定のベンダーが解決したことを示すものではない。
商業的な意味合いとして、プロバイダーは統制の適用範囲をますます説明する必要がある。制限は顧客、部門、アプリケーション、個別ジョブのどれに適用されるのか。関連のない活動を維持しつつ、不審な作業を分離できるのか。
これらの問いは、購入組織内の説明責任にも影響する。財務チームが予算を管轄する一方で、エンジニアリングが統合を管轄することがある。セキュリティ部門は契約を管轄せずにアラートを受け取るかもしれない。引き継ぎが未解決のままでは、全員が情報を得ていても、ワークフローを停止する責任者がいない状況になり得る。
開発者にとって、消費量の可視化はアプリケーションの挙動を診断する一部となる。アカウントの支出が増えたことを知るだけでは、どのジョブが失敗したアクションを繰り返したかを知ることほど有用ではない。有益な証拠は、タスク、その進捗、消費した資源を結び付けるべきだ。
ナレッジワーカーにとって、影響は回答の遅延、調査の中断、アシスタントの利用不能として現れる。基盤となる資源割り当てを自ら制御することはほとんどない。彼らの体験は、中断が起きるはるか前に調達とエンジニアリングが下した判断に左右される。
これらの依存関係をレビューするチームは、承認済み契約、アーキテクチャ判断、インシデント手順を検索可能な技術ナレッジベースに保管できる。文書化は連携した対応を支援するが、アプリケーションによって強制される統制の代わりにはならない。
有用な自律性と制限された消費は異なる方向へ引っ張る
中核的なトレードオフは、システムに有用な作業を続けさせることと、無期限に続行させないことの間にある。
AIエージェントは、モデルを使ってタスク全体にわたる行動を選択するソフトウェアである。これにより、困難な作業を委任しやすくなる。一方で、最初の依頼が、その後に続くすべての行動を必ずしも説明しているわけではないことも意味する。
ユーザーは、エージェントが必要とする検索、文書、外部サービスを把握しないまま、調査を許可することがある。制限的な境界は有用な作業を早期に止めるリスクがある。開放的な境界は、組織が十分に規定していない結果を受け入れることになる。
OWASPのunbounded consumptionカテゴリは、制御されないモデル利用をサービス劣化と経済的損害の要因として特定している。例には過剰なリクエストや資源集約的なクエリが含まれる。フレームワークは、資源管理、タイムアウト、監視、グレースフルデグラデーションを含む多層的な保護を推奨している。グレースフルデグラデーションとは、有用なサービスを維持しながら機能を縮小することを意味する。
この視点に立てば、問題はプロンプトの長さを超える。短い指示でも複雑なワークフローを開始し得る。受信リクエストだけを数えても、アプリケーションが受け入れた後に行うすべての処理についてはほとんど分からない。
仮想的なリサーチアシスタントは、文書コレクションを検索し、矛盾する記述を調べ、さらに証拠を求めるかもしれない。各アクションは個別には合理的であり得る。事業上の問いは、その一連の行動がなお許可された調査を前進させているかどうかだ。
ここで、タスクの完了とタスクの継続は分岐する。基盤となるジョブが進捗を失っていても、継続的な活動はインターフェース上で生産的に見えることがある。ステータス更新の連続は、次のアクションにより多くの資源を与えるべきことを示すものではない。
同じ緊張関係はエラー回復にも現れる。失敗したアクションを再試行することで、一時的な問題が解決することもある。成功し得ないアクションを繰り返せば、失敗を長引かせるだけだ。アプリケーションには、モデルが再試行を望むこと以外の証拠を用いて、これらの状況を区別する方法が必要となる。
この区別は、組織が自律性を評価する方法にも反映されるべきだ。運用担当者が何が継続しているのか理解できなくなるなら、人の介入が少ないことが自動的に良いわけではない。日常的な承認が意味のない中断になるなら、介入が多いことも自動的に安全ではない。
有用な評価では、ワークフローの続行を許す証拠は何かを問う。新たな情報を得たか。依存関係は変化したか。意味のある中間成果を完了したか。これらは進捗に関する分析上の問いであり、現在の製品がどれも確実に答えられるという主張ではない。
責任はモデルプロバイダーだけにとどまらない。アプリケーションは、どの作業を要求するか、どのツールを公開するか、未完了タスクをどう扱うかを決定する。こうした判断は、基盤モデルが意図どおりに振る舞っている場合でも、リスクエクスポージャーに影響する。
このため、モデルを切り替えれば問題が解決すると考えることはできない。より資源集約度の低いモデルは、各アクションの費用を減らすかもしれない。しかし、アプリケーションが適切な回数のアクションを選ぶことまでは保証しない。
CISAのAIトークンに関するガイダンスは、委任された権限をめぐるより広い議論の一部と位置付けられる。AIシステムに目標の追求を認めるなら、コミットできるリソースに明確な境界を設ける必要がある。
難しい設計課題は、その境界内で有用な裁量を保つことだ。企業には複雑な業務に対応する十分な柔軟性と、境界に達した際に何が起こるのかを信頼できる形で説明する仕組みが求められる。
モデルを取り巻くソフトウェアが支出の境界を決める
モデルの判断と、アプリケーションが支出を許可することは別々の判断である。
2026年9月11日に公開されたAustralian Signals Directorateのagentic AI harnessesに関する勧告は、モデルを取り巻くソフトウェアに注目している。ハーネスとは、モデルをツール、データ、メモリ、実行制御と接続するソフトウェア層を指す。
この勧告は、組織がこの層を運用上およびセキュリティ上のリスクを生む独立した要因として評価すべきだと論じている。重点には、権限、監視、監督、そしてモデルが接続先システムとやり取りする方法が含まれる。これはトークンに関するガイダンスを補完する、有用なアーキテクチャ上の視点となる。
この区別が重要なのは、アシスタントが行動を推奨しても、それを実行する権限を持つとは限らないためだ。実際に行動が起きるかどうかは、モデルを取り巻くアプリケーションが決める。同じ分離は、追加的なリソース消費を認可する場合にも適用できる。
この観点から見ると、支出の境界は、モデルが単に説得して越えられるものではない、アプリケーション側の判断であるべきだ。モデルに節約するよう求めることと、強制可能な制限を課すことは異なる。前者は目標を示すだけであり、後者は許可される行動を変える。
9月に提出された研究は、より限定的な技術的懸念を加えている。persistent billable stateに関するプレプリントは、エージェントのやり取りをまたいで保持される外部ツールのコンテンツを調査している。著者らは、保持されたコンテンツが後続のリクエストで再び含まれる場合、繰り返し課金される入力になり得ると報告している。
この研究では、管理されたワークフローにおいて攻撃とホスト側の防御を検証している。調査結果は、広範な企業侵害の証拠ではなく、保持情報の取り扱いに関するものである。プレプリントである以上、導入リスクについて広範な結論を導く前に、慎重な検証と独立した再現が必要だ。
それでもこの研究は、情報を受け入れることと、それを処理するために繰り返し費用を支払うことの重要な違いを浮き彫りにしている。ツールの応答は、本来の目的を終えた後もワークフロー内に残り得る。そのため、保持に関する判断はアクセスに関する判断と並んで注目に値する。
例として文書調査を考えると、この問題は具体的になる。アシスタントが限定的な質問に答えるため、長大なレポートを取得する。アプリケーションが無関係な後続操作でもそのレポートを送り続けるなら、継続的な処理には独自の正当化が必要となる。
単純にすべてを削除することは、一般的な答えとして十分ではない。アシスタントは矛盾を解消したり結論を説明したりするため、以前の証拠を必要とする場合がある。アーキテクチャ上の問いは、どの情報を残す必要があるのか、そしてアプリケーションがその判断をどのように可視化するかだ。
ここでプロバイダー間の比較も、より意味を持つようになる。購入者は、タスク履歴、介入、再開時の挙動を比較できる。より長い利用可能なコンテキスト、すなわちモデルがリクエスト中に考慮できる情報量が大きいことだけでは、こうした運用上の問いに答えられない。
同様に、プロバイダーを変更することは、ガバナンスの必要性をなくすのではなく、新たな依存関係を生む。移行先サービスは情報を異なる方法で扱う可能性がある。可用性を維持するフォールバックであっても、正確性、権限、リソース露出の評価が必要だ。
中心となる示唆は、組織による統制である。企業は、どの判断がモデルに属し、どの判断がアプリケーションに属し、どの判断に人間の権限が必要かを理解すべきだ。これらの責任を曖昧にすると、過剰支出と不要な中断の双方を調査しにくくなる。
警告には信頼性があるが、攻撃の発生頻度は依然として不明確
もっともらしい攻撃経路があっても、攻撃者がそれをどれほど頻繁に悪用するか、どの程度の被害をもたらすかは示されない。
利用可能な情報源は、過剰な消費をセキュリティおよびレジリエンス上の懸念として扱うことを支持している。一方で、企業全体における悪意ある「denial-of-wallet」事案を包括的に測定したものではない。この不確実性は、警告を報じる際にも明示されるべきだ。
この区別が重要なのは、いくつかの異なる障害が似た症状を生むためだ。悪意あるリクエスト、ソフトウェアの不具合、予想外に困難な正当なタスクはいずれも消費を増加させ得る。支出の急増だけでは、どの説明が正しいかを判断できない。
すべての急増を攻撃と呼べば、インシデント報告を歪めることになる。すべての急増を通常の需要と呼べば、悪用を見えにくくする。組織には、どちらの解釈を選ぶ前にも調査できる十分なタスクレベルの証拠が必要だ。
保護コントロールに関する主張にも重要な限界がある。設定済みの閾値は、設定が存在することを示すにすぎない。強制がどれほど迅速に行われるか、どの活動を対象とするか、依存する作業が別の場所で継続するかまでは示さない。
アラートが示す主張はさらに限定的だ。指定された条件下で、システムが誰かに通知できることを示すだけである。購入者は依然として、通知の遅延、エスカレーションの責任、通知後に取れる措置を理解する必要がある。
同様に、封じ込めの実証に成功しても、その結果はテストされた条件の範囲で解釈すべきだ。人工的なワークロードを停止できたことは、そのテストについて有用な事実を示す。しかし、すべてのワークフロー、統合、悪用パターンへの保護を自動的に証明するものではない。
最も重要な懐疑的な問いは、事業上の影響に関するものだ。過剰な消費を止めるコントロールでも、正当な業務を中断させる可能性がある。したがって保護を評価するには、防止された露出と、その保護が妨げる作業の両方を検討する必要がある。
このトレードオフは、組織が完了率でアシスタントを評価する場合に特に重要になる。積極的な停止は、正常な完了を減らす可能性がある。寛容な継続は、露出を増やしながら見かけ上の完了率を改善し得る。有意義な比較には、両方の結果を視野に入れる必要がある。
もう一つの不確実性は、契約上の責任がどこから始まり、どこで終わるかにある。プロバイダーが監視機能を提供する一方で、顧客が強制措置を設定する場合がある。アプリケーションベンダーが、別の企業のモデルサービスに依存している場合もある。購入者は、機能名だけから責任を推測するべきではない。
ガイダンス自体についても、正確に説明すべきだ。サイバーセキュリティに関する公開文書が、直ちに新たな法的義務となるわけではない。義務的な要件に関する主張には、別途適用可能な根拠が必要となる。ここでの情報源が示すのは、普遍的なコンプライアンス期限ではなく、ガイダンスと技術的懸念である。
プロダクトチームにとって、妥当な対応は釣り合いの取れた検証だ。現実的な制限の下でも、代表的なタスクが有用であり続けるかを調べられる。また、不審または壊れたタスクが、無関係な作業を無効化せずに停止するかもテストできる。
読者にとっても、報道の基準は同じく規律あるものであるべきだ。推奨されるコントロール、独立してテストされた挙動、確認済みのインシデントを明確に区別することが求められる。これらの分類は異なる問いに答えるものであり、互換可能なものとして扱えば購買判断の信頼性が下がる。
CISAのAIトークンに関するガイダンスは、誇張した主張を必要とせずとも重要である。これは組織が今すぐ検討できる依存関係を示す一方、実世界での悪用の頻度と深刻度については、さらなる証拠に委ねている。
強制措置、ワークロード分離、独立テストに注目する
次に必要な証拠は、正当なサービスを維持しながら、組織が過剰な作業を封じ込められるかを示すものだ。
今後数カ月で最も有用な兆候は、より安全なAIに関する一般的な約束ではなく、運用上の挙動に関するものとなる。この公開文書は、より具体的な問いを投げかける明確な根拠を作る。ただし、プロバイダーや購入者がすでにその問いに答えていることを証明するものではない。
最初の兆候は、強制措置の挙動に関する、より明確な文書化だ。ベンダーが通知と制限を区別し、各制限が正確にどこに適用されるかを説明しているかに注目したい。これは、消費のガバナンスが利用可能な製品機能になりつつあるという見方を強めるだろう。
反対の兆候が見られれば、この評価は弱まる。文書が介入について説明せず、予算だけを記述し続けるなら、購入者は依然として露出を見積もるのに苦労する。機能は、有効化後に何が引き続き許可されるかを含め、その運用上の効果で評価すべきだ。
二つ目の兆候は、購買要件や受け入れテストにおけるワークロード分離の証拠である。ワークロード分離とは、他のジョブを不必要に中断させずに問題のあるジョブを制限することを意味する。重要な活動が継続する一方、優先度の低い活動や不審な活動が停止することを示す証拠が重要となる。
これは、消費コントロールと継続性を結び付けるガイダンスを裏付けることになる。アカウント全体の停止が、状況によっては依然として適切な場合もある。しかし、その挙動を選択的な封じ込めと同等のものとして示せば、重大な違いを隠すことになる。
三つ目の兆候は、封じ込めと有用なタスク完了を組み合わせた独立テストだ。ワークロードの前提を公開し、中断されたタスクがなぜ停止したのかを説明する評価に注目したい。強い結果は、許可された作業が信頼できる形で完了することと、露出が限定されることの両方を示すだろう。
消費量の削減だけを測定する結果には、重要な空白が残る。アシスタントが十分な数の作業を拒否すれば、支出を減らすのは容易だ。難しいテストは、制限がシステム購入の目的であるビジネス上の価値を維持できるかどうかである。
これらの兆候は、競合する提供内容を比較する実践的な方法にもなる。購入者は、文書化された強制措置、分離の挙動、独立評価された結果を確認できる。これにより、モデル能力に関する主張だけに頼るよりも有用な評価が得られる。
開発者にとっての当面の示唆は、運用上の挙動をレビュー可能にすることだ。タスクには識別可能な目的、説明責任を負う所有者、理解可能な停止条件が必要である。こうした性質により、障害は診断しやすくなり、購買上の主張もテストしやすくなる。
企業のリーダーは、AIサービスを担当するチームに対し、代表的なジョブを認可から完了または中断まで追跡するよう求めるべきだ。そのリソース境界を誰が管理するか、誰が介入できるか、その後もどの無関係な作業が利用可能であるかを特定する。ダッシュボードを答えとして受け入れるのではなく、実際のテストから得られた証拠を求める。CISAのAIトークンに関するガイダンスを用いて、そのレビューを支出だけでなく事業継続性の観点からも構成する。その後、観察された挙動をサービス契約および社内の責任分担と比較する。それらの説明が食い違う場合は、導入を拡大する前にその不一致を解消する。業務を委任するという決定には、それを誰が停止できるのかという問いへの明確な答えが伴うべきだ。
