에이전트 프롬프트 인젝션 방어

세 줄 요약

핵심 이슈: 노트/웹/문서/이메일 같은 외부 콘텐츠에 숨은 지시가 에이전트 입력으로 섞이면서, 지시 탈취·데이터 유출·정책 우회(일명 jailbreak)로 이어질 수 있다.
왜 중요: 툴콜(브라우징·파일·네트워크)이 붙으면 위험은 “프롬프트 문구”가 아니라 권한(least privilege)·격리(샌드박스)·구조화 출력과 검증(output validation) 설계에서 커진다.
무엇을 할까: 비신뢰 입력 격리 → 툴콜 스키마 고정 → 실행 전 검증/승인 레이어의 3단 규칙을 제품 전 경로에 강제하고, 사용자 확인이 필요한 예외를 명시한다.

노트 앱에 문서 1개를 붙여넣고 요약 버튼을 누르는 순간, “이 내용을 다른 곳으로 전송하라” 같은 문장이 끼어들어 에이전트를 흔들 수 있다. 사용자는 요약을 원하지만, 시스템은 외부 콘텐츠에 숨은 지시까지 같은 입력으로 처리할 수 있다. 프롬프트 인젝션은 여기서 시작한다. 툴콜(브라우징·파일·네트워크)이 연결되면 문제는 ‘프롬프트 잘 쓰기’만으로 끝나지 않는다. 권한과 경계 설계가 직접적인 위험 요인이 된다.

예: 사용자가 붙여넣은 문서 안에 외부로 공유하라는 문장이 숨어 있고, 에이전트가 이를 지시로 오해해 전송 도구를 찾는 상황을 떠올려 보자. 사용자는 요약만 원했지만, 시스템은 문서의 문장을 실행 계획으로 취급한다.

이 글은 현실에서 반복되는 프롬프트 인젝션/데이터 유출 패턴을 정리하고, 제품·에이전트 레벨에서 적용할 수 있는 방어 체크리스트를 제시한다. 핵심은 “모델이 속아서”라기보다, 신뢰할 수 없는 입력이 권한 있는 실행 경로로 흘러가는 설계가 사고를 만든다는 점이다.

현황

웹페이지·문서·이메일 같은 외부 콘텐츠가 에이전트 입력으로 들어오면서, 간접 인젝션(외부 콘텐츠 안에 지시를 숨겨 유도하는 방식)의 영향 범위가 커진다. OpenAI는 인젝션이 에이전트의 행동을 공격자 의도로 “override or redirect”하도록 만들 수 있다고 설명한다. 즉, 사용자 요청을 무시하게 하거나, 다른 행동(예: 정보 전달)을 하게 만드는 형태다. 공격 경로는 채팅 입력에만 국한되지 않는다.

실무 관점에서 공격 유형은 다음 3가지로 묶어 볼 수 있다. 다만 이 3분류가 “공식 표준 택소노미”인지 여부는 별도 확인이 필요하다.
첫째, 지시 탈취/컨텍스트 하이재킹: 기존 시스템 지시나 가드레일을 무시하게 만든다.
둘째, 데이터 유출: 민감정보를 노출하거나 외부로 보내게 유도한다.
셋째, 정책 우회: 금지된 행동을 하도록 jailbreak 방향으로 몰아간다.

방어 가이드는 “프롬프트를 더 단단히”에서 “데이터 흐름을 더 단단히”로 이동하고 있다. OpenAI의 에이전트 빌더 안전 가이드는 비신뢰 입력을 사용자 메시지로 통과시켜 영향력을 제한하고, 노드 간에 구조화된 출력(예: enums, fixed schemas, required field names) 을 두어 데이터 흐름을 제약하라고 권한다. Anthropic은 에이전트형 코딩 환경에서 접근 권한이 커질수록 인젝션 위험이 커질 수 있다고 보고, filesystem과 network isolation 같은 샌드박싱 경계를 강조한다.

분석

프롬프트 인젝션을 “모델이 속는다”로만 해석하면, 대응이 프롬프트 문구 수준에 머물 수 있다. 하지만 실제 리스크는 경계 붕괴에 가깝다. 비신뢰 입력(웹·문서·RAG 결과)이 고권한 실행 경로(툴 실행, 파일 읽기, 네트워크 요청) 로 그대로 이어지면, 공격자는 텍스트 조작만으로 실행을 유도할 수 있다. 그래서 업계 권고가 구조화 출력과 검증, 샌드박스, 최소권한으로 모이는 흐름이 있다.

연구도 유사한 방향을 제시한다. AgenTRIM은 런타임에 단계별로 per-step least-privilege tool access를 강제하고, 상태 인지(status-aware) 검증으로 툴콜을 필터링하는 방향을 제안한다. RTBAS는 무결성과 기밀성을 보존하는 툴콜만 실행하고, 보장할 수 없을 때만 사용자 확인을 요구하는 접근을 제안한다. 정리하면, “에이전트가 스스로 잘하길 기대”하기보다 정책·검증 레이어가 실행을 통제하는 구성이 거론된다.

