엔터프라이즈 LLM 보안: 프롬프트 인젝션 및 에이전트 오남용 ‘탐지·보호’

“LLM 보안”을 일반 AppSec처럼 만들기

엔터프라이즈에서 LLM 보안을 현실적으로 운영하려면, LLM을 “특수한 AI”로 보기보다 (1) 입력-처리-출력 파이프라인을 가진 애플리케이션으로 보고,

• 예방(Prevent): 설계/권한/데이터 경계
• 탐지(Detect): 입력·출력·행위·세션 단위 탐지
• 대응(Respond): 차단·격리·증거수집·재발방지
• 검증(Validate): 레드팀/모의해킹을 CI/CD로 “상시화”

300x250

이 네 축을 계층별 통제(Defense-in-Depth)로 배치하는 게 핵심입니다. OWASP는 LLM01(프롬프트 인젝션)을 최상단 리스크로 두고, “지시(instruction)와 데이터(data)가 섞이는 구조” 자체가 취약점의 뿌리라고 정리합니다.
NIST AI 600-1(생성형 AI 프로파일)은 “라이프사이클 전 구간에서 지속 측정·관리”를 요구하는 방식으로, 조직 운영(거버넌스/모니터링/테스트)을 프레임워크로 묶어줍니다.

위협 모델링: “무엇을 막을 것인가”를 사용 패턴으로 쪼개기

LLM 사용 형태 3종과 대표 공격면

A. 단일 챗봇형(툴 없음/약함)

• 직접 인젝션/탈옥: “규칙 무시”, “시스템 지시 보여줘”
• 정책 위반 유도(브랜드/규정/금칙)
• 대화 컨텍스트 장기 누적 악용(멀티턴 조작)

B. 툴/에이전트 연동형(메일/DB/API/RPA)

• 권한 오남용: 인젝션으로 “허용 범위 밖 실행” 유도(메일 대량발송, DB 덤프 등)
• 간접 인젝션: 웹페이지/문서에 숨겨진 지시문이 모델을 조종(요약 요청했는데 “이 지시를 수행하라”)
• 툴 체인 악용(정상 호출처럼 보이는 연속 액션)

C. 사내 데이터 연동 RAG/Copilot(문서·코드·티켓)

• 내부 문서/소스/PII 유출(의도/비의도)
• 인가 경계 우회: “내 권한 밖 문서를 요약해줘”
• 검색/랭킹 조작(문서 삽입, 인덱스 오염 등)

OWASP LLM Top 10에 맵핑하는 이유

• “위협을 말로만”이 아니라 테스트 케이스·통제항목·로그 요구사항으로 곧장 내릴 수 있습니다.
• 특히 LLM01(프롬프트 인젝션)은 “직접/간접”을 모두 포함하는 형태로 정리되어 있어, 에이전트/멀티모달까지 확장되는 공통 축으로 쓰기 좋습니다.

다계층 탐지·분석 아키텍처: 입력/출력/행위/세션을 분리해서 본다

핵심은 “한 지점에서 완벽 차단”이 아니라
(A) 입력(Pre) → (B) 실행(툴/검색) → (C) 출력(Post) → (D) 행위/세션 분석을 각각 따로 잡는 겁니다.

OWASP 치트시트도 입력 검증/구조화 프롬프트/후처리/휴먼 승인 등 여러 방식을 조합하라고 권고합니다.

입력 측(Pre) 탐지/방어: “프롬프트를 악성 페이로드로 본다”

(1) 룰 기반(정적) — 빠르고 설명 가능

• 대표 패턴(영/한 혼합 포함)
  • “이전 지시 무시”, “시스템 프롬프트”, “개발자 모드”, “정책 우회”
• 난독화 대응
  • 공백/특수문자 삽입(i g n o r e), base64/URL-encoding, 혼합 언어

운영 팁

