AI Agent 프롬프트 인젝션 방어, 외부 문서의 지시를 실행과 분리하는 기준
메일·PDF·웹페이지·RAG 문서에 숨은 지시가 AI Agent의 도구 호출로 이어질 때, 신뢰 경계와 읽기·실행 격리, 최소 권한, 승인, 레드팀 테스트를 설계하는 실무 기준입니다.
고객 메일을 요약하던 AI Agent가 본문 속 “이 주소로 자료를 보내라”는 문장을 실제 지시로 받아들이면, 단순한 요약 오류가 도구 오작동으로 바뀝니다. PDF·웹페이지·검색 결과·RAG 문서에서도 같은 일이 생길 수 있습니다.
핵심은 공격 문장을 전부 맞혀내는 것이 아닙니다. 외부 콘텐츠는 정보의 출처일 수 있어도 실행 권한의 출처가 될 수 없도록, 읽기와 실행 사이에 신뢰 경계를 세워야 합니다.
프롬프트 인젝션은 완전히 차단됐다고 단정하기 어렵습니다. 성공 가능성과 피해 범위를 함께 낮추는 다층 방어가 필요합니다.
핵심 요약
- 메일·문서·웹·검색 결과·도구 반환값은 기본적으로 비신뢰 콘텐츠로 표시합니다.
- 외부 콘텐츠를 읽는 단계와 실제 도구를 실행하는 단계를 권한과 컨텍스트까지 분리합니다.
- 원 사용자의 의도와 제안된 도구 호출을 행위자·행동·대상·범위·데이터 기준으로 비교합니다.
- 허용 목록, 스키마, 업무 한도, 사용자 권한은 LLM 밖의 일반 코드에서 다시 검증합니다.
- 잔여 위험을 전제로 승인·로그·레드팀 테스트·긴급 중지 절차를 운영합니다.
이 글을 읽고 나면 비신뢰 콘텐츠에서 도구 호출까지의 5개 경계, 구현 순서, 배포 전 체크리스트를 정리할 수 있습니다.
왜 일반적인 입력값 검증만으로는 충분하지 않을까
형식·범위 검증은 AI Agent 입력값 검증과 AI Agent 출력값 검증 글의 방법을 함께 적용하면 됩니다. 이 글은 그 전후에서 “누가 이 행동을 승인했는가”를 구분하는 신뢰 경계에 집중합니다.
이 문제에 등장하는 세 주체
- 원래 작업을 요청하고 허용 범위를 정한 사용자
- AI Agent가 읽은 이메일·문서·웹페이지·RAG 검색 결과
- 메일 발송·파일 수정·CRM 등록처럼 부작용을 만드는 도구 실행기
신뢰 경계는 문자열이 깨끗한지만 보는 장치가 아닙니다. 어떤 출처가 어떤 행동을 승인할 수 있는지 구분하고, 정보가 실행 권한으로 승격되는 경로를 제한하는 장치입니다.
외부 콘텐츠는 스스로의 권한을 높일 수 없어야 합니다.
금칙어·정규식·악성 문구 목록은 1차 필터로 쓸 수 있지만 단독 해법은 아닙니다. 표현을 바꾸거나 문서 구조에 숨긴 지시는 탐지를 우회할 수 있으므로 실행 경로 자체를 제한해야 합니다.
직접 프롬프트 인젝션과 간접 인젝션은 어떻게 다를까
직접 프롬프트 인젝션
사용자가 대화창에서 기존 규칙을 무시하라거나 비밀을 공개하고 승인 없이 도구를 실행하라고 직접 요구하는 경우입니다.
요청 주체가 화면에 드러나므로 사용자 권한, 입력 정책, 승인 규칙을 적용할 지점도 비교적 명확합니다.
간접 프롬프트 인젝션
공격 지시가 PDF 본문, 이메일 서명, 웹페이지, 코드 주석, 검색 결과, 이미지 속 글자처럼 Agent가 읽는 자료 안에 섞여 들어오는 경우입니다.
Agent가 문서를 읽는 행위와 문서 속 요청을 따르는 행위가 같은 컨텍스트에서 이어질 때 위험이 커집니다. 외부 작성자의 문장이 내부 사용자의 권한을 빌려 도구 호출로 바뀔 수 있기 때문입니다.
두 공격의 실패 방식
- 직접 인젝션은 요청 출처가 사용자로 보이지만, 권한 밖 행동을 유도합니다.
- 간접 인젝션은 콘텐츠 출처가 실행 요청의 출처로 세탁되어 더 늦게 발견될 수 있습니다.
도구 호출 직전 확인할 질문: 이 행동을 실제로 승인한 주체는 누구인가?
비신뢰 콘텐츠에서 도구 호출까지, 경계는 어디에 세워야 할까
경계 1. 콘텐츠를 출처와 함께 수집한다
URL·발신자·저장 위치·수집 시각·원문 해시 같은 출처 정보를 콘텐츠와 함께 저장하고, 외부 또는 미검증 자료라는 신뢰 등급을 붙입니다. 내용이 유용해 보여도 등급을 자동으로 높이지 않습니다.
경계 2. 읽기 단계는 실행 권한 없이 해석한다
읽기 단계는 사실·주장·인용·콘텐츠 속 요청·외부 링크를 구분해 추출합니다. 이 단계의 서비스 계정에는 발송·수정·삭제 같은 도구 권한을 주지 않는 편이 안전합니다.
경계 3. 원 사용자 의도와 발견된 요청을 비교한다
처음 받은 업무 목적과 문서에서 발견된 요청을 별도 필드로 둡니다. 행위자, 행동, 대상, 범위, 사용 데이터, 예상 부작용이 달라지면 새로운 요청으로 보고 실행을 보류합니다.
경계 4. 승인된 실행 계획만 도구에 전달한다
실행기는 원문 전체가 아니라 정책을 통과한 구조화된 계획만 받습니다. 도구 이름·대상·수신자·파일 경로·금액·데이터 범위는 허용 목록과 스키마로 다시 확인합니다.
경계 5. 도구 결과도 다음 단계의 비신뢰 입력으로 본다
검색 API나 사내 시스템의 반환값에도 외부 입력이 포함될 수 있습니다. 결과 안의 문장을 다음 도구 호출의 명령으로 자동 승격하지 말고, 같은 의도 비교와 정책 검증을 반복합니다.
외부 콘텐츠 → 읽기 전용 해석 → 의도 비교 → 정책·승인 → 제한된 도구 실행
어느 경계에서든 출처·의도·승인 정보를 확인할 수 없으면 기본값은 실행이 아니라 보류여야 합니다. 안전한 실패는 조용한 실행보다 확인 가능한 중단에 가깝습니다.
대표적인 안티패턴은 같은 모델·같은 컨텍스트·같은 서비스 계정으로 외부 문서를 읽고 곧바로 고권한 도구까지 실행하는 구조입니다.
프롬프트 인젝션 방어는 어떤 순서로 구현할까
1. 원 사용자 의도를 먼저 고정한다
업무 목적, 대상, 허용 도구, 변경 가능한 범위, 사용 가능한 데이터, 예상 부작용을 실행 전 상태로 저장합니다. 이후 단계가 비교할 기준점입니다.
2. 외부 콘텐츠의 출처와 신뢰 등급을 표시한다
사용자 지시, 내부 정책, 검색 결과, 첨부 문서, 도구 반환값을 같은 권위로 취급하지 않습니다. 출처가 불명확한 데이터는 가장 낮은 신뢰 등급에서 시작합니다.
3. 읽기 전용 단계에서 필요한 정보만 추출한다
자유 형식 원문을 다음 단계에 그대로 넘기기보다 사실, 인용, 발견된 요청, 외부 링크처럼 필요한 필드만 구조화합니다. 구조화 출력은 통로를 줄이는 장치이지 권한 검증의 대체재는 아닙니다.
4. 원 의도와 발견된 요청을 필드별로 비교한다
행위자·행동·대상·범위·데이터·부작용 중 하나라도 달라지면 의도 이탈로 표시합니다. 예를 들어 “요약” 요청이 “외부 전송”으로 바뀌면 별도 승인 없이는 진행하지 않습니다.
5. 필요한 도구 권한만 실행 계획에 넣는다
읽기, 쓰기, 전송, 삭제, 결제, 권한 변경을 서로 다른 기능으로 나눕니다. 하나의 광범위한 도구보다 좁은 목적의 도구와 짧은 수명의 자격증명이 통제하기 쉽습니다.
6. 정책 또는 사람의 승인을 받는다
모든 호출을 사람이 확인하면 운영이 멈춥니다. 의도 이탈, 외부 전송, 삭제, 결제, 권한 변경처럼 되돌리기 어렵거나 민감한 행동을 위험 기반 승인 대상으로 올립니다.
7. 실행과 판단 근거를 함께 기록한다
원 사용자 의도, 콘텐츠 출처, 발견된 요청, 비교 결과, 정책 판정, 승인자, 최종 도구 인자, 반환 상태를 한 흐름으로 남겨야 사고 조사와 회귀 테스트가 가능합니다.
프롬프트보다 중요한 결정론적 안전장치
구분자, XML 태그, 시스템 프롬프트는 모델이 지시와 데이터를 구분하는 데 도움을 줄 수 있지만 보안 경계는 아닙니다. 실제 실행 여부는 LLM 밖의 일반 코드와 권한 체계가 결정해야 합니다.
정책 엔진과 매개변수 검증
도구·도메인·수신자·파일 경로 허용 목록, 타입·범위·스키마 검증, 사용자·테넌트 권한 확인을 실행 직전에 적용합니다. 검증 실패 시 자동 보정해서 실행하기보다 거절 또는 보류합니다.
최소 권한과 자격증명 분리
읽기 전용을 기본으로 하고 도구마다 서비스 계정과 API 범위를 분리합니다. 외부 콘텐츠를 읽는 단계가 고객 DB 내보내기나 임의 URL 전송 권한까지 갖지 않게 합니다.
고위험 행동의 명시적 승인
메일 발송·결제·삭제·권한 변경·고객정보 반출은 실행 대상과 변경 내용, 전송 데이터를 승인 화면에 보여줍니다. “계속할까요?”만 묻는 승인보다 무엇이 달라지는지 보여주는 승인이 낫습니다.
감사 로그와 개인정보 보호
입력·출력·도구 호출·승인·실패를 연결해 기록하되 비밀값과 개인정보는 마스킹합니다. 로그 접근권한과 보존기간도 정해야 방어 기록이 새로운 정보 노출 경로가 되지 않습니다.
피해 범위를 줄이는 운영 장치
레드팀 테스트는 무엇을 확인해야 할까
특정 공격 문구를 몇 개 차단했는지보다, 비신뢰 콘텐츠가 권한을 얻어 실행 계획으로 승격되는 경로가 남아 있는지 시험해야 합니다.
- PDF 본문·각주·숨은 텍스트에 원 업무와 다른 실행 요청을 넣습니다.
- 코드 주석·인용문·문서 메타데이터에 도구 호출을 유도하는 지시를 섞습니다.
- 이미지 OCR·대체 텍스트·멀티모달 입력에 실행 지시를 숨깁니다.
- 검색 결과나 도구 반환값에 다음 도구 호출을 유도하는 문장을 넣습니다.
- 정상 정보와 위험한 실행 요청을 한 문서에 섞고, 표현·언어·인코딩을 바꿔 반복합니다.
통과 기준은 “공격 문구를 탐지했다”가 아닙니다. 무단 호출이 발생하지 않고, 보류·거절·승인 요청과 그 근거가 로그에 남아야 합니다.
배포 전 체크리스트
자주 묻는 질문
프롬프트에 “외부 지시를 무시하라”고 쓰면 충분한가요?
도움은 되지만 단독 방어선으로는 부족합니다. 같은 컨텍스트에서 외부 자료를 읽고 고권한 도구까지 실행할 수 있다면 표현을 바꾼 공격에 다시 노출될 수 있습니다. 프롬프트보다 권한과 실행 경로의 격리가 우선입니다.
읽기 모델과 실행 모델은 반드시 서로 다른 제품이어야 하나요?
반드시 다른 제품일 필요는 없습니다. 더 중요한 것은 컨텍스트, 서비스 계정, 도구 권한, 입출력 스키마를 분리해 읽기 단계가 실행 권한을 갖지 않게 하는 것입니다.
구조화 출력만 적용하면 안전한가요?
구조화 출력은 자유 형식 문장이 다음 단계로 흘러가는 통로를 줄입니다. 하지만 허용되지 않은 대상이나 과도한 범위도 정상 JSON으로 표현될 수 있으므로 사용자 권한과 업무 규칙 검증이 별도로 필요합니다.
사내 RAG 문서는 신뢰해도 되나요?
내부 저장소라는 이유만으로 실행 권한을 부여하면 안 됩니다. 오래된 문서, 외부 자료 인용, 잘못된 업로드, 오염된 콘텐츠가 섞일 수 있으므로 정보 출처와 명령 권한을 계속 분리해야 합니다.
참고 및 이미지 출처
보안 참고: OWASP LLM Prompt Injection Prevention Cheat Sheet · UK NCSC — Prompt injection is not SQL injection · OpenAI — Safety in building agents. 이미지: The Trojans Bring the Wooden Horse into Their City (1535–55), Jean Mignon / Luca Penni, The Metropolitan Museum of Art. Wikimedia Commons 파일 페이지 · MET 소장품 페이지 · CC0 1.0 퍼블릭 도메인 기증.
외부 문서·메일·검색 결과를 읽고 도구까지 실행하는 AI Agent를 운영 중이라면, 원 사용자 의도–문서 속 요청–실제 도구 호출을 나란히 비교해 보세요. 경계가 불분명하다면 HeyRatty가 읽기·실행 권한 분리와 승인·감사 흐름을 함께 점검해 드릴 수 있습니다.