LLM 애플리케이션에서의 Authorization

20 hours ago 1

대형 언어 모델(LLM)은 인간 사용자의 불확실한 입력을 처리하는 예측 불가능한 시스템이기 때문에, 최소 권한 원칙(least privilege) 적용이 필수적임
LLM이 실제로는 내부 검색·자동화 등 다양한 업무에 활용되면서, 최소한의 권한만 부여된 “효과적 권한(effective permissions)” 에서만 동작하도록 해야 보안 사고·오용을 방지할 수 있음
RAG(검색 증강 생성) 구조에서는 데이터 임베딩과 권한 체크를 데이터 소스와 분리하여, 리소스 레벨에서 정밀한 권한 제어가 필요함
외부(3rd party) 데이터/RAG, Agent, MCP 등 복잡한 활용이 늘수록, 실제 권한 적용 위치와 방식이 보안의 핵심 이슈로 부상함
OAuth 등 토큰 기반 인증은 리소스 단위의 세밀한 권한 통제에 한계가 있어, 실제 권한 로직은 애플리케이션 레이어에서 직접 구현해야 함

용어 및 기본 개념

Prompt: LLM에 전달하는 사용자의 요청(명령문, 질문 등)
RAG(Retrieval-Augmented Generation): 프롬프트에 추가 데이터를 첨부해 LLM의 응답 정확도를 높이는 워크플로우(예: 회사 휴가 목록을 자동으로 첨부)
Context: 프롬프트에 첨부되는 보조 데이터(검색된 관련 자료 등)
Embedding: 텍스트의 수치화된 벡터 표현, 데이터 검색/매칭에 활용
Agent: 프롬프트에 따라 액션을 수행하는 LLM 기반 실행 엔진(툴 자동 호출 등)
Tool: LLM이 직접 호출할 수 있는 API/애플리케이션 등 외부 기능
Model Context Protocol(MCP): Anthropic이 제안한 LLM의 툴 액세스 표준 프로토콜

Golden Rule:
LLM은 사용자의 요청을 처리하는 데 반드시 필요한 최소 권한만으로 동작해야 함
인간 사용자에게는 "관행적 과다 권한"이 어느 정도 허용되지만, LLM은 예측 불가능하고 빠르며 실수 시 대규모 피해 발생 가능.
→ LLM의 “실효 권한(effective permissions)”은 사용자·LLM·태스크 권한의 교집합으로 한정해야 함

LLM 애플리케이션의 실효 권한 =
1. LLM이 가진 권한
2. 사용자가 가진 권한
3. 요청된 태스크에 필요한 권한
  이 세 가지의 교집합
사용자는 LLM(챗봇 등)에게 자신의 역할을 “위임(impersonation)”하지만,
LLM과 사용자가 가진 권한 범위를 모두 넘어서면 안 됨
권한 Venn 다이어그램으로 직관적으로 설명
- 태스크 권한이 교집합에 완전히 포함될 때만 실행 허용

예시: 사내 챗봇이 사내 소스코드에서 “비밀 키가 포함된 파일”을 찾아주는 경우
임베딩: 모든 파일을 벡터로 변환해 DB에 저장, 프롬프트도 벡터로 변환해 유사도 기반 매칭
권한 적용 위치:
- 검색 결과로 반환된 “파일”의 실제 소유 조직, 종류, 리포지토리, 사용자 권한을 즉시 확인
- 사용자가 해당 파일에 접근 가능한지 확인(리소스 레벨 권한)
- 임베딩 → 소스 데이터 연결 과정에서 애플리케이션 계층에서 권한 검사
LLM 자체에 권한 로직을 넣는 것은 불안정(확률적 특성상 보장 불가)
정리:
- RAG의 핵심은, 임베딩과 원본 데이터 연결 후 사용자별/리소스별 권한을 강력하게 적용하는 것

외부 API/시스템(예: 위키, 티켓 시스템 등)의 데이터를 임베딩해 활용
문제점: 임베딩과 원본 데이터가 서로 다른 시스템에 존재 → 권한 적용 위치가 모호
권한 처리 방법 세 가지
1. 외부 시스템에 권한 위임(API 단 건 요청마다 실제 권한 확인, 느린 응답·레이트 리밋 문제)
2. ACL(접근 제어 목록)을 애플리케이션에 동기화(정확도/신뢰성은 높지만, ACL 관리/동기화 비용 증가)
3. 외부 권한 로직 자체를 내부에 재구현(관리·동기화 부담, 논리 복잡성 증가)
결론: 실제 상황에 따라 “권한 적용 위치”와 방식의 trade-off가 중요
(성능-간결함, 관리 비용-정밀도 등 선택 필요)

예시: 챗봇이 리포지토리 브랜치 삭제/이슈 닫기 등 자동 유지보수 작업
MCP(Model Context Protocol)로 툴(함수/API)을 LLM에 표준화 방식으로 노출
MCP의 각 요청마다 실효 권한 모델을 적용해야 함
(사용자/에이전트/태스크 권한의 교집합)
OAuth 등 토큰 기반 인증의 한계
- 권한 정보가 토큰에 포함되지만, 실시간 자원/리소스 단위 권한을 커버하지 못함
- 실제로는 토큰에 일부 정보만 담고, 나머지는 애플리케이션 계층에서 별도 권한 로직 구현 필요

LLM/RAG/Agent 환경에서 권한 관리의 핵심은 “권한 적용 위치와 방식” 선정
실효 권한 모델을 통해, LLM이 “사용자+LLM+태스크” 교집합 내에서만 동작하도록 제한
OAuth 등 인증 토큰은 “누가 요청했는가” 식별용으로만 사용,
실제 리소스별 권한 검증은 반드시 애플리케이션에서 수행
외부 시스템 연동 시에는,
1) 권한을 위임(성능 저하), 2) ACL 동기화(운영 복잡), 3) 권한 로직 재구현(높은 유지관리)
등 다양한 trade-off를 고려해 설계 필요
최종 요약:

LLM은 사용자 요청을 처리하는 데 반드시 필요한 최소 권한 내에서만 동작해야 하며,
실효 권한(effective permissions)은 LLM 권한, 사용자 권한, 태스크 권한의 교집합으로 정의
실제 권한 검증은 리소스별, 애플리케이션 계층에서 반드시 수행해야 함