# LLM 애플리케이션에서의 Authorization

> Clean Markdown view of GeekNews topic #22258. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=22258](https://news.hada.io/topic?id=22258)
- GeekNews Markdown: [https://news.hada.io/topic/22258.md](https://news.hada.io/topic/22258.md)
- Type: news
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-07-31T10:11:02+09:00
- Updated: 2025-07-31T10:11:02+09:00
- Original source: [osohq.com](https://www.osohq.com/academy/authorization-in-llm-applications)
- Points: 12
- Comments: 0

## Summary

**대형 언어 모델(LLM)** 은 예측 불가능한 입력 처리 특성 때문에, 보안 사고와 데이터 오남용을 막기 위해 **최소 권한 원칙**과 **실효 권한(effective permissions)** 적용이 필수적입니다. 특히 **RAG(검색 증강 생성)**, 외부 데이터, 에이전트(Agent) 등 복잡한 활용이 많아지면서, **애플리케이션 계층**에서의 리소스별 정밀한 권한 검증이 핵심 과제가 되고 있습니다. **OAuth 등 토큰 기반 인증**만으로는 세밀한 권한 통제가 어렵기 때문에, 실제 권한 관리 로직을 별도로 구현해야 하며, 외부 시스템 연동 시에는 성능, 관리 비용, 정밀도 간 **trade-off**까지 고려한 설계가 요구됩니다. LLM이 안전하게 동작하려면 반드시 “사용자, LLM, 태스크 권한의 교집합 내에서만 실행”하도록 제한해야 합니다.

## Topic Body

- **대형 언어 모델(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의 툴 액세스 표준 프로토콜  
  
### LLM 권한 모델의 핵심 원칙  
  
- **Golden Rule**:  
  > LLM은 사용자의 요청을 처리하는 데 반드시 필요한 **최소 권한**만으로 동작해야 함  
- 인간 사용자에게는 "관행적 과다 권한"이 어느 정도 허용되지만, **LLM은 예측 불가능하고 빠르며 실수 시 대규모 피해 발생 가능**.  
  → **LLM의 “실효 권한(effective permissions)”은 사용자·LLM·태스크 권한의 교집합으로 한정**해야 함  
  
#### 실효 권한(effective permissions) 계산  
  
- **LLM 애플리케이션의 실효 권한** =  
  1) LLM이 가진 권한  
  2) 사용자가 가진 권한  
  3) 요청된 태스크에 필요한 권한  
  **이 세 가지의 교집합**  
- 사용자는 LLM(챗봇 등)에게 자신의 역할을 “위임(impersonation)”하지만,  
  LLM과 사용자가 가진 권한 범위를 모두 넘어서면 안 됨  
- **권한 Venn 다이어그램**으로 직관적으로 설명  
  - 태스크 권한이 교집합에 완전히 포함될 때만 실행 허용  
  
### RAG(검색 증강 생성)와 권한 처리  
  
#### 1. 1st Party(자사) 데이터 RAG  
  
- 예시: 사내 챗봇이 사내 소스코드에서 “비밀 키가 포함된 파일”을 찾아주는 경우  
- **임베딩**: 모든 파일을 벡터로 변환해 DB에 저장, 프롬프트도 벡터로 변환해 유사도 기반 매칭  
- **권한 적용 위치**:  
  - 검색 결과로 반환된 “파일”의 실제 소유 조직, 종류, 리포지토리, 사용자 권한을 **즉시 확인**  
  - 사용자가 해당 파일에 접근 가능한지 확인(리소스 레벨 권한)  
  - 임베딩 → 소스 데이터 연결 과정에서 **애플리케이션 계층에서 권한 검사**  
- LLM 자체에 권한 로직을 넣는 것은 불안정(확률적 특성상 보장 불가)  
- **정리**:  
  - RAG의 핵심은, 임베딩과 원본 데이터 연결 후 **사용자별/리소스별 권한을 강력하게 적용**하는 것  
  
#### 2. 3rd Party(외부) 데이터 RAG  
  
- 외부 API/시스템(예: 위키, 티켓 시스템 등)의 데이터를 임베딩해 활용  
- **문제점**: 임베딩과 원본 데이터가 서로 다른 시스템에 존재 → 권한 적용 위치가 모호  
- **권한 처리 방법 세 가지**  
  1) **외부 시스템에 권한 위임**(API 단 건 요청마다 실제 권한 확인, 느린 응답·레이트 리밋 문제)  
  2) **ACL(접근 제어 목록)을 애플리케이션에 동기화**(정확도/신뢰성은 높지만, ACL 관리/동기화 비용 증가)  
  3) **외부 권한 로직 자체를 내부에 재구현**(관리·동기화 부담, 논리 복잡성 증가)  
- **결론**: 실제 상황에 따라 “권한 적용 위치”와 방식의 trade-off가 중요  
  (성능-간결함, 관리 비용-정밀도 등 선택 필요)  
  
### 에이전트 기반 LLM(AI Agent)와 권한  
  
- 예시: 챗봇이 리포지토리 브랜치 삭제/이슈 닫기 등 자동 유지보수 작업  
- MCP(Model Context Protocol)로 **툴(함수/API)을 LLM에 표준화 방식으로 노출**  
- MCP의 각 요청마다 **실효 권한 모델**을 적용해야 함  
  (사용자/에이전트/태스크 권한의 교집합)  
- **OAuth 등 토큰 기반 인증의 한계**  
  - 권한 정보가 토큰에 포함되지만, 실시간 자원/리소스 단위 권한을 커버하지 못함  
  - 실제로는 토큰에 일부 정보만 담고, 나머지는 **애플리케이션 계층에서 별도 권한 로직 구현** 필요  
  
### 결론 및 실무 요약  
  
- LLM/RAG/Agent 환경에서 **권한 관리의 핵심은 “권한 적용 위치와 방식” 선정**  
- **실효 권한 모델**을 통해, LLM이 “사용자+LLM+태스크” 교집합 내에서만 동작하도록 제한  
- OAuth 등 인증 토큰은 “누가 요청했는가” 식별용으로만 사용,  
  **실제 리소스별 권한 검증은 반드시 애플리케이션에서 수행**  
- 외부 시스템 연동 시에는,  
  **1) 권한을 위임(성능 저하), 2) ACL 동기화(운영 복잡), 3) 권한 로직 재구현(높은 유지관리)**  
  등 다양한 trade-off를 고려해 설계 필요  
  
- **최종 요약**:  
  > LLM은 사용자 요청을 처리하는 데 반드시 필요한 최소 권한 내에서만 동작해야 하며,  
  > 실효 권한(effective permissions)은 LLM 권한, 사용자 권한, 태스크 권한의 교집합으로 정의  
  > 실제 권한 검증은 리소스별, 애플리케이션 계층에서 반드시 수행해야 함

## Comments



_No public comments on this page._