OpenAI、AI agentをprompt injectionに強くする設計原則を公開

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をどこに入れるかで決まるということだ。