프롬프트 인젝션 공격은 AI가 사용자 입력과 시스템 지시를 모두 자연어로 처리한다는 점을 악용합니다. 방어의 핵심은 AI에게 중요한 권한을 몰아주지 않고, 입력부터 도구 실행과 최종 출력까지 각각 통제하는 것입니다.
📌 핵심 5줄 요약
1. 프롬프트 인젝션은 AI의 지시 우선순위를 흔들어 원래 목적과 다른 응답이나 행동을 유도하는 공격입니다.
2. 사용자가 직접 입력하는 방식뿐 아니라 웹페이지, 이메일, 문서에 숨겨진 지시를 읽게 만드는 간접 공격도 있습니다.
3. 시스템 프롬프트를 숨기는 것만으로는 충분하지 않으며 민감정보와 권한을 모델에서 분리해야 합니다.
4. 입력 정제, 지시와 데이터의 분리, 출력 검증, 도구 호출 승인 절차를 함께 적용해야 합니다.
5. 방어 여부는 정상적인 질문보다 공격적인 우회 시도와 실제 업무 흐름을 포함한 테스트로 확인해야 합니다.
📌 목차
01 | 프롬프트 인젝션이란
02 | 공격이 가능한 이유
03 | 직접 프롬프트 인젝션
04 | 간접 프롬프트 인젝션
05 | 대표적인 공격 목표
06 | 시스템 프롬프트 유출과 한계
07 | 프롬프트 인젝션과 일반 입력 공격의 차이
08 | 기본 방어 원칙
09 | 입력 데이터와 지시 분리
10 | 출력 검증과 후처리
11 | 도구 호출과 권한 통제
12 | 민감정보와 메모리 보호
13 | 테스트와 사고 대응
14 | 실무 적용 체크포인트
01 | 프롬프트 인젝션이란
프롬프트 인젝션은 대규모언어모델이나 생성형 AI에 전달되는 텍스트를 조작해 모델의 행동을 공격자가 원하는 방향으로 바꾸는 기법입니다. 공격자는 기존 업무 지시를 무시하라고 요구하거나, 특정 정보를 공개하거나, 원래 허용되지 않은 도구를 사용하도록 유도할 수 있습니다.
문제는 모델이 자연어로 작성된 지시와 단순한 참고 데이터를 언제나 완벽하게 구분하지 못한다는 데 있습니다. 따라서 보안 규칙을 프롬프트 한 문장에만 의존하면 우회 가능성이 생깁니다.
02 | 공격이 가능한 이유
일반적인 소프트웨어는 명령어와 데이터를 문법적으로 구분하는 경우가 많지만, 언어 모델은 지시와 데이터가 모두 토큰 형태로 입력됩니다. 모델은 보안 정책을 실행하는 전용 보안 엔진이라기보다 입력 맥락을 바탕으로 다음 응답을 생성하는 시스템입니다.
이 때문에 “이전 지시를 무시하라”와 같은 문장이 단순한 문서 내용으로 들어와도 모델의 판단에 영향을 줄 수 있습니다. 특히 외부 검색, 파일 분석, 이메일 요약, 자동화 도구 호출을 연결하면 공격 표면이 넓어집니다.
03 | 직접 프롬프트 인젝션
직접 공격은 사용자가 챗봇이나 AI 서비스에 악성 지시를 직접 입력하는 방식입니다. 예를 들어 업무 목적과 관계없는 시스템 규칙 공개를 요구하거나, 금지된 작업을 수행하도록 반복적으로 우회 지시를 보낼 수 있습니다.
단순히 공격 문구를 차단하는 방식은 표현을 바꾼 우회 시도에 취약할 수 있습니다. 따라서 특정 문장을 찾는 것보다 요청의 목적, 접근 대상, 필요한 권한과 결과의 위험성을 함께 판단해야 합니다.
04 | 간접 프롬프트 인젝션
간접 프롬프트 인젝션은 공격자가 AI에 직접 명령하지 않고, AI가 읽을 외부 자료에 악성 지시를 심어두는 방식입니다. 웹페이지, 이메일, 첨부 문서, 고객 문의, 데이터베이스 레코드 등이 공격 매개체가 될 수 있습니다.
예를 들어 문서 요약 AI가 문서 안의 문장을 지시로 오인하면 원래 요약 대신 내부 정보 공개나 외부 도구 호출을 시도할 수 있습니다. 외부 콘텐츠는 신뢰할 수 없는 데이터로 취급하고, 그 안의 지시를 실행하지 않도록 설계해야 합니다.
05 | 대표적인 공격 목표
공격 목표는 크게 정보 탈취, 정책 우회, 오작동 유도, 도구 악용으로 나눌 수 있습니다. 시스템 프롬프트나 내부 지침을 알아내려는 시도, 다른 사용자의 정보 노출, 악성 답변 생성, 승인되지 않은 파일·메일·웹 요청 실행 등이 대표적입니다.
| 공격 목표 | 발생 가능한 문제 |
|---|---|
| 지시 유출 | 내부 정책이나 업무 규칙이 노출될 수 있습니다. |
| 데이터 노출 | 대화 기록, 문서, 개인정보가 잘못 반환될 수 있습니다. |
| 도구 악용 | 메일 발송, 파일 변경, 외부 요청 등이 의도와 다르게 실행될 수 있습니다. |
| 응답 조작 | 허위 요약, 위험한 안내, 업무 판단 오류가 발생할 수 있습니다. |
06 | 시스템 프롬프트 유출과 한계
시스템 프롬프트 유출은 모델의 내부 지시나 운영 규칙을 답변으로 끌어내려는 공격입니다. 그러나 시스템 프롬프트를 숨긴다고 해서 핵심 보안 문제가 해결되지는 않습니다.
프롬프트에 비밀번호, 인증 토큰, 개인정보 같은 비밀을 넣으면 유출 위험이 커집니다. 또한 모델이 비밀을 직접 출력하지 않더라도 응답 패턴을 통해 일부 규칙이 추론될 수 있습니다. 비밀값은 프롬프트가 아니라 별도의 보안 저장소와 접근 제어로 관리해야 합니다.
07 | 프롬프트 인젝션과 일반 입력 공격의 차이
SQL 인젝션이나 명령어 인젝션은 대체로 특정 문법을 주입해 프로그램의 해석 구조를 바꾸는 공격입니다. 반면 프롬프트 인젝션은 자연어 의미와 맥락을 이용하므로 표현이 다양하고 완전한 차단 규칙을 만들기 어렵습니다.
따라서 기존의 문자열 필터만으로는 부족합니다. 모델의 답변이 실제 시스템에 영향을 주는 지점, 특히 파일 쓰기·메일 전송·결제·계정 변경과 같은 외부 효과를 별도로 보호해야 합니다.
08 | 기본 방어 원칙
첫째, 모델에게 필요한 최소 권한만 제공합니다. 둘째, 신뢰할 수 없는 콘텐츠를 데이터로 표시하고 그 안의 지시를 실행하지 않도록 합니다. 셋째, 모델의 응답을 곧바로 실행하지 않고 별도의 검증 단계를 둡니다.
넷째, 민감정보는 모델 입력에 가능한 한 포함하지 않습니다. 다섯째, 위험한 작업은 사용자의 명시적 승인이나 사람이 확인하는 절차를 요구합니다. 여섯째, 정상 입력뿐 아니라 우회·반복·다국어·인코딩 변형을 포함해 지속적으로 점검합니다.
09 | 입력 데이터와 지시 분리
사용자의 요청, 시스템 정책, 외부 문서, 검색 결과를 하나의 긴 문자열로 섞지 않는 것이 좋습니다. 각 데이터의 출처와 신뢰 수준을 표시하고, 외부 콘텐츠는 “참고 데이터”로만 다루도록 애플리케이션에서 구조화해야 합니다.
입력값에는 길이, 형식, 인코딩, 파일 유형 제한을 적용할 수 있습니다. 다만 특정 공격 문구만 삭제하는 방식은 우회될 수 있으므로 입력 필터는 보조 수단으로 사용해야 합니다.
실무에서 확인할 항목
사용자 지시와 외부 데이터가 구분되어 있는지, 외부 데이터 안의 명령문이 실행 경로로 전달되지 않는지, 모델이 불확실한 요청을 사람에게 넘길 수 있는지 확인합니다.
10 | 출력 검증과 후처리
모델 출력은 정답이나 안전한 명령으로 간주하지 말고 검증해야 합니다. 출력 형식을 제한하고, 허용된 값인지 확인하며, 개인정보·비밀·위험한 명령이 포함됐는지 검사한 뒤 사용자에게 보여주는 방식이 안전합니다.
특히 모델이 생성한 URL, 파일 경로, 데이터베이스 쿼리, API 매개변수, 메일 수신자 정보는 별도 검증이 필요합니다. 자연어 답변과 실제 실행 명령을 분리하면 잘못된 출력이 시스템 전체로 확산되는 것을 줄일 수 있습니다.
11 | 도구 호출과 권한 통제
AI 에이전트가 검색, 파일, 메일, 일정, 결제 같은 도구를 사용할 때는 모델에게 직접적인 전체 권한을 주지 않아야 합니다. 기능별로 권한을 나누고, 필요한 작업만 제한된 범위에서 수행하도록 설계합니다.
읽기와 쓰기 권한을 분리하고, 외부 전송이나 삭제처럼 되돌리기 어려운 작업에는 사용자 확인을 요구합니다. 도구 호출마다 사용자, 요청 목적, 대상, 매개변수, 실행 결과를 기록하면 사후 추적과 차단에 도움이 됩니다.
12 | 민감정보와 메모리 보호
개인정보, 인증정보, 내부 문서, 고객 기록을 모델의 장기 메모리나 대화 맥락에 무분별하게 저장하지 않아야 합니다. 꼭 필요한 정보만 최소한으로 전달하고, 식별자를 가린 뒤 처리하는 방법을 검토합니다.
대화 간 데이터가 섞이지 않도록 사용자별·조직별 접근 경계를 분리해야 합니다. 메모리 기능을 사용하는 경우 저장 대상, 보존 기간, 삭제 방법, 재사용 조건을 명확히 정하고 사용자가 확인할 수 있게 하는 것이 좋습니다.
13 | 테스트와 사고 대응
프롬프트 인젝션 테스트는 한두 개의 공격 문장을 입력하는 것으로 끝나지 않습니다. 시스템 프롬프트 유출, 외부 문서의 악성 지시, 민감정보 요청, 도구 호출 유도, 우회 표현과 언어 변형을 시나리오로 만들어 점검해야 합니다.
문제가 발생하면 해당 대화를 보존하고, 어떤 입력이 어느 도구와 데이터에 도달했는지 확인합니다. 영향을 받은 권한과 토큰을 차단하거나 교체하고, 로그와 접근 정책을 검토한 뒤 재발 방지 테스트를 추가합니다.
간단한 테스트 사례
문서 요약 기능에 공격 지시가 포함된 파일을 넣고, 요약 결과가 문서 내용과 무관한 작업을 제안하거나 실행하는지 확인합니다. 또한 모델이 접근할 수 없는 자료를 요구했을 때 거부하고 대체 절차를 안내하는지도 점검합니다.
14 | 실무 적용 체크포인트
프롬프트 인젝션 방어는 한 번의 필터 설정이 아니라 서비스 설계 전반의 문제입니다. 다음 항목을 개발·운영 과정에서 반복 확인하면 위험한 자동화를 줄이는 데 도움이 됩니다.
☑ 체크리스트
- 시스템 프롬프트에 비밀번호, 인증 토큰, 불필요한 개인정보를 넣지 않았는가?
- 사용자 입력과 외부 문서·검색 결과를 서로 다른 데이터로 구분했는가?
- 모델이 사용하는 도구에 최소 권한과 기능별 접근 제한을 적용했는가?
- 파일 변경, 외부 전송, 삭제, 결제 등 고위험 작업에 사람의 승인을 요구하는가?
- 모델 출력의 형식, URL, 파일 경로, 수신자, 개인정보를 실행 전에 검증하는가?
- 공격 로그와 도구 호출 기록을 남기고 이상 행동을 탐지할 수 있는가?
- 직접·간접 공격, 우회 표현, 다국어 입력을 포함한 보안 테스트를 반복하는가?
📖 자주하는 질문 Q&A
프롬프트 인젝션은 특정 문구를 차단하면 막을 수 있나요?
완전히 막기 어렵습니다. 공격자는 표현, 언어, 문장 순서와 맥락을 바꿀 수 있으므로 문구 필터는 보조 수단으로 사용하고 권한 통제와 출력 검증을 함께 적용해야 합니다.
시스템 프롬프트를 공개하지 않으면 안전한가요?
아닙니다. 프롬프트를 숨기는 것은 일부 정보 유출을 줄일 수 있지만, 외부 데이터 오염이나 도구 악용을 막지는 못합니다. 민감정보를 별도로 보호하고 위험한 작업을 승인 절차 뒤에 두는 것이 중요합니다.
검색이나 문서 요약 기능도 프롬프트 인젝션에 취약한가요?
취약할 수 있습니다. 검색 결과와 문서에 악성 지시가 포함될 수 있기 때문입니다. 외부 콘텐츠를 신뢰할 수 없는 데이터로 취급하고, 그 안의 지시가 도구 실행이나 정책 변경으로 이어지지 않게 해야 합니다.
AI가 답변만 하고 외부 작업을 하지 않으면 위험이 없나요?
위험이 줄어들지만 사라지지는 않습니다. 잘못된 정보, 내부 규칙 노출, 개인정보 반환, 사용자의 의사결정 오류가 발생할 수 있으므로 입력과 출력에 대한 기본 검증은 필요합니다.
📝 마무리
프롬프트 인젝션은 자연어 기반 AI의 구조적 특성에서 발생하므로 단일 차단 문구만으로 해결하기 어렵습니다. 입력과 외부 데이터를 분리하고, 모델 권한을 최소화하며, 출력과 도구 호출을 검증하는 다층 방어가 기본입니다. 특히 민감정보와 되돌리기 어려운 작업을 모델의 자율 영역에서 분리하는 것이 가장 중요합니다.