r/artificialが再確認した安全設計の教訓、system promptは秘密ではない

この thread は internal AI product で繰り返される失敗を示している

March 20, 2026 UTC、r/artificial には data access、user roles、response formatting、product behavior のかなりの部分を system prompt に埋め込んだ internal AI tool の話が投稿された。チームはその text が end user には実質的に見えないと考えていた。しかし投稿によれば、その前提はすぐ崩れた。組織内の誰かが creative phrasing で instructions を verbatim に近い形で引き出し、model は system prompt をそのまま開示してしまった。さらに prompt を公開するなという文を追加しても、長くは持たなかったという。

この thread で重要なのは驚きそのものではなく、community の反応だ。上位コメントは今回の件を、system prompt は security boundary ではないという古い警告の再確認として受け止めていた。commenter たちは、extraction attempt、prompt injection、debugging surface、logging mistake、あるいは model が自分の指示を守り切れない挙動を通じて、prompt text は結局見えてしまう前提で設計すべきだと述べた。つまり prompt は behavior を誘導できても、secrecy を保証する手段としては弱い。

community が引いた境界線

discussion で最も practical だった助言は、sensitive logic を prompt の外へ出して application backend に置くことだった。authorization rule、data access limit、pricing logic、internal workflow state のような business control は、model の自発的な compliance に依存しない通常の software layer に置くべきだ。複数の commenter は system prompt を tone、formatting、refusal style、task framing だけを担う薄い behavioral layer として扱うべきだとも述べている。その layer が漏れても damage が限定的でなければならないという考え方だ。

この thread のもう一つの実用的な point は、structured output が露出範囲を減らすという点である。free-form instruction following が少ないほど attack surface は小さくなる。schema、tool contract、allowlisted action、server-side validation は prompt extraction 自体を消すわけではないが、core system が hidden prose だけに guardrail を依存する状態を避けやすくする。internal copilot や enterprise assistant では product logic を 1 つの大きな prompt に押し込みたくなりがちなので、この distinction はかなり重要だ。

engineering 上の教訓

r/artificial が新しい exploit class を発見したわけではない。ただ、この thread は古い warning が実 deployment では今も無視されがちだと示した。internal assistant を出荷するチームは、system prompt がいずれ露出する前提で設計し、そのとき何の secret や control が実際に漏れるのかを先に問うべきだ。もし答えが多すぎるなら、その architecture は間違っている。prompt text は model を導けても、本当に守るべきものの保管場所としては弱い。

出典: r/artificial discussion.