108 lines
5.4 KiB
Markdown
108 lines
5.4 KiB
Markdown
---
|
|
id: wiki-2026-0508-excessive-agency
|
|
title: Excessive Agency
|
|
category: 10_Wiki/Topics
|
|
status: needs_review
|
|
canonical_id: self
|
|
aliases: []
|
|
duplicate_of: none
|
|
source_trust_level: A
|
|
confidence_score: 0.92
|
|
tags: [uncategorized]
|
|
raw_sources: []
|
|
last_reinforced: 2026-05-08
|
|
github_commit: pending
|
|
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
|
tech_stack:
|
|
language: unspecified
|
|
framework: unspecified
|
|
---
|
|
|
|
# Excessive Agency (과도한 권한 남용)
|
|
|
|
## 📌 한 줄 통찰 (The Karpathy Summary)
|
|
Excessive Agency(과도한 권한 남용)는 AI 에이전트에게 현재 작업을 수행하는 데 필요한 범위를 넘어서는 지나치게 강력한 도구 접근 권한, 데이터 접근 권한, 혹은 자율적 결정권이 부여되어 발생하는 보안 리스크이다. 이는 OWASP LLM06 위험으로 분류되며, 프롬프트 인젝션 공격 시 에이전트가 시스템 전체를 장악하거나 돌이킬 수 없는 피해를 입히는 직접적인 원인이 된다.
|
|
|
|
## 📖 구조화된 지식 (Synthesized Content)
|
|
* **리스크의 세 가지 양상**:
|
|
* **과도한 도구 권한 (Excessive Functionality)**: 단순히 파일을 읽기만 하면 되는데 파일 삭제나 셸 실행 권한까지 부여된 경우.
|
|
* **과도한 데이터 접근 (Excessive Permissions)**: 특정 문서만 필요함에도 데이터베이스 전체나 다른 사용자의 데이터에 접근 가능한 경우.
|
|
* **과도한 자율성 (Excessive Autonomy)**: 사용자 승인 없이 이메일 발송, 금융 결제 등 중대한 외부 영향을 끼치는 작업을 수행하게 둔 경우.
|
|
* **발생 원인**: 개발 편의를 위해 모든 권한이 허용된 API 키를 사용하거나, 에이전트가 어떤 상황에서 어떤 도구를 써야 할지에 대한 정교한 정책(Policy)이 부재할 때 발생한다.
|
|
* **방어 전략**:
|
|
* **스키마 수준의 제어 (Schema-level Gating)**: 도구의 파라미터 중 위험한 옵션(예: `rm -rf /`)은 에이전트가 아예 넘길 수 없도록 스키마 수준에서 차단.
|
|
* **최소 권한의 원칙 (Least Privilege)**: 작업 단위별로 필요한 도구만 활성화하는 동적 권한 할당.
|
|
* **승인 게이트 (Approval Gates)**: 파괴적인 행동이나 외부 영향이 큰 작업 전에는 반드시 인간의 개입을 요구.
|
|
|
|
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
|
* **유연성 저하**: 권한을 너무 세분화하여 제한하면, 에이전트가 예상치 못한 창의적인 방법으로 문제를 해결하는 능력이 제약될 수 있다.
|
|
* **운영 복잡성**: 수많은 도구와 데이터에 대해 개별적인 권한 정책을 수립하고 유지하는 것은 높은 엔지니어링 비용이 든다.
|
|
|
|
## 🔗 지식 연결 (Graph)
|
|
### Related Concepts
|
|
* [[Agentic AI Security|Agentic AI Security]]
|
|
* 연결 이유: 과도한 권한 남용은 에이전트 보안의 핵심 관리 대상이다.
|
|
* [[T-component (Tool Registry)|T-component (Tool Registry)]]
|
|
* 연결 이유: 도구의 권한과 명세를 관리하는 하네스의 구성 요소이다.
|
|
* [[L-component (Lifecycle Hooks)|L-component (Lifecycle Hooks)]]
|
|
* 연결 이유: 도구 실행 전 권한을 검사하고 정책을 집행하는 실질적인 계층이다.
|
|
|
|
### Deeper Research Questions
|
|
* 작업의 '위험도'를 모델이 실시간으로 평가하여, 위험이 감지될 때만 권한을 일시적으로 축소하는 '동적 권한 격리' 기술은 가능한가?
|
|
* 에이전트가 가진 권한을 그래프 형태로 시각화하여, 한 도구의 권한이 다른 도구로 전이(Privilege Escalation)될 수 있는 경로를 자동으로 탐지하는 방법은 무엇인가?
|
|
|
|
### Practical Application Contexts
|
|
* **Implementation:** 데이터베이스 조회 도구 구현 시, 에이전트용 계정은 'Read-Only' 권한만 부여하고 특정 테이블에만 접근 가능하도록 DB 레벨에서 제한한다.
|
|
* **System Design:** 하네스 설계 시 모든 도구 호출을 가로채는 중앙 집중형 'Policy Enforcement Point'를 두어, 도구 실행 전 정책 엔진(Open Policy Agent 등)에 질의하도록 한다.
|
|
|
|
---
|
|
*Last updated: 2026-05-01*
|
|
|
|
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
|
|
|
**언제 이 지식을 쓰는가:**
|
|
- *(TODO)*
|
|
|
|
**언제 쓰면 안 되는가:**
|
|
- *(TODO)*
|
|
|
|
## 🧪 검증 상태 (Validation)
|
|
|
|
- **정보 상태:** needs_review
|
|
- **출처 신뢰도:** A
|
|
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
|
|
|
## 🧬 중복 검사 (Duplicate Check)
|
|
|
|
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
|
- **처리 방식:** UPDATE (자동 정규화)
|
|
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
|
|
|
## 🕓 변경 이력 (Changelog)
|
|
|
|
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
|
|------|-----------|-----------|--------|
|
|
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
|
|
|
## 💻 코드 패턴 (Code Patterns)
|
|
|
|
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
|
|
|
```text
|
|
# TODO
|
|
```
|
|
|
|
## 🤔 의사결정 기준 (Decision Criteria)
|
|
|
|
**선택 A를 써야 할 때:**
|
|
- *(TODO)*
|
|
|
|
**선택 B를 써야 할 때:**
|
|
- *(TODO)*
|
|
|
|
**기본값:**
|
|
> *(TODO)*
|
|
|
|
## ❌ 안티패턴 (Anti-Patterns)
|
|
|
|
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)* |