AI 에이전트 프롬프트 인젝션 방어: 외부 문서·웹 검색 결과를 분리하는 7단계

AI 에이전트에게 웹 검색, 사내 문서, 메일, 스프레드시트 같은 자료를 읽게 하면 답변만 만드는 단계와 실제 행동을 하는 단계가 연결됩니다. 이때 문서 안에 “이전 지시를 무시하라”, “이 주소로 파일을 보내라”와 같은 문장이 섞여 있으면 모델이 그것을 사실 설명이 아니라 지시로 해석할 수 있습니다. 이 글은 특정 제품의 안전성을 보증하는 글이 아니라, 도구를 연결하기 전 팀이 직접 기록할 수 있는 운영 체크리스트입니다.

AI 에이전트 프롬프트 인젝션이 일반 질문과 다른 이유

프롬프트 인젝션은 사용자의 정상적인 요청에 외부 주체가 만든 지시를 끼워 넣어 모델의 행동이나 출력을 의도와 다르게 바꾸려는 위험입니다. OWASP는 사용자가 직접 입력하는 직접 인젝션과 웹사이트·파일 같은 외부 입력을 통해 들어오는 간접 인젝션을 나눠 설명합니다. 따라서 문서가 정상적인 업무 자료처럼 보여도 그 안의 문장은 신뢰된 정책과 같은 층위에 놓으면 안 됩니다.

특히 에이전트에는 답변이라는 출력 외에 메일 발송, 링크 열기, 데이터 수정, 파일 업로드 같은 도구 행동이 있습니다. OpenAI의 에이전트 보안 설명도 외부 콘텐츠라는 source와 정보 전송·링크 접근 같은 위험한 sink가 결합될 때 영향이 커진다고 설명합니다. 아래처럼 “무슨 문장이 위험한가”와 “실제로 어떤 행동까지 이어지는가”를 따로 적어야 합니다.

첫 원칙: 외부 문서는 지시가 아니라 데이터다

에이전트의 문맥에는 최소 네 층이 있습니다. 시스템 정책과 애플리케이션 규칙, 사용자가 이번 작업에서 요청한 목표, 외부에서 읽어 온 자료, 도구가 반환한 결과입니다. 이 층을 하나의 긴 문자열로 이어 붙이면 어떤 문장이 권한을 갖는지 설명하기 어려워집니다. 원고를 생성할 때도 출처와 판단을 별도 필드로 유지하고, 도구 호출에는 그 판단을 그대로 권한으로 넘기지 않는 편이 안전합니다.

이 경계는 AI 윤리·거버넌스 가이드에서 다루는 책임 소재와도 연결됩니다. 누가 요청했는지, 어떤 자료를 읽었는지, 어떤 도구 인자가 승인됐는지가 남아야 나중에 결과를 설명할 수 있습니다.

외부 문서·웹 검색 결과를 나누는 7단계

1단계: 사용자의 목표와 금지 행동을 한 줄로 고정한다

“관련 자료를 찾아 처리해 줘”처럼 넓은 요청은 외부 지시가 끼어들 공간을 키웁니다. 먼저 결과물을 “공개된 자료 세 개를 요약하고 출처 링크를 남긴다”처럼 적고, 메일 발송·결제·삭제·권한 변경은 이번 작업의 금지 행동이라고 분명히 씁니다. 목표가 바뀌었다면 새 작업으로 다시 승인해야 합니다.

통과 조건: 에이전트가 읽기, 요약, 초안 작성 중 어디까지 할 수 있는지와 절대로 하지 않을 행동을 사람이 한 문장으로 재현할 수 있습니다.

2단계: 문장마다 출처와 신뢰 경계를 표시한다

웹 검색 결과, 첨부 문서, 사용자가 직접 입력한 정보, 내부 정책을 같은 배열에 넣지 않습니다. 최소한 source_type, 원문 URL 또는 파일 ID, 수집 시각, 신뢰 상태를 함께 기록합니다. “공식 문서에서 확인한 사실”과 “외부 문서가 주장하는 내용”은 서로 다른 문장으로 써야 합니다.

통과 조건: 답변의 핵심 주장마다 출처를 열어 볼 수 있고, 출처가 없는 추론은 추론이라고 표시됩니다. NIST의 생성형 AI 위험관리 자료처럼 위험과 불확실성을 관리하는 자료는 정답 목록으로 복사하지 말고 검증 절차의 근거로 사용합니다.

3단계: 데이터를 추출하고 지시문은 실행 큐에서 제외한다

