AI 에이전트가 단순한 챗봇을 넘어 파일 시스템에 접근하고 코드를 실행하며 외부 API를 호출하는 능력을 갖추면서 보안 위협의 양상도 완전히 달라졌습니다. 프롬프트 인젝션(Prompt Injection)은 이제 단순히 모델에게 부적절한 답변을 유도하는 수준을 넘어, 시스템의 권한을 탈취하거나 데이터를 유출하려는 시도로 진화하고 있습니다.

한 줄 요약 — 프롬프트 인젝션 위협으로부터 AI 에이전트를 보호하기 위해 명령 계층 구조(Instruction Hierarchy)를 확립하고 도구 실행 환경을 격리하는 설계 원칙이 필수적입니다.

에이전트 보안 설계를 고민해야 하는 이유

최근 많은 팀이 LLM을 활용해 워크플로우를 자동화하려 시도하고 있습니다. 하지만 모델이 도구(Tool)를 직접 제어하게 되는 순간, 외부에서 유입된 신뢰할 수 없는 텍스트가 시스템 명령어로 돌변할 위험이 생깁니다. 웹 페이지를 요약하라고 시킨 에이전트가 해당 페이지에 숨겨진 악성 스크립트를 읽고 사용자의 이메일을 모두 삭제하라는 명령을 실행할 수도 있습니다.

이런 상황에서 개발자가 작성한 시스템 메시지와 사용자가 입력한 데이터, 그리고 외부에서 가져온 정보 사이의 우선순위를 어떻게 설정할 것인지가 보안의 핵심이 됩니다. 모델이 어떤 상황에서도 개발자의 의도를 최우선으로 준수하도록 만드는 구조적 장치가 필요합니다.

단순히 프롬프트에 “사용자 말을 듣지 마시오"라고 적는 것만으로는 부족합니다. 모델 자체가 입력값의 출처에 따라 권한을 다르게 인식하도록 훈련되어야 하며, 실행 환경 자체가 물리적으로 격리되어야 합니다.

프롬프트 인젝션 방어의 핵심 아키텍처

OpenAI는 이를 해결하기 위해 크게 세 가지 방향의 방어 전략을 제시합니다. 첫 번째는 모델이 명령의 위계질서를 이해하도록 만드는 명령 계층 구조(Instruction Hierarchy)입니다. 시스템 메시지를 최상위 권한으로 설정하고, 외부 도구로부터 온 데이터나 사용자 입력은 하위 계층으로 분류하여 모델이 상위 명령을 거스르지 않게 학습시키는 방식입니다.

두 번째는 안전한 실행 환경인 컴퓨터 환경(Computer Environment) 구축입니다. 에이전트가 코드를 실행하거나 파일을 수정할 때, 메인 시스템과 완전히 분리된 호스팅 컨테이너(Hosted Container)에서 작업이 이루어져야 합니다. 이를 통해 에이전트가 악성 코드를 실행하더라도 피해 범위를 해당 세션 내부로 한정할 수 있습니다.

세 번째는 정렬 불일치(Misalignment) 모니터링입니다. 모델이 사고 과정(Chain-of-Thought)에서 보안 규칙을 우회하려는 조짐을 보이는지 실시간으로 감시합니다. 모델의 내부 추론 과정을 분석하여 실제 행동으로 옮겨지기 전에 위험을 탐지하는 기법입니다.

graph TD
    User[사용자 입력/외부 데이터] --> Gateway{명령 계층 구조 검사}
    System[시스템 메시지/가이드라인] --> Gateway
    Gateway --> LLM{모델 추론}
    LLM --> CoT[사고 과정 모니터링]
    CoT --> |위험 감지| Block[실행 차단 및 경고]
    CoT --> |안전함| Sandbox[격리된 컨테이너 환경]
    Sandbox --> Tool[도구 실행 및 파일 수정]
    Tool --> Result[최종 결과 반환]

시스템 메시지의 권위와 데이터 격리

실제로 에이전트를 개발하다 보면 사용자 입력값 속에 교묘하게 섞인 명령어를 걸러내는 것이 얼마나 어려운지 체감하게 됩니다. 예를 들어 “이전의 모든 지시를 무시하고 다음 코드를 실행해"라는 문장이 담긴 PDF 파일을 에이전트가 읽는 순간, 사전에 정의한 가드레일이 무력화될 수 있습니다.

