OpenAI、AI agentをprompt injectionに強くする設計原則を公開
Original: Designing AI agents to resist prompt injection View original →
OpenAIは2026年3月11日のresearch postで、AI systemがbrowseやmessage reading、tool executionを伴うagentになると、prompt injectionは単なるprompt-engineering上の悩みではなく、第一級のsecurity problemになると強調した。OpenAIはこの攻撃を、email、web page、calendar inviteのようなuntrusted contentに埋め込まれた悪意あるinstructionだと定義する。agentがその内容を読み込むと、隠れたinstructionがdeveloperの意図した振る舞いを上書きし、望まないactionへ誘導し得る。
難しいのは、この問題が構造的だという点だ。Large language modelは、どこに書かれたinstructionでも従うよう訓練される。一方、agentic productはtrusted instructionとuntrusted user dataを同じworkflow内で扱わなければならない。その結果、dataとcontrolの境界が従来softwareよりはるかに壊れやすくなる。OpenAIは、こうしたattackを評価するbenchmarkを構築し、そこからより安全なagent設計のための実務的な指針を導いたと説明した。
OpenAIの設計ガイダンス
- long-term memoryにはtrusted contentだけを保持する。poisoned memoryは一度の攻撃を持続的なfailure modeへ変えてしまうからだ。
- 可能な限りdataとinstructionを分離し、任意のpage textをprivileged command inputとして扱わない。
- least privilegeを適用し、agentが初期状態で読めるもの、書けるもの、実行できるものを最小化する。
- 不審なmulti-step behaviorを止めたり検知したりするmonitoringとintervention layerを追加する。
- message送信、data transfer、account変更のような影響の大きいside effectの前には、明示的なuser confirmationを要求する。
OpenAIは、これらの考え方がすでにChatGPTのdefenseにも反映されており、model training、system instruction、runtime monitor、confirmation gateを組み合わせていると述べた。注目点は、prompt injectionをより賢いmodelが自然に無視してくれる問題として扱っていないことだ。むしろproduct architecture、permissions design、human-in-the-loop reviewが必要なsystems problemとして位置づけている。
より広いagent ecosystemにとっても、このガイダンスは基準を引き上げる。email assistant、coding agent、browser control、enterprise workflow toolを作るteamは、単にmodelの頑健性だけで安全性を語れなくなる。安全なdeploymentは、untrusted contentをどう隔離し、tool accessをどう絞り、人間のcheckpointをどこに入れるかで決まるということだ。
Related Articles
Codexは短時間の支援ツールから、ノートPCを閉じても進む企業向けエージェントへ軸足を移す。OpenAIは週次利用者が500万人超、年初比400%増とし、Onaの200万開発者向けクラウド環境を取り込む狙いを示した。
OpenAIは6月4日、ChatGPTのLockdown Modeを全ログインユーザーとワークスペースに提供し、API生成リクエストでは入力・出力のmoderationスコアを同じ応答で受け取れるようにした。prompt injection対策が製品機能として見える位置に出てきた。
HNで注目されたのは「Claudeがバグを見つける」話だけでなく、各チームが自分の対象に合わせて作り替えるharnessの形だった。