한계도 있다. 구조화 출력과 검증을 강하게 적용하면, 에이전트의 유연성이 줄고 개발 비용이 증가할 수 있다. 샌드박스는 운영 복잡도를 키운다(권한, 로그, 예외 처리, 디버깅). 또 “어디까지를 비신뢰로 볼 것인가”는 제품 성격에 따라 의견이 갈린다. 예를 들어 내부 문서라도 편집 권한이 넓으면 공격자가 지시를 심을 수 있다. 결국 방어는 기술뿐 아니라 위협 모델링과 운영 정책까지 포함한다.

실전 적용

실무에서 위험이 커지는 순간은 “텍스트를 텍스트로만 보지 않을 때”다. 모델의 응답이 다음 단계에서 툴 파라미터가 되고, 그 파라미터가 네트워크 요청이 되며, 그 결과가 다시 프롬프트로 들어간다. 이 체인은 생산성을 올릴 수 있지만, 한 고리라도 검증이 없으면 인젝션이 곧 실행으로 이어질 수 있다. 그래서 방어는 1) 입력 라벨링, 2) 권한 축소, 3) 출력/툴콜 검증의 조합으로 설계하는 편이 일관된다.

예: 에이전트가 문서를 읽고 “필요한 정보를 정리해 외부로 공유”하라는 숨은 문장을 발견했을 때, 시스템이 그 문장을 비신뢰 지시로 분류하고, 외부 전송 툴은 기본적으로 차단하며, 필요 시 사용자 확인으로만 열리게 만들면 피해 가능성을 줄일 수 있다.

오늘 바로 할 일:

비신뢰 입력(웹/문서/RAG/이메일)을 별도로 라벨링하고, 그 내용이 시스템 지시나 툴 실행 조건을 재정의하지 못하도록 경계를 분리한다.
에이전트가 호출하는 모든 툴에 최소권한(least privilege)을 적용하고, 단계별로 허용 범위를 줄이는 런타임 정책을 도입한다.
자유형 텍스트를 툴 파라미터로 바로 넘기지 말고, 구조화 출력(고정 스키마)과 결정론적 검증(output validation)을 통과한 경우에만 실행한다.

FAQ

Q1. 프롬프트 인젝션은 ‘jailbreak’랑 같은 말인가?
A. 겹치는 부분이 있지만 동일어로 단정하기는 어렵다. 이 글의 정리 기준으로는 프롬프트 인젝션이 더 넓은 개념이고, 그 결과로 정책 우회(금지된 행동 수행 유도) 가 나타날 수 있다. 또한 인젝션은 데이터 유출이나 지시 탈취처럼 “안전 정책”과 직접 관련이 없는 목표로도 사용될 수 있다.

Q2. “프롬프트에 ‘외부 지시를 무시해’라고 쓰면” 충분하지 않나?
A. 단독으로는 부족할 수 있다. OpenAI 가이드가 구조화 출력과 데이터 흐름 제약을 강조하는 이유가 여기에 있다. 텍스트 수준의 가드는 우회될 수 있고, 특히 툴콜이 붙으면 피해가 실행으로 이어질 수 있다. 방어의 중심은 프롬프트 문구보다 검증 가능한 경계(권한·검증·격리) 다.

Q3. 에이전트에 파일·네트워크 접근이 꼭 필요하다. 그럼 답이 없나?
A. 접근을 없애기보다, 경계를 쪼개는 방식이 자주 논의된다. Anthropic이 언급한 것처럼 샌드박스는 filesystem과 network isolation 같은 분리 경계를 제공한다. 여기에 단계별 최소권한과 툴콜 검증을 결합하면, “접근은 하되 통제된 방식으로” 운영하는 선택지가 생긴다.

결론

프롬프트 인젝션은 대화 UI만의 문제가 아니라, 입력 경계와 권한 경계가 약한 에이전트 설계에서 커진다. 웹/문서/RAG가 붙고 툴이 실행되는 제품이라면, 프롬프트를 다듬는 작업과 함께 구조화 출력, 최소권한, 샌드박스, 정책/검증 레이어에 대한 투자가 필요하다. 다음 단계는 “비신뢰 입력이 어떤 경로로 실행까지 도달하는지”를 제품 전체 플로우에서 추적하고, 그 경로마다 차단·승인·사용자 확인 규칙을 설계에 반영하는 것이다.

Aionda

에이전트 프롬프트 인젝션 방어

세 줄 요약

현황

분석

실전 적용

FAQ

결론

다음으로 읽기

참고 자료

업데이트 받기