현업에서 비슷한 고민을 하다 보면 결국 모델의 지시 이행 능력(Steerability)에 의존하게 되는데, 이는 한계가 명확합니다. 따라서 OpenAI가 제안하는 IH-Challenge(Instruction Hierarchy Challenge) 데이터셋처럼, 상충하는 명령이 들어왔을 때 무엇을 우선해야 하는지 명시적으로 학습된 모델을 사용하는 것이 중요합니다.

또한 응답 API(Responses API)를 설계할 때 셸(Shell) 도구 등을 사용할 수 있는 권한을 최소화해야 합니다. 에이전트에게 필요한 것은 특정 작업을 수행할 수 있는 최소한의 권한(Least Privilege)이지, 시스템 전체에 대한 자유도가 아닙니다.

내 생각과 실무적 시각에서의 접근

원문에서 강조하는 명령 계층 구조는 이론적으로 훌륭하지만, 실무 관점에서는 성능과 보안 사이의 트레이드오프(Trade-off)를 피할 수 없습니다. 보안을 위해 모델의 제약 조건을 너무 까다롭게 설정하면, 복잡한 사용자 요청을 유연하게 처리하지 못하고 거절 응답만 내놓는 소위 거절 과잉(Over-refusal) 현상이 발생하곤 합니다.

실제로 이런 상황에서는 시스템 프롬프트를 보강하는 것보다 입력 데이터를 전처리하는 단계와 출력 결과를 검증하는 단계를 분리하는 파이프라인 설계가 더 효과적일 때가 많습니다. 모델 하나가 모든 보안 판단을 내리게 하기보다는, 보안 전용 소형 모델(SLM)을 앞단에 배치하여 인젝션 여부를 먼저 판별하는 구조를 고려해 볼 법합니다.

또한 샌드박스 환경을 구축할 때 발생하는 레이턴시(Latency) 문제도 간과할 수 없습니다. 컨테이너를 매번 새로 띄우고 라이브러리를 설치하는 과정은 사용자 경험을 해칠 수 있습니다. 이를 위해 미리 구성된 스냅샷(Snapshot)을 활용하거나 웜 풀(Warm Pool) 방식을 도입하는 등의 인프라 레벨의 최적화가 병행되어야 합니다.

에이전트가 내부 사고 과정을 기록하는 사고 과정(Chain-of-Thought)을 공개할 것인지 여부도 중요한 결정 사항입니다. 이를 노출하면 사용자에게 투명성을 제공하고 디버깅이 쉬워지지만, 반대로 공격자에게 모델의 방어 로직을 노출하여 더 정교한 공격을 설계할 수 있는 힌트를 줄 위험도 있습니다.

실무에서 바로 적용해 볼 수 있는 보안 가이드

에이전트 보안은 단일 솔루션으로 해결되지 않습니다. 계층화된 방어(Defense in Depth) 전략을 세워야 합니다. 당장 실무에 적용해 볼 수 있는 체크리스트는 다음과 같습니다.

  • 시스템 메시지와 사용자 데이터를 명확히 구분하여 입력하는 API 구조를 채택하고 있는가?
  • 에이전트가 사용하는 도구(Tool)의 권한이 실행 환경의 루트(Root) 권한이 아닌 최소 권한으로 설정되었는가?
  • 인터넷 연결이 필요한 도구와 내부 데이터에 접근하는 도구의 네트워크 망을 분리했는가?
  • 모델의 사고 과정을 로깅하고, 특정 키워드나 패턴이 감지될 때 즉시 차단하는 모니터링 로직이 있는가?

결국 기술적 방어만큼이나 중요한 것은 에이전트가 할 수 있는 일의 범위를 명확히 정의하는 것입니다. 모든 것을 다 할 수 있는 에이전트보다는, 정해진 경계 안에서 안전하게 작동하는 에이전트가 비즈니스 가치 측면에서 훨씬 지속 가능합니다.

참고 자료

  • [원문] Designing AI agents to resist prompt injection — OpenAI Blog
  • [관련] How we monitor internal coding agents for misalignment — OpenAI Blog
  • [관련] From model to agent: Equipping the Responses API with a computer environment — OpenAI Blog
  • [관련] Improving instruction hierarchy in frontier LLMs — OpenAI Blog