LLM AI 보안 및 거버넌스 체크리스트 20항목 (2026): 프롬프트 인젝션·RAG·권한

LLM·AI 보안 및 거버넌스 체크리스트는 누가 어떤 데이터와 도구를 사용할 수 있는지, 출시 전에 무엇을 시험하고 실패 시 누가 멈출지까지 정해야 실행할 수 있습니다. 프롬프트 필터 설치 여부만으로 통과 판정을 내리지 마세요.

아래는 RAG와 외부 도구를 사용하는 기업용 LLM 에이전트의 출시 검토 예시입니다. 특정 인증의 합격표나 모든 산업에 공통인 법정 기준은 아닙니다. 조직의 데이터·업무 위험도에 맞춰 책임자와 승인 기준을 정합니다.

LLM AI 보안 및 거버넌스 체크리스트 20항목

각 행을 통과·보완·해당 없음으로 기록하고 근거 링크를 남깁니다. 예외를 허용했다면 승인자와 재검토 시점까지 적습니다. NIST AI RMF 1.0의 4개 기능(GOVERN·MAP·MEASURE·MANAGE) 열은 편집팀이 붙인 대응 예시이며, 이 표는 공식 프레임워크의 원문 표나 인증 합격표가 아닙니다. NIST AI RMF

프롬프트 인젝션은 정규식만으로 막을 수 없습니다

직접 입력 외에도 검색 문서나 웹페이지에 숨은 지시가 모델의 행동에 영향을 줄 수 있습니다. ignore system prompt 같은 특정 영어 표현을 차단해도 다른 언어·표현·외부 문서 경로가 남습니다. OWASP는 완전한 차단을 보장하는 방식보다 최소 권한, 출력 검증, 외부 콘텐츠 구분, 민감 작업 통제 등 여러 방어를 함께 설명합니다. OWASP Prompt Injection

따라서 보안 테스트는 “모델이 지시를 거절했는가”와 함께 실제로 데이터가 노출되거나 도구가 실행됐는가를 봐야 합니다. 모델이 부적절한 도구 호출을 제안해도 서버 인가 단계가 차단하는지 검증하세요.

도구 실행과 사용자 권한을 연결하기

예를 들어 고객지원 에이전트가 ticket.read를 제안했다고 가정합니다. 서버는 인증된 사용자의 조직·역할과 요청한 티켓 소유 조직을 대조해야 합니다. 모델이 출력한 tenant_id나 “관리자가 승인했다”는 문장을 신뢰해서 권한을 부여하면 안 됩니다.

실행 흐름은 다음처럼 구성할 수 있습니다.

1. 서버 세션에서 사용자와 테넌트 확인
2. 도구 이름·인자를 허용된 스키마로 검증
3. 대상 리소스에 대한 서버 인가 수행
4. 정책상 필요한 작업 승인 확인
5. 실행 한도·중복 방지 검사 후 도구 호출
6. 결과와 인가 판단을 최소한의 감사 정보로 기록

이는 설계 예시입니다. 실제 접근 제어 코드는 각 서비스의 인증·권한 저장소와 연결되어야 합니다. 구현 관점은 LLM 에이전트 보안 설계 가이드에서 이어서 확인할 수 있습니다.

RAG 검색과 감사 로그 점검

검색 필터의 테넌트·권한 조건은 서버의 인증 정보에서 만듭니다. 문서 ID와 버전을 남겨 답변 출처를 추적하되, 출처가 적혀 있다는 사실만으로 내용의 정확성이나 접근 권한을 보장하지는 않습니다. 문서 권한 변경·삭제 후 색인과 캐시에도 반영되는지 시험하세요.

감사 로그에는 요청 식별자, 모델·프롬프트 버전, 도구 이름, 인가 결과, 지연·비용 등 사고 조사에 필요한 정보를 우선 남깁니다. 원문 입력·응답을 모두 장기간 저장하는 방식은 개인정보나 비밀정보를 로그에 복제할 수 있으므로 목적·접근권한·보유기간을 먼저 정합니다.

출시 전에 실행할 테스트 예시

아래는 실제 고객정보 없이 합성 데이터로 수행할 수 있는 테스트 설계입니다. 이 글에서 특정 제품에 대한 실측 결과를 주장하는 것은 아닙니다.

정상 요청이 얼마나 차단되는지도 함께 기록합니다. “공격 문장 몇 개를 막았다”는 결과만으로 운영 적합성을 판단하지 않습니다.

NIST AI RMF를 운영 기록으로 연결하기

NIST AI RMF는 자발적으로 활용하는 위험관리 프레임워크이며 Govern·Map·Measure·Manage 기능을 제시합니다. 생성형 AI용 프로파일도 함께 참고할 수 있습니다. 아래 연결은 이 글의 적용 예시입니다. NIST AI RMF, AI RMF 핵심 기능

모델 교체뿐 아니라 새 데이터 소스, 새 도구, 권한 확대도 재검토 계기로 삼습니다. 체크리스트를 작성한 날짜보다 현재 운영 구성과 증거가 일치하는지가 중요합니다.

출시 후 권한 우회가 발견됐을 때: 원인 추적과 회귀 테스트

체크리스트를 통과하고 출시했더라도, 운영 중 "다른 사용자의 문서가 답변에 인용됐다" 같은 신고가 들어올 수 있습니다.

원인 후보

• 검색 단계에서 권한 필터를 적용하지 않고, 생성 후에 결과만 걸러냄(이미 컨텍스트에 들어간 내용이 요약으로 새어 나감)
• 인덱싱 시점의 ACL을 메타데이터로 복사해 두었는데, 원본 권한 변경이 인덱스에 반영되지 않음
• 도구 호출이 사용자 토큰이 아니라 서비스 계정 권한으로 실행됨

추적 절차

1. 신고된 답변의 요청 ID로 감사 로그에서 검색된 청크 ID 목록과 각 청크의 원본 문서 ID를 찾습니다.
2. 해당 문서의 현재 ACL과 인덱스에 저장된 ACL 메타데이터를 비교합니다.
3. 도구 호출 로그에서 실행 주체(사용자 ID 또는 서비스 계정)를 확인합니다.

해결

• 검색 쿼리 자체에 사용자 그룹 필터를 넣어, 권한 없는 청크가 컨텍스트에 들어가지 않게 합니다.
• 원본 권한 변경 이벤트를 받아 인덱스 메타데이터를 갱신하고, 주기적으로 전체 대조 작업을 돌립니다.

회귀 테스트로 고정

def test_no_cross_tenant_retrieval(retriever):
    hits = retriever.search("분기 매출 보고서", user={"id": "u-a", "groups": ["team-a"]})
    assert all("team-a" in h.metadata["allowed_groups"] for h in hits)

권한 우회 사례가 발견될 때마다 같은 형태의 테스트를 추가하고 CI에서 매 배포 전에 실행합니다.