프롬프트 인젝션 방어 체크리스트: 차단보다 피해 범위를 줄이는 설계

OWASP, NIST, Microsoft, OpenAI 공식 지침을 바탕으로 직접·간접 프롬프트 인젝션의 공격 흐름과 신뢰 경계, 출력 검증, 최소 권한, 승인 절차를 점검합니다.

8분 읽기
외부 문서의 숨은 명령을 여러 보안 계층이 차단하고 권한을 제한하는 구조 이미지
AI Spot 편집팀이 주제 구조를 설명하기 위해 제작한 이미지입니다.

핵심 요약

  • 프롬프트 인젝션은 사용자 입력뿐 아니라 웹페이지, 문서, 이메일, 이미지와 도구 응답에서도 시작될 수 있다
  • RAG나 시스템 프롬프트 하나에 기대지 말고 외부 콘텐츠 격리, 결정론적 검증, 최소 권한과 실행 전 승인을 겹쳐야 한다
  • 현재 방어는 우회 가능성을 전제로 피해 범위와 복구 시간을 줄이는 설계가 필요하다

이메일을 요약해 달라고 했을 뿐인데 AI 에이전트가 다른 주소로 메일을 보내려 한다면, 문제는 답변의 품질에서 끝나지 않습니다. 메일 본문에 숨겨진 지시를 모델이 사용자 명령처럼 받아들이고 전송 도구까지 호출한 상황일 수 있거든요.

프롬프트 인젝션은 채팅창에 노골적인 공격 문구를 넣을 때만 발생하지 않습니다. OWASP는 사용자가 직접 넣는 명령을 직접 인젝션으로, 웹페이지·파일 같은 외부 소스의 명령이 모델 행동을 바꾸는 경우를 간접 인젝션으로 구분합니다. 공격 문자열은 사람에게 보이지 않아도 모델이 해석할 수 있으면 영향을 줄 수 있습니다. OWASP LLM01:2025 Prompt Injection

목표를 “공격 문구를 전부 찾아내기”로 잡으면 운영이 막힙니다. 현재 지침들이 공통으로 제안하는 방향은 일부 공격이 탐지를 통과할 가능성을 인정하고, 그 뒤에 할 수 있는 행동과 접근할 데이터를 줄이는 쪽에 가깝습니다.

공격은 입력에서 도구 실행으로 번진다

간접 프롬프트 인젝션이 피해로 이어지는 흐름을 다섯 단계로 나누면 점검할 위치가 보입니다.

  1. 외부 콘텐츠 유입: 에이전트가 웹페이지, 이메일, 문서, 검색 결과 또는 RAG 저장소에서 자료를 읽습니다.
  2. 지시와 데이터 혼동: 외부 자료의 문장을 분석 대상이 아니라 수행할 명령으로 해석합니다.
  3. 원래 작업 이탈: 요약이나 검색에서 벗어나 공격자가 원하는 계획을 세웁니다.
  4. 권한 사용: 파일, 메일, 브라우저, 데이터베이스 또는 사내 API를 호출합니다.
  5. 외부 영향 발생: 정보가 노출되거나 메시지가 발송되고 시스템 상태가 바뀝니다.

NIST는 간접 인젝션이 요약을 왜곡하거나 공격자가 지정한 정보를 출력하고, 악성 사이트로 사용자를 유도하거나 에이전트의 작업을 탈취할 수 있다고 정리합니다. 제한된 자원에 접근하는 모델을 조종해 정보를 외부로 보내는 사례도 공격 유형에 포함됩니다. NIST AI 100-2e2025, 3.4.2~3.4.4

첫 탐지가 실패해도 네 번째 단계의 권한 통제가 작동하면 피해를 줄일 수 있습니다. 입력 필터의 탐지율이 높더라도 모델이 관리자 권한과 외부 전송 권한을 함께 갖고 있다면 한 번의 실패가 커질 수 있죠.

RAG와 시스템 프롬프트만 믿지 않는다

RAG는 관련 자료를 제공하는 방식이지 가져온 자료가 안전하다는 보증은 아닙니다. OWASP는 RAG와 파인튜닝이 답변의 관련성과 정확도를 높일 수 있지만 프롬프트 인젝션의 단독 해결책은 아니라고 명시합니다. OWASP LLM01:2025 Prompt Injection

