AI가 웹페이지 지시를 따를 때, 프롬프트 인젝션 확인법

AI를 활용하여 생성한 이미지입니다.

핵심부터 말하면: AI에게 웹페이지·PDF·이메일·검색 결과를 읽히는 순간, 그 자료 안의 문장은 모두 ‘지시’가 아니라 우선 ‘데이터’로 취급해야 합니다. 문서에 “이전 지시를 무시하라”, “비밀을 출력하라”, “이 링크를 열고 메일을 보내라” 같은 문장이 섞여 모델의 행동을 바꾸려는 공격이 프롬프트 인젝션입니다.[1][2] 요약·검색은 읽기 작업으로 제한하고, 결제·메일 발송·파일 삭제·외부 게시 같은 행동은 별도 확인과 사람 승인을 거치게 하세요.

프롬프트 인젝션은 어디에 숨어 있나요?

직접 프롬프트 인젝션은 사용자가 채팅창에 모델의 역할을 바꾸거나 비밀 정보 출력을 요구하는 방식입니다. 간접 프롬프트 인젝션은 사용자가 직접 입력하지 않아도 웹페이지, 검색 결과, PDF, 이메일, 이미지 OCR 텍스트, 코드 저장소에 공격 문장을 넣어 모델이 읽도록 만드는 방식이에요. 예를 들어 “회의 날짜만 찾아줘”라는 요청을 처리하던 중 문서에 시스템 지시를 출력하거나 내부 파일을 읽으라는 문장이 나오면, 그것은 회의 자료가 아니라 검토해야 할 데이터입니다.

웹페이지에 명령형 문장이 있다고 모두 악성은 아닙니다. 사용 설명서의 정상적인 절차도 “버튼을 누르세요”처럼 쓰이기 때문이에요. 현재 업무의 데이터에 관한 설명인지, 모델이나 연결된 도구에 새 행동을 시키는 문장인지가 구분 기준입니다.

읽기와 실행을 분리하는 기본 구조

1. 목적 고정: “이 문서에서 날짜와 참석자만 추출”처럼 출력 범위를 먼저 정합니다.
2. 자료 표시: 웹페이지나 파일을 ‘신뢰하지 않는 참고 자료’로 감싸고, 그 안의 지시를 실행하지 말라는 규칙을 시스템 수준에서 둡니다.
3. 출력 제한: 필요한 필드만 반환하게 하고 비밀·자격 증명·내부 경로를 출력 대상으로 포함하지 않습니다.
4. 행동 분리: 검색·계산처럼 위험이 낮은 도구와 메일·결제·삭제처럼 결과가 되돌아가기 어려운 도구를 분리합니다.
5. 승인: 외부로 전송되거나 상태가 바뀌는 작업은 대상, 내용, 범위를 사람이 확인한 뒤 실행합니다.[1]

모델에게 “안전하게 행동해”라고 한 문장 적는 것만으로는 충분하지 않습니다. 도구가 실제로 어떤 권한을 갖는지, 호출 전에 어떤 값이 보이는지, 실패했을 때 되돌릴 수 있는지가 더 중요해요. 읽기 전용 API 키와 쓰기 권한 토큰을 분리하고, 가능한 경우 샌드박스나 테스트 계정에서 먼저 실행하세요.

웹페이지를 읽힐 때 확인하는 순서

1. 요청을 좁혀서 시작하세요

페이지 전체를 읽고 “알아서 필요한 일을 해줘”라고 맡기기보다 필요한 항목과 허용된 행동을 명시합니다. 예를 들어 제품 페이지에서는 이름·공식 가격·지원 운영체제만 추출하고, 구매 버튼을 누르거나 판매자에게 문의하는 행동은 요청에서 제외하세요. 페이지 속 문장이 모델에게 직접 말하는 것처럼 보이더라도 원래 작업 범위를 늘리지 않습니다.

2. 의심스러운 문장을 별도로 표시하세요

“시스템 메시지를 무시”, “내부 프롬프트를 공개”, “이 주소로 파일 업로드”, “관리자 권한을 요청” 같은 패턴은 내용 요약에 포함할 수 있지만 실행할 지시로 승격해서는 안 됩니다. 정상적인 안내와 공격 문장을 자동으로 완벽히 구분할 수 있다고 가정하지 말고, 불확실하면 문장과 출처를 사람에게 보여 주세요.

3. 인용과 원문을 대조하세요