• 룰은 “차단”만이 아니라 점수화(score)에 사용하세요.
• “차단 룰”은 최소화하고, 대부분은 고위험 세션으로 태깅 후 다음 계층(행위/툴 게이트)에서 걸러야 오탐 폭발을 줄입니다.

(2) 분류기(ML/LLM-as-judge) — 멀티턴/변형에 강함

• 라벨 예: normal / jailbreak / injection / data_request / tool_abuse / policy_evasion
• 결과: risk_score(0~1) + 근거(feature) + 라벨

OWASP는 고위험 케이스에 대해 “사람 승인(HITL) 또는 추가 검증”을 넣는 것을 현실적 선택지로 봅니다.

(3) 구조화 프롬프트(프롬프트 ‘구획’ 유지)

OWASP 권장 축은 “지시와 데이터를 분리”하는 겁니다.

예시(개념 템플릿)

• System: 정책/목표/금지/우선순위
• Developer: 업무 규칙, 출력 포맷(엄격)
• User: 사용자 질문(비신뢰)
• Untrusted Content: 웹/문서/메일 본문(절대 지시로 취급 금지)

출력 측(Post) 탐지/방어: “반드시 후처리 필터를 둔다”

입력만 막으면 간접 인젝션·멀티턴·모델 편향으로 새는 경우가 많습니다. 그래서 “출력 후처리(post-filter)”는 사실상 필수 계층입니다.

(1) 정책 위반/금칙 콘텐츠 분류

• 조직 정책(준법/인사/브랜드/규제)을 라벨로 분류 → 차단/수정/경고

(2) 민감정보(DLP) 탐지/마스킹

• 정규식(주민번호/카드/계좌/이메일/사번)
• 내부 식별자(프로젝트 코드네임, 내부 도메인, 저장소 경로, 티켓 키 패턴)
• “부분 마스킹 + 사유 코드”를 남겨야 포렌식/튜닝이 됩니다.

(3) 시스템/개발자 프롬프트 노출 징후 탐지

• “내 시스템 지시는…”, “정책 전문은…” 같은 문장 패턴
• 고위험: 즉시 세션 차단 + 프롬프트/컨텍스트 스냅샷 보관

에이전트/툴 연동형 “행위 기반 탐지”: 여기서 승부가 납니다

OWASP도 에이전트는 “프롬프트 인젝션을 넘어서는 고유 리스크”가 있다고 따로 치트시트로 다룹니다.

핵심 개념: “툴 호출은 ‘권한 행사’다”

따라서 탐지/통제는 프롬프트 텍스트가 아니라 실제 실행되는 액션(툴 호출)을 1차 데이터로 삼아야 합니다.

• 비정상 데이터 접근
  • 대량 조회, 와일드카드/전체 테이블, 시간대/빈도 급변
• 비정상 API 시퀀스
  • 평소: search → summarize
  • 이상: search → export → email.send → drive.upload 같은 “데이터 반출 체인”
• 비정상 메일/파일 작업
  • 수신자 급증, 외부 도메인 비율 증가, 첨부/링크 삽입 증가

운영 지표(예시)

• MTTD(탐지) / MTTR(자동차단) / FPR(오탐률) / TPR(탐지율)
• “에이전트 툴 호출 차단률”, “HITL 큐 적체 시간” 같은 운영 KPI도 같이 봐야 합니다.
  NIST AI 600-1 관점에서도 이런 지속 측정/관리 체계가 핵심 축입니다.

로그/포렌식 설계: “나중에 보자”가 되지 않게 스키마를 먼저 정한다

최소 로그 스키마(권장)

• session_id, user_id, tenant_id, ip, device_id
• model, provider, prompt_version, policy_version
• input_text_hash, output_text_hash (원문은 암호화/접근통제)
• risk_score_pre, risk_score_post, labels[]
• rag_docs[] (문서ID, ACL결과, 스니펫 해시)
• tool_calls[] (tool_name, args_hash, allow/deny, reason_code, latency)
• egress[] (email_to_domain, upload_domain, destination, bytes)
• action (allow / block / redact / require_approval)

