프롬프트 인젝션 방어: 에이전트형 AI 가드레일 7단 설계

프롬프트 인젝션은 “말장난”이 아니라 ‘권한 탈취’ 문제다

에이전트형 AI(도구 실행, 파일 접근, 메일 발송, 업무 시스템 연동)는 단순 챗봇과 다릅니다.

한 번 속으면 “틀린 답변”이 아니라 내 권한으로 실제 행동이 일어납니다.

OWASP는 2025 LLM Top 10에서 Prompt Injection을 최상위 리스크로 둡니다. OWASP Top 10 for LLM Applications 2025 (PDF)

이 글의 목표: 읽고 나서 ‘내 에이전트’를 바로 더 안전하게 만들기

  • 프롬프트 인젝션이 실제로 터지는 구조(직접/간접/2차)를 한 번에 정리
  • 바로 적용 가능한 7단 가드레일을 “설계 규칙”으로 제시
  • 마지막에 내 서비스가 지금 어디가 가장 위험한지 2분 진단표 제공

먼저 용어를 30초로 끝내자

종류 한 줄 정의 왜 위험한가
직접 인젝션 사용자가 “규칙 무시하고 X 해”라고 노골적으로 주입 대부분 필터링/정책으로 어느 정도 막힘
간접 인젝션 AI가 읽는 외부 데이터(웹/문서/이슈/메일)에 악성 지시를 숨김 AI는 그걸 “데이터”가 아니라 “명령”처럼 해석할 수 있음
2차(Second-order) 낮은 권한 에이전트가 높은 권한 에이전트를 속여 대신 실행 권한 분리가 안 되어 있으면 ‘팀킬’처럼 뚫림

핵심 원칙: “모델을 믿지 말고, 도구를 믿게 만들어라”

보안에서 중요한 건 “모델이 착하게 행동한다”가 아닙니다.

모델이 어떤 말을 하든, 시스템이 위험 행동을 못 하게 해야 합니다.

따라하기: 에이전트형 AI를 지키는 7단 가드레일

가드레일 1: 도구 호출은 ‘자연어’가 아니라 ‘스키마’로만

도구 실행(메일 발송/파일 삭제/결제/배포)은 자연어로 직접 연결하지 마세요.

모델은 JSON 스키마(타입/필수 필드/허용 값)를 채우기만 하게 하고, 실행은 코드가 합니다.

스키마 검증에서 걸리면 실행이 멈춥니다. 여기서 사고의 60%가 사라집니다.

가드레일 2: “허용 목록(allowlist)” 없이는 아무것도 실행하지 않기

도구/명령/경로/도메인은 기본이 ‘차단’입니다.

예: 파일은 특정 폴더만, 네트워크는 특정 도메인만, 명령은 특정 서브커맨드만.

에이전트가 강해질수록, allowlist의 가치가 더 커집니다.

가드레일 3: 실행 전 ‘의도 확인’은 사람에게, ‘안전 확인’은 시스템에게

사람 승인(Human-in-the-loop)은 만능이 아닙니다.

사람은 바쁘면 대충 “OK”를 누릅니다.

그래서 승인 전에 시스템이 먼저 안전 검증 질문을 강제해야 합니다.

  • 이 작업은 되돌릴 수 있나
  • 민감 데이터가 포함되나
  • 권한 범위를 넘어가나
가드레일 4: RAG/외부 문서는 “데이터”로만 취급하고 “명령”으로 취급하지 않기

간접 인젝션의 핵심은 “문서 안의 문장”이 명령으로 승격되는 순간입니다.

해결은 단순합니다. 외부 문서에서 온 텍스트는 절대 실행 지시로 해석하지 않는다를 시스템 규칙으로 박아야 합니다.

MCP 간접 인젝션 방어 가이드도 이 방향(간접 지시 무력화, 권한 최소화)을 강조합니다. Microsoft: Protecting against indirect prompt injection attacks in MCP

가드레일 5: 샌드박스와 롤백이 없는 자동화는 금지

파일 편집, 코드 변경, 설정 수정은 무조건 샌드박스에서 먼저.

그리고 실행 전에 롤백 루틴(커밋/스냅샷/백업)을 자동으로 만듭니다.

“복구 가능성”이 곧 안전입니다.

가드레일 6: 권한을 ‘기능’이 아니라 ‘업무’ 기준으로 쪼개기

2차 인젝션은 “에이전트끼리 믿는 구조”에서 터집니다.

해결은 권한을 기능 단위가 아니라 업무 단위로 쪼개는 겁니다.

  • 요약 에이전트: 읽기 전용
  • 작성 에이전트: 초안만, 발송 불가
  • 실행 에이전트: 좁은 범위의 도구만, 항상 승인 필요
가드레일 7: 감사 로그를 “나중에 보기”가 아니라 “실시간 알림”으로

사고는 로그가 없어서가 아니라, 로그를 나중에 봐서 터집니다.

도구 실행 요청이 발생하면 “누가/무엇을/왜/어디에”를 즉시 남기고 알림을 보내세요.

이 한 줄이 내부 사고를 외부 사고로 번지기 전에 끊습니다.

시각 앵커: 2분 위험 진단표

질문 YES면 지금 위험한 이유 오늘 할 1가지
에이전트가 자연어로 바로 도구를 실행한다 문장 하나가 곧 실행이 됨 도구 호출 스키마화
allowlist 없이 파일/명령/도메인이 열린다 폭발 반경이 무한대 폴더/도메인/명령 allowlist
외부 문서(RAG) 내용을 지시처럼 따른다 간접 인젝션 정면 수용 외부 텍스트는 ‘데이터 전용’ 규칙
승인만 있고 안전검증이 없다 사람은 대충 OK를 누름 안전 질문 3개 강제
실행이 샌드박스 없이 바로 프로덕션에서 돈다 복구 비용이 치명적 샌드박스+롤백 자동화
에이전트가 하나로 모든 권한을 가진다 2차 인젝션에 취약 업무 기준 권한 분리
감사 로그가 있지만 알림은 없다 사고를 나중에 발견 도구 실행 실시간 알림

몰트봇/로컬 에이전트를 쓰는 사람이라면

로컬 에이전트는 “내 기기에서 돌아서 안전”이 아니라, 내 기기라서 더 위험할 수 있는 구조입니다.

이미 몰트봇을 쓰고 있다면, 먼저 아래 글에서 ‘폭발 반경’ 관점으로 위험 지점을 체크해두는 게 좋습니다.

결론: 프롬프트 인젝션은 ‘모델 문제’가 아니라 ‘시스템 설계 문제’다

모델은 언제든 속을 수 있습니다.

하지만 스키마 + allowlist + 권한 분리 + 샌드박스 + 실시간 감시를 깔면 “속아도 사고가 안 나는” 구조가 됩니다.

이 글을 읽고 오늘 한 가지만 한다면, allowlist부터 시작하세요.