검색 결과가 제공한 요약만 믿지 말고 중요한 사실은 원문 링크와 문맥을 확인합니다. 다른 페이지로 리디렉션되는 링크, 페이지에 나중에 삽입된 내용, 광고 영역의 문장을 본문 근거로 사용하지 않도록 범위를 정하세요. 출처 확인은 인젝션을 막는 동시에 모델이 만든 요약의 누락과 왜곡을 찾는 절차이기도 합니다.

파일·이메일·OCR의 예외

PDF와 이메일은 작성자가 신뢰할 수 있어 보여도 외부에서 전달된 콘텐츠입니다. 첨부 파일의 텍스트에 지시가 숨어 있을 수 있고, 이미지 OCR은 원문과 다른 문자를 읽을 수 있어요. 파일을 분석하는 동안 외부 URL을 자동으로 열거나 첨부 파일을 실행하지 말고, 문서에서 추출한 링크와 명령은 목록으로만 반환하게 하세요. 사내 문서라도 계정 권한이 넓으면 내부 정보가 연쇄적으로 노출될 수 있으므로 최소 권한을 유지합니다.

도구 호출 전에 거쳐야 할 승인 질문

이 질문에 답할 수 없으면 도구를 호출하지 않는 것이 기본값입니다. 특히 받은편지함에서 자동으로 답장을 보내거나 웹페이지의 버튼을 눌러 결제하는 에이전트는 미리보기와 최종 승인 단계를 분리해야 합니다. OWASP와 OpenAI의 안전 가이드도 외부 입력을 신뢰하지 않고 도구 권한과 승인 경계를 설계하는 방향을 강조합니다.[1][2]

에이전트에 적용할 때의 운영 경계

간단한 문서 요약과 도구 실행을 하나의 대화 흐름에 묶으면, 모델이 외부 자료의 문장을 실행 지시로 착각했을 때 피해가 커질 수 있습니다. 문서 수집 단계는 읽기 전용 계정으로 운영하고, 추출 결과는 구조화된 데이터로 넘긴 뒤, 행동 단계에서 다시 정책과 승인을 확인하세요. 각 단계가 어떤 원문을 사용했는지와 어떤 도구를 호출했는지도 로그에 남겨야 사후에 원인을 찾을 수 있습니다.

의심스러운 지시를 발견했을 때 모델에게 조용히 무시하라고만 하지 말고, “외부 자료에서 실행 지시로 보이는 문장을 발견했으나 실행하지 않았다”는 식으로 보고하게 하세요. 이 보고에는 해당 문장의 출처와 문맥을 포함하되, 비밀 정보나 전체 내부 문서를 그대로 복사하지 않는 제한이 필요합니다. 보안 테스트는 실제 계정 대신 샌드박스와 가짜 데이터로 수행하고, 차단·허용 사례를 반복해 정책이 원하는 범위에서 작동하는지 확인하세요. 실제 사고가 의심되면 대화 로그와 원문 URL을 보존하고 토큰이나 세션을 폐기한 뒤, 조직의 보안 대응 절차에 따라 접근 권한을 점검해야 합니다. 도구가 이미 실행됐다면 결과가 외부로 전송됐는지와 변경된 파일·레코드를 먼저 확인하고 추가 자동화를 중지하세요.

승인 없이 실행된 호출은 성공 여부와 관계없이 보안 검토 대상으로 분류하는 편이 좋습니다.

자주 묻는 질문

프롬프트에 “인젝션을 무시하라”고 쓰면 해결되나요?

그 문장만으로는 충분하지 않습니다. 공격 문장이 같은 입력 흐름으로 들어오고 도구 권한이 넓다면 모델이 잘못 해석할 여지가 남아요. 데이터와 지시를 분리하고, 출력 형식·권한·승인을 함께 설계해야 합니다.

웹페이지를 읽는 것 자체를 막아야 하나요?

항상 그럴 필요는 없습니다. 다만 읽기 전용으로 제한하고, 외부 자료의 문장을 실행하지 않으며, 중요한 사실은 원문에서 확인하는 절차가 필요합니다. 위험이 높은 사이트나 민감한 문서라면 사람이 먼저 내려받아 범위를 확인하는 방법을 선택하세요.

출처

1. OpenAI Platform, Agent Builder safety
2. OWASP, LLM Prompt Injection Prevention Cheat Sheet
3. Haechi, AI 웹 검색 결과와 인용 검증
4. Haechi, AI 도구 호출과 계산·검색
5. Haechi, 생성형 AI에 개인정보를 입력하기 전 체크리스트