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에서 가장 실무적인 조언은 sensitive logic을 prompt 밖으로 옮겨 application backend에 두라는 것이었다. authorization rule, data access limit, pricing logic, internal workflow state 같은 business control은 model의 자발적 순응에 기대지 않는 일반 software layer에 있어야 한다. 몇몇 commenter는 system prompt를 tone, formatting, refusal style, task framing 정도의 얇은 behavioral layer로 취급하자고도 말했다. 그 정도가 새더라도 피해를 제한할 수 있어야 한다는 뜻이다.

thread가 던진 또 하나의 포인트는 structured output이 노출 범위를 줄인다는 점이다. free-form instruction following이 적을수록 attack surface도 작아진다. schema, tool contract, allowlisted action, server-side validation은 prompt extraction을 완전히 막지는 못하지만, 핵심 시스템이 숨겨진 prose 하나에 guardrail을 의존하는 상황은 피하게 해 준다. internal copilot과 enterprise assistant에서 product logic을 큰 prompt 하나에 몰아넣고 싶어지는 유혹이 강한 만큼, 이 구분은 더 중요하다.

엔지니어링 관점의 교훈

r/artificial이 여기서 새로운 exploit class를 발견한 것은 아니다. 다만 오래된 경고가 실제 deployment에서는 여전히 무시된다는 점을 thread가 다시 보여 줬다. internal assistant를 배포하는 팀이라면 system prompt가 언젠가 노출될 수 있다고 가정하고, 그 순간 실제로 어떤 secret과 control이 새는지를 먼저 물어야 한다. 그 답이 너무 많다면 architecture가 잘못된 것이다. prompt text는 model을 안내할 수는 있어도, 정말 보호해야 하는 것을 숨겨 둘 장소로는 약하다.

출처: r/artificial discussion.