대형 언어 모델(LLM) 환경 애플리케이션 권한 최소화 및 보안 아키텍처

1. 주제 정의

대형 언어 모델(LLM) 기반 애플리케이션은 단순 대화형 챗봇을 넘어 내부 데이터 검색, 자동화 에이전트, 외부 API 연동 등 점차 업무 핵심 도구로 확산되고 있습니다. 그러나 LLM은 예측 불가능성, 프롬프트 조작(prompt injection), 자동화 속도로 인해 인간 사용자보다 훨씬 높은 보안 리스크를 가집니다.

 

따라서 LLM 권한 최소화 및 통제 관리란,

• LLM이 처리하는 모든 요청에서
• 사용자 권한 ∩ LLM 권한 ∩ 태스크 권한의 교집합만 허용하는 실효 권한(effective permissions) 모델을 기반으로
• 리소스 단위까지 권한을 제어하고,
• 인증/인가 체계(OAuth 등)의 한계를 보완하는 보안 아키텍처를 설계하는 것
  을 의미합니다.

2. 주요 원칙

2.1 최소 권한 원칙 (Least Privilege)

• LLM은 반드시 필요한 권한만 보유해야 하며, 광범위 권한은 위험 요소.
• 인간 사용자에게 허용되는 “관행적 과다 권한”조차 LLM에는 적용 불가.

2.2 실효 권한 모델 (Effective Permissions)

• 권한 = 사용자 권한 ∩ LLM 권한 ∩ 태스크 권한
• 교집합 내에서만 실행 허용
• 직관적으로는 Venn 다이어그램으로 표현 가능

2.3 리소스 레벨 제어 (Resource-Level Control)

• 단순 API 호출 허용 여부가 아닌,
  → 파일·레코드·리포트·브랜치 같은 개별 리소스 단위로 접근 여부 검증 필요.

2.4 애플리케이션 계층에서 권한 검증

• OAuth 등 인증 체계는 “누가 요청했는가” 수준까지만 제공
• 실제 리소스 권한 로직은 반드시 애플리케이션 내부에서 직접 구현해야 함

3. 영역별 상세 관리

3.1 RAG (Retrieval-Augmented Generation)

(1) 1st Party 데이터

• 예시: 사내 소스코드 검색 챗봇
• 구조
  • 소스코드 파일 → 임베딩 DB 저장
  • 프롬프트 → 임베딩 매칭 → 유사 문서 반환
• 권한 관리 포인트
  • 반환된 문서 → 실제 소유 조직/폴더/리포지토리 기반 권한 체크
  • 사용자 접근 가능 여부 확인 후만 제공
  • 임베딩 자체에는 권한 로직 없음 → 애플리케이션 계층에서 필수적으로 보강

300x250

(2) 3rd Party 데이터

• 예시: 외부 위키, Jira 티켓 데이터 활용
• 문제점: 데이터 원본과 임베딩이 분리되어 있어 권한 검증 위치가 모호
• 세 가지 처리 방식
  1. 권한 위임: 외부 API 호출 시 매번 권한 확인 → 성능 저하
  2. ACL 동기화: 외부 ACL을 내부에 복사 → 정확하나 관리 비용 증가
  3. 권한 로직 재구현: 내부에서 외부 권한 검증 구현 → 유지보수 복잡
• Trade-off 고려: 성능, 운영 비용, 정밀성의 균형 필요

3.2 Agent & Tool 호출

• 예시: 챗봇이 GitHub 리포지토리 브랜치 삭제, Jira 이슈 자동 닫기
• 구조
  • LLM → MCP(Model Context Protocol) 기반 Tool 호출
• 관리 포인트
  • 툴 호출 시마다 실효 권한 모델 적용
  • LLM이 제안한 Action은 반드시 사용자·LLM·태스크 권한 교집합 내인지 확인

3.3 OAuth 인증의 한계

• 가능: 사용자 신원 인증, 기본 범위(scope) 확인
• 한계: 리소스 단위 권한 제어 불가
• 실무 대응
  • 토큰에는 최소 정보만 포함
  • 세밀한 접근 제어는 애플리케이션 권한 로직에서 수행

4. 예시 / 사례

사례 1: 사내 문서 검색 챗봇

• 사용자: 마케팅팀 직원
• 요청: “2024년 광고 예산 파일 보여줘”
• 동작
  • 프롬프트 → 임베딩 매칭 → 관련 파일 후보 반환
  • 애플리케이션 계층에서: 해당 파일이 마케팅팀 리포지토리에 있고, 사용자가 접근 권한 있는지 확인
  • 접근 불가 시 “권한 부족” 응답 반환

사례 2: AI Agent의 자동화

• 사용자: 개발팀 엔지니어
• 요청: “release/1.2 브랜치 삭제해줘”
• 동작
  • LLM이 MCP 통해 delete_branch 툴 호출
  • 애플리케이션 계층 권한 검사:
    • LLM은 삭제 권한 없음
    • 사용자도 release/* 브랜치 삭제 권한 없음
    • → 교집합 권한 없음 → 요청 거부

사례 3: 외부 시스템 연동

• 요청: “내가 만든 Jira 티켓 닫아줘”
• 처리
  • 옵션 A: LLM이 Jira API 직접 호출 → Jira 권한 검사 수행(느림)
  • 옵션 B: ACL 동기화 → 내부 권한 DB와 비교 후 처리(정확하지만 관리 부담)
  • 옵션 C: 권한 로직 재구현 → Jira 권한 모델을 애플리케이션 내 구현(복잡)

5. 종합 결론

1. LLM은 인간보다 더 엄격한 최소 권한 모델을 적용해야 함
2. 실효 권한 모델(사용자 ∩ LLM ∩ 태스크)은 LLM 보안 아키텍처의 핵심
3. 리소스 단위 제어는 반드시 애플리케이션 계층에서 구현 필요
4. RAG·Agent·3rd Party 연동 등 활용 환경마다 권한 적용 위치/방식이 달라지므로, trade-off 분석을 통해 최적 설계 필요

6. 보안 체크리스트 (가이드라인)

✅ LLM이 보유한 권한은 최소한인가?
✅ 사용자 권한과 LLM 권한이 교차하는지 검증하고 있는가?
✅ 태스크 단위로 필요한 권한만 허용하는가?
✅ RAG 환경에서 리소스별 권한 검증이 애플리케이션 계층에 구현되어 있는가?
✅ Agent/Tool 호출 시마다 권한 교집합 검증이 수행되는가?
✅ OAuth 토큰만 믿지 않고, 세밀한 권한 로직을 자체 구현했는가?
✅ 외부 시스템 연동 시, 권한 위임·ACL 동기화·재구현 중 어떤 방식을 선택했는가?
✅ Prompt Injection 등 권한 우회 공격에 대한 방어가 준비되어 있는가?

 

👉 결론적으로, LLM 권한 관리의 본질은 “교집합 제한”과 “애플리케이션 계층 권한 검증”입니다.
LLM 보안을 강화하려면 사람보다 더 엄격한 최소 권한 모델을 적용해야 합니다.