검색 저장소 자체도 공격면입니다. NIST는 악성 지시가 여러 RAG 단계를 통과하거나 오염된 문서가 특정 질의의 출력을 조작할 수 있다고 설명합니다. 외부 데이터를 표시하고 제3자 데이터의 지시를 걸러내는 완화책도 모든 공격을 막지는 못합니다. NIST AI 100-2e2025, 3.4.4 Mitigations

프롬프트 문구를 단단하게 만드는 작업은 필요합니다. 그것을 권한 경계로 취급해서는 안 됩니다.

방어 1: 지시와 외부 데이터를 분리한다

사용자 목표, 시스템 정책, 외부 콘텐츠를 가능한 한 별도 필드와 처리 단계로 유지해야 합니다. 외부 문서를 시스템 지시 뒤에 그대로 붙이기보다 출처, 콘텐츠 유형, 신뢰 수준을 메타데이터로 표시하고 “분석할 데이터”라는 경계를 유지하는 방식입니다.

Microsoft는 외부 콘텐츠 표시와 격리, 계획 이탈 감지, 도구 호출 흐름 분석, 정보 흐름 통제를 함께 사용하는 방어 심층화를 제안합니다. 한 가지 확률적 탐지기에 맡기지 말고 결정론적 통제를 겹치라는 접근입니다. Microsoft 간접 프롬프트 인젝션 방어 지침

방어 2: 모델 출력은 실행 전 다시 검증한다

모델이 도구 이름과 인자를 출력했다고 해서 곧바로 실행할 이유는 없습니다. 애플리케이션 코드가 허용된 도구인지, 인자 형식이 맞는지, 대상이 허용 목록에 있는지, 현재 사용자에게 권한이 있는지를 판단해야 합니다.

OWASP는 기대 출력 형식을 정의하고 결정론적 코드로 결과를 검증하라고 권고합니다. 입력·출력 필터, 최소 권한, 고위험 작업의 사람 승인도 같은 완화 목록에 포함합니다. OWASP LLM01:2025 Prompt Injection

구조화 출력은 구문 오류를 줄여줄 뿐입니다. recipient가 올바른 JSON 문자열이어도 형식 검증 뒤에 수신 도메인, 기밀 등급, 발신 권한 같은 업무 정책을 코드에서 확인해야 합니다. 모델에게 안전 여부를 다시 묻는 것만으로는 독립된 통제가 되지 않습니다.

방어 3: 권한을 짧고 좁게 준다

에이전트가 읽기, 쓰기, 삭제, 외부 전송 권한을 한꺼번에 가질 필요는 드뭅니다. 검색 작업에는 읽기 권한만 주고 수정 작업은 별도 도구와 승인 절차로 나누는 편이 낫습니다. Microsoft는 필요한 최소한의 단기 권한만 부여하고 사용 후 제거하는 방식을 제안합니다. Microsoft 간접 프롬프트 인젝션 방어 지침

사용자 개인의 광범위한 토큰보다 애플리케이션 전용 자격 증명과 좁은 스코프가 적절합니다. OWASP 역시 확장 기능에는 애플리케이션 자체 토큰을 제공하고 모델이 아니라 코드에서 기능을 처리하며, 권한을 의도한 작업에 필요한 수준으로 제한하라고 권고합니다. OWASP LLM01:2025 Prompt Injection

방어 4: 중요한 행동은 실행 직전에 확인한다

승인은 대화를 시작할 때 한 번 받는 동의가 아닙니다. 실제 수신자, 변경 대상, 공개될 데이터, 결제 금액처럼 결과를 바꾸는 정보를 실행 직전에 보여줘야 합니다.

OpenAI는 필요한 데이터에만 접근을 제한하고, 이메일 전송이나 구매 같은 중요한 행동을 확정하기 전에 세부 내용을 검토하며, “이메일을 확인하고 필요한 일을 모두 처리하라” 같은 넓은 요청보다 구체적인 작업을 주도록 안내합니다. 동시에 이런 지침이 모든 프롬프트 인젝션을 막지는 못한다고 밝힙니다. OpenAI 프롬프트 인젝션 안내