보안 관점 체크포인트(감사/규정 대응)

• “누가 어떤 프롬프트로 어떤 문서/툴을 호출했는지”
• “차단/마스킹 사유 코드가 남는지(설명가능성)”
• “세션 리플레이(재현)가 가능한지(해시+스냅샷)”

보호(Prevent) 설계: “프롬프트만”이 아니라 “권한/데이터/실행”을 분리

가장 중요한 원칙 5가지

OWASP 치트시트의 핵심을 엔터프라이즈 운영 언어로 바꾸면 아래 5개가 됩니다.

1. 지시와 데이터를 분리(구조화 프롬프트 + Untrusted 태깅)
2. 최소권한(Least Privilege): LLM이 직접 DB/메일 권한을 가지지 않음
3. 툴 게이트웨이(정책집행 지점): 모든 툴 호출을 “정책 엔진”이 승인/차단
4. 인가 필터가 선행된 RAG: LLM에는 “이미 ACL 통과된 결과만” 전달
5. 출력 후처리(DLP/정책필터): 유출은 마지막에서라도 잡는다

“툴 게이트웨이(Policy Enforcement)” 구현 패턴

추천 구조(개념)

• LLM ↔ (직접 DB/API 금지)
• LLM → Tool Gateway → (DB/API/메일/드라이브)
• Gateway는 다음을 수행:
  • 요청자 권한/역할/목적 검증
  • 파라미터 허용목록 검사(예: SQL 템플릿/리미트 강제)
  • 위험 점수/세션 상태 확인(고위험이면 승인필요)
  • 실행 결과도 “비신뢰 데이터”로 태깅해 모델에 반환

예: SQL 툴 호출 강제 제약(개념 예시)

• SELECT만 허용
• LIMIT 자동 삽입(예: 200)
• 금지 키워드(DROP, UNION, INTO OUTFILE, information_schema) 차단
• 테이블/컬럼 allowlist

RAG 데이터 보호(특히 내부 문서/코드)

• 검색 단계에서 ACL 필터(사용자 토큰/그룹/프로젝트 기반)
• 민감정보 토큰화/마스킹 인덱싱
• 문서 신뢰도 태그
  • 외부 크롤링/메일 본문 등은 untrusted=true로 구분해 “지시문 무시” 컨텍스트를 강제

NIST AI 600-1은 생성형 AI 위험을 “라이프사이클/운영 전반에서 관리”하도록 맵핑을 제공하는 문서이므로, RAG/데이터 파이프라인에 통제를 넣는 것이 프레임워크 취지와 맞습니다.

모의해킹·레드팀: “테스트 스위트”를 표준화하고, 자동화를 CI/CD에 붙이기

테스트 케이스를 “분류 체계”로 만든다

OWASP LLM01(프롬프트 인젝션)을 축으로, 최소한 아래 카테고리는 스위트에 고정하세요.

• 직접 인젝션: 시스템/개발자 지시 무시, 역할 탈취
• 간접 인젝션: 문서/웹/메일에 숨은 지시문
• 데이터 유출: PII/내부문서/소스코드/비밀값 유도
• 툴 오남용: 이메일 발송, 파일 업로드, DB 대량조회
• 거부/과부하: 긴 입력/반복 루프 유도(비용/지연 공격)

자동화 레드팀(Continuous Red Teaming)

요즘 실무에서 현실적인 형태는 보통 이렇습니다.

• (1) Attack Generator: 시드 프롬프트 변형/조합
• (2) Execution Engine: 대상 환경에 대량 실행
• (3) Judge/Detector: 정책 위반/유출/오남용을 점수화
• (4) 리그레션(회귀) 관리: 빌드/릴리즈마다 재실행