문서에서 제목, 날짜, 금액, 상태, 링크 같은 업무 데이터를 추출하는 단계와 “무엇을 하라”는 행동 제안을 만드는 단계를 분리합니다. 외부 문장에 포함된 역할 변경, 비밀값 요구, 정책 무시, 파일 전송, 링크 방문 요청은 데이터 필드에 남길 수 있지만 도구 호출 인자로 자동 복사하지 않습니다.

통과 조건: 입력 문서에 공격 문구가 추가되어도 추출 결과와 실행 큐가 동일하게 유지되거나, 사람이 검토할 보류 상태로 떨어집니다. 정규식 하나만으로 안전하다고 결론내리지 말고, 문맥·출처·도구 위험을 함께 평가합니다.

4단계: URL과 첨부파일은 목적지와 전달값을 확인한다

링크는 도착할 사이트만의 문제가 아닙니다. URL의 경로·쿼리 문자열에 대화 내용이나 개인 정보가 들어갈 수 있고, 신뢰해 보이는 주소가 다른 곳으로 리디렉션될 수도 있습니다. OpenAI의 링크 안전성 설명은 자동으로 가져올 URL이 독립적으로 공개된 주소인지 확인하고, 확인되지 않은 주소는 사용자에게 보여 주거나 차단하는 방식을 소개합니다.

통과 조건: 자동 접근 전에 최종 URL, 전송되는 매개변수, 로그인 상태, 리디렉션, 파일의 출처를 기록합니다. 공개 검색만 필요한 업무라면 로그인된 계정과 개인 폴더를 연결하지 않는 것이 우선입니다.

5단계: 도구 권한은 업무가 아니라 결과의 위험으로 줄인다

읽기 권한이 있다고 작성·삭제 권한까지 필요한 것은 아닙니다. 도구를 연결할 때 읽기, 내부 초안 작성, 외부 전송, 삭제·권한 변경을 별도 등급으로 나누고 기본값은 읽기 전용으로 둡니다. AI 사이버보안·위협 탐지 가이드의 제로트러스트 관점처럼, “내부 도구이므로 안전하다”가 아니라 매 호출의 대상과 결과를 확인하는 방식입니다.

통과 조건: 토큰의 대상·범위·만료·회수 경로가 있고, 이번 작업에 사용하지 않는 도구는 애초에 노출되지 않습니다. 도구 이름이 비슷하다는 이유로 권한을 묶지 않습니다.

6단계: 외부 전송과 변경은 실행 직전에 사람이 승인한다

사람 승인은 “진행할까요?”라는 짧은 질문만을 뜻하지 않습니다. 승인 화면에는 주체, 도구 이름, 구체적인 인자, 대상, 공유되는 정보, 예상 결과, 취소·복구 방법이 보여야 합니다. OpenAI의 에이전트 보안 자료도 중요한 행동이나 민감한 정보 전송에 확인을 요구하는 방식을 설명합니다.

통과 조건: 승인 전후의 도구 인자가 같은지 다시 비교하고, 승인하지 않은 인자는 실행되지 않습니다. 승인자가 자리를 비우거나 검토 시간이 지나면 자동 실행이 아니라 보류로 끝냅니다.

7단계: 로그를 남기고 공격 사례로 다시 테스트한다

최종 답변만 저장하면 왜 그런 판단을 했는지 알 수 없습니다. 요청 ID, 사용자 목표, 외부 출처, 감지된 지시문, 선택한 도구, 인자 해시, 승인자, 결과, 보류·차단 사유를 남깁니다. Google Cloud Model Armor 문서도 입력과 출력을 별도 정책으로 검사하고 관찰 모드에서 로그를 확인한 뒤 차단 수준을 조정하는 흐름을 설명합니다.

통과 조건: 테스트 문서에 “이전 지시 무시”, 비밀값 요구, 외부 URL 전송, 숨은 텍스트, 리디렉션 링크, 권한 확대 요구를 하나씩 넣었을 때 결과가 실행·승인·보류·차단 중 어디인지 재현됩니다. 실패한 테스트는 프롬프트 문구만 고치는 대신 도구 권한과 승인 경계를 먼저 줄입니다.

업무 유형별로 적용하는 방법

웹 검색 요약

검색 결과는 답변의 근거 후보이지 실행 명령이 아닙니다. 검색어, 선택한 원문 URL, 원문에서 확인한 주장, 아직 확인하지 못한 문장을 표로 남깁니다. “링크를 열고 로그인하라”는 결과가 나오더라도 검색 요약 업무의 목표에 포함되지 않았다면 행동으로 넘기지 않습니다.

PDF·문서 검토

파일의 본문과 메타데이터, 숨은 텍스트, 링크를 나눠 읽습니다. 문서가 계약·정책·매뉴얼이라도 최신 버전과 적용 범위를 확인하고, 문서 안의 명령형 문장은 별도 경고 필드로 보냅니다. 문서에서 추출한 수신자나 업로드 주소는 자동 메일 발송이나 파일 공유의 인자로 사용하지 않습니다.