승인 화면에는 외부 수신자, 첨부 파일, 포함된 개인정보, 되돌릴 수 있는지를 보여줘야 합니다. 승인 횟수보다 승인 품질이 중요합니다.

방어 5: 실패 사례를 회귀 테스트로 남긴다

입력 필터, 안전 분류기, 규칙 기반 검사, 샌드박스는 서로 다른 실패 형태를 다룹니다. OpenAI의 에이전트 구축 가이드도 가드레일 하나만으로 충분하지 않으며 인증·인가, 접근 통제, 일반 소프트웨어 보안과 함께 적용해야 한다고 설명합니다. OpenAI 에이전트 구축 가이드

테스트에는 분할 명령, 다국어와 인코딩, 이미지 속 텍스트, 악성 도구 응답, RAG 오염과 연속 도구 호출을 포함할 수 있습니다. OWASP는 정기적인 공격 시뮬레이션을, NIST는 프롬프트 인젝션·데이터 오염 등을 다루는 레드팀과 보안 조치의 정기 평가를 권고합니다. OWASP LLM01:2025 Prompt Injection NIST AI 600-1, MS-2.7

모델, 시스템 프롬프트, 검색 인덱스, 도구 정의, 권한 정책 중 하나라도 바뀌면 기존 실패 사례를 다시 실행해야 합니다. 답변 차단 여부뿐 아니라 실제 도구 호출과 외부 통신까지 확인해야 하죠.

운영 체크리스트

외부 콘텐츠와 모델 경계

  • 웹, 이메일, 파일, RAG 문서와 도구 응답을 불신 입력으로 분류했는가
  • 시스템 정책과 외부 콘텐츠를 단순한 한 문자열로 합치지 않는가
  • 출력 스키마와 필수 필드를 코드로 검증하는가
  • 도구 이름, 도메인, 파일 경로와 수신자에 허용 목록이 있는가

권한과 실행

  • 읽기·쓰기·삭제·외부 전송 권한이 분리되어 있는가
  • 자격 증명이 필요한 범위와 시간으로 제한되는가
  • 고위험 작업은 대상과 데이터 범위를 보여준 뒤 승인받는가
  • 모델 출력이 HTML, SQL, 셸 명령으로 곧바로 실행되지 않는가

배포 후 운영

  • 입력·출력과 함께 도구 호출, 정책 판정, 권한 변경을 기록하는가
  • 공격이 의심되면 도구와 자격 증명을 빠르게 비활성화할 수 있는가
  • 모델·프롬프트·RAG·도구 변경 후 공격 회귀 테스트를 수행하는가

세 가지 한계

첫째, 모든 공격을 예방한다고 약속할 수 없습니다. OWASP는 생성형 AI의 확률적 특성 때문에 빈틈없는 방어 방법이 있는지 불분명하다고 설명하고, NIST도 현재 완화책이 모든 공격을 막지는 못한다고 정리합니다. OWASP LLM01:2025 NIST AI 100-2e2025

둘째, 방어 계층은 비용을 만듭니다. Microsoft는 런타임 감시와 격리된 추론이 지연이나 연산 비용을 늘리고 확률적 탐지가 정상 작업을 막는 오탐을 만들 수 있다고 적습니다. 서비스마다 허용할 지연과 위험 수준이 다릅니다. Microsoft 간접 프롬프트 인젝션 방어 지침

셋째, 사람 승인이 형식적인 클릭으로 변할 수 있습니다. 실제 실행 정보가 보이지 않거나 알림이 너무 자주 나오면 위험을 구분하기 어렵습니다. 고위험 행동을 좁게 정의하고 판단에 필요한 내용을 보여줘야 합니다.

처음부터 거대한 보안 플랫폼을 붙일 필요는 없습니다. 현재 에이전트의 도구를 읽기, 쓰기, 삭제, 외부 전송 네 칸으로 나눠보세요. 한 도구가 네 칸을 모두 차지한다면 프롬프트보다 권한부터 쪼갤 이유가 충분합니다.


공식 참고자료

#프롬프트 인젝션 #AI 보안 #LLM #AI 에이전트

관련 글

오류나 바뀐 조건을 찾으셨나요?

문제가 되는 문장과 확인 가능한 원문을 보내주시면 우선 검토합니다.

정정 요청