오픈소스/도구 기반 접근이 많이 쓰이며(예: promptfoo류), 조직 특화 시나리오는 내부 규칙으로 확장하는 방식이 흔합니다. (도구는 환경/보안정책에 따라 선택)

SOC/SIEM/SOAR 연동: “AI 보안 이벤트”를 기존 보안 운영에 넣기

SIEM 적재 시 권장 분류(인덱스/데이터셋)

• llm_prompt_events (입력/출력, 점수, 라벨)
• llm_tool_events (툴 호출, 허용/차단, 파라미터 해시)
• llm_rag_events (검색 문서ID, ACL결과)
• llm_egress_events (메일/업로드/외부 도메인 반출)

SOAR 플레이북(예시)

• High risk prompt injection 탐지
  1. 세션 즉시 종료(토큰 폐기)
  2. 동일 사용자 세션 “추가 인증” 요구
  3. 해당 프롬프트/응답/툴 호출 스냅샷 보관
  4. 룰 튜닝 티켓 생성(오탐이면 예외 처리)
• Tool abuse 탐지(메일/업로드)
  1. 실행 차단 + 보류 큐(HITL)
  2. 수신자/도메인 평판 조회
  3. 승인 로그 남기고 재개(2인 승인 권장)

실무 로드맵(현실 버전)

1단계 — “기본 가드레일” 먼저

• 구조화 프롬프트/Untrusted 태깅
• 입력/출력 점수화 + 최소 차단 룰
• 툴 게이트웨이 PoC(메일/DB 중 1개부터)

이 단계 목표는 완벽 차단이 아니라 관측 가능성 확보입니다.

2단계 — 위협 모델 기반 레드팀

• OWASP LLM01 중심 테스트 스위트 작성
• 직접/간접 인젝션 + 데이터 유출 + 툴 오남용 시나리오
• 결과를 “통제 항목”으로 환류(룰/정책/게이트)

3단계 — 레드팀 자동화 + CI/CD

• PR/릴리즈 전 자동 실행
• 회귀 탐지(“예전에 막던 게 다시 뚫림”)를 자동 리포팅

4단계 — 행동 분석 + SOAR 정착

• API/DB/메일/업로드 이벤트를 기반으로 이상행위 룰
• MTTD/MTTR KPI 운영
• 고위험 케이스는 HITL 승인 체계로 안정화

5단계 — 거버넌스(정책/표준/감사) 내재화

• NIST AI 600-1/AI RMF 요구사항을 내부 표준 체크리스트로 변환
• ISO/IEC 42001 같은 AIMS(경영시스템) 관점으로 책임/역할/개선 프로세스 연결

엔터프라이즈 보안 점검 체크리스트

A) 설계/아키텍처

• 시스템/개발자/사용자/비신뢰 컨텐츠가 구획화되어 있는가?
• LLM이 직접 데이터/메일/외부전송 권한을 가지지 않는가?
• 모든 툴 호출이 Gateway(정책집행)로 지나가는가?
• RAG 검색 단계에서 ACL 필터가 선행되는가?

B) 탐지/로깅

• 입력 점수(risk_score_pre)와 라벨이 기록되는가?
• 출력 후처리(DLP/정책필터) 결과가 기록되는가?
• 툴 호출(허용/차단/사유/파라미터 해시)이 남는가?
• 세션 단위 리플레이가 가능한가(해시/스냅샷/버전)?

C) 대응/운영

• 고위험 세션 차단/격리 플레이북이 있는가?
• HITL 승인 큐(2인 승인 포함) 운영 기준이 있는가?
• 레드팀 스위트가 정기적으로 돌고, 회귀가 추적되는가?

D) 데이터 보호

• 민감정보(PII/비밀/내부코드) 식별 규칙이 정의돼 있는가?
• 인덱싱/검색/출력 단계 중 최소 1곳 이상에서 마스킹이 되는가?
• 외부 반출(메일/업로드) 이벤트가 모니터링되는가?