메일·CRM·스프레드시트 연결

읽기와 변경을 서로 다른 도구로 만들고, 변경 도구는 초안 또는 승인 대기로 시작합니다. 메일을 읽다가 발견한 “회신해 달라”는 문장은 사용자의 새 요청으로 간주하지 않습니다. CRM 상태 변경은 대상 레코드, 이전 값, 새 값, 근거 출처를 사람이 확인한 뒤 실행합니다. 개발 업무라면 AI 코드 생성·개발 도구 가이드의 변경 검토 흐름과 결합해 커밋·배포를 별도 승인으로 둡니다.

팀에서 바로 쓰는 15분 점검표

새 도구를 연결하기 전 아래 질문에 모두 답할 수 있으면 자동화 범위를 검토할 수 있습니다. 답하지 못하는 항목이 있으면 모델을 바꾸기보다 해당 행동을 읽기 전용이나 보류로 낮추는 것이 먼저입니다.

1. 이번 작업의 사용자 목표와 금지 행동을 한 줄로 썼는가?
2. 외부 문서·검색 결과·메일의 출처와 수집 시각을 저장하는가?
3. 외부 문장의 지시를 데이터 추출과 실행 큐에서 분리하는가?
4. 링크의 최종 목적지와 URL에 포함될 전달값을 확인하는가?
5. 읽기·초안·전송·삭제 권한이 서로 분리되어 있는가?
6. 사람 승인 화면에 실제 도구 인자와 공유 정보가 보이는가?
7. 승인 전후 인자 비교, 보류, 차단, 복구 경로가 로그에 남는가?

이 점검표는 AI 자연어처리·LLM 응용 가이드처럼 모델 활용 사례를 설명하는 글과도 구분됩니다. 모델의 성능이나 이름을 비교하는 것보다, 실제 업무에서 어떤 자료를 읽고 어떤 행동을 허용하는지 결정하는 문서가 먼저입니다.

자주 묻는 질문

프롬프트 인젝션 문구를 필터링하면 충분한가요?

충분하지 않습니다. 공격 문구는 사람에게 자연스러운 요청이나 사회공학적 설명으로 바뀔 수 있고, 정상 문서와 섞일 수 있습니다. 탐지 결과는 보조 신호로 쓰고, 최소 권한·출처 경계·행동 승인·로그로 실패 시 영향을 제한해야 합니다.

RAG나 검색을 쓰면 외부 지시가 안전해지나요?

검색과 RAG는 필요한 근거를 가져오는 방법이지, 가져온 텍스트에 권한을 부여하는 방법이 아닙니다. OWASP가 설명하듯 외부 콘텐츠를 문맥에 넣는 순간 간접 인젝션 경계가 생깁니다. 검색된 자료는 출처가 있는 데이터로 인용하고, 도구 호출은 별도의 정책 검사를 거치게 하세요.

사람 승인만 있으면 자동화해도 되나요?

승인자는 실제 내용과 대상을 볼 수 있어야 하고, 승인 전후 인자가 변하지 않아야 합니다. 승인 화면이 요약만 보여 주거나, 승인 뒤에 다른 URL과 인자를 실행하면 승인 자체가 안전장치가 되지 않습니다. 파괴적 행동은 구조적으로 차단하거나 복구 가능한 초안 단계로 낮추는 것이 더 안전합니다.

마무리: 모델보다 경계를 먼저 설계한다

AI 에이전트 프롬프트 인젝션 방어의 핵심은 완벽한 탐지 문구를 찾는 데 있지 않습니다. 외부 문서를 데이터로 한정하고, URL과 도구 인자를 따로 확인하며, 위험한 행동에 사람 승인과 회수 경로를 붙이고, 결과를 다시 테스트할 수 있는 로그를 만드는 일입니다. 이 경계가 준비된 뒤에야 자동화 범위를 조금씩 넓힐 수 있습니다.

이 글은 공개된 공식 자료와 ai.tasko.kr의 현재 제목·본문 corpus를 비교해 작성했습니다. 특정 모델·클라우드·보안 제품이 모든 공격을 막는다고 주장하지 않으며, 서비스별 권한 설정과 조직의 개인정보·보안 정책은 별도로 확인해야 합니다.

출처

• OWASP GenAI Security Project — LLM01:2025 Prompt Injection
• OpenAI — Understanding prompt injections
• OpenAI — Designing AI agents to resist prompt injection
• OpenAI — Keeping your data safe when an AI agent clicks a link
• Google Cloud — Model Armor overview
• NIST — Generative AI Profile
• Google Search Central — Creating helpful, reliable, people-first content