프롬프트 인젝션은 단순히 모델이 이상한 답을 하는 문제가 아니다. 에이전트가 내부 데이터에 접근하고 외부 네트워크나 도구를 호출할 수 있으면, 악성 지시가 여러 홉을 거쳐 데이터 유출 경로가 된다.
3홉 공격 모델
외부 콘텐츠의 악성 지시
-> 에이전트가 내부 도구로 민감 데이터 조회
-> 조회 결과를 외부 호출, 댓글, 로그, webhook 등으로 전송O’Reilly 글의 핵심은 Kubernetes NetworkPolicy 같은 네트워크 제어만으로는 충분하지 않다는 점이다. 네트워크는 패킷을 보지만, “이 문자열이 민감한 고객 데이터이며 악성 지시 때문에 외부로 나간다”는 의미를 모른다.
방어 원칙
| 계층 | 방어 |
|---|---|
| 입력 | 외부 문서와 사용자 지시를 신뢰 수준별로 분리 |
| 도구 | 민감 데이터 조회 도구와 외부 전송 도구를 같은 에이전트 권한에 묶지 않음 |
| 정책 | tool call마다 목적, 데이터 분류, 대상 도메인을 검사 |
| 출력 | 외부 채널로 나가는 텍스트에 DLP와 allowlist 적용 |
| 감사 | trace에 어떤 입력이 어떤 도구 호출을 유발했는지 남김 |
실무 체크리스트
- 외부 웹페이지, 이메일, issue 본문을 system instruction과 같은 채널로 넣지 않는다.
- read tool과 write/exfiltration-capable tool을 분리하고, 결합이 필요하면 승인 단계를 둔다.
- MCP 서버는 “편의 도구”가 아니라 권한 경계로 설계한다.
- 민감 데이터가 포함된 tool result는 모델에 그대로 넘기기 전에 최소화한다.
- 에이전트가 생성한 외부 요청은 URL, body, 첨부를 정책 엔진에서 검사한다.
관련 문서
- gitlost — GitHub AI 에이전트가 private repo를 유출한 프롬프트 인젝션 사례
- prompt-injection-role-confusion — 프롬프트 인젝션을 역할 혼동으로 설명하는 연구
- zero-trust-ai-agents — 자율 AI 에이전트를 위한 엔터프라이즈 보안 프레임워크
- crabtrap — AI 에이전트 아웃바운드 HTTP를 정책으로 통제하는 보안 프록시
참고 자료
- Prompt Injection to Data Exfil in 3 Hops — O’Reilly Radar (2026-07)