권한 누적 문제: AI 에이전트가 원래 허용되지 않은 접근 권한을 축적하는 이유

Source: Dev.to

위 링크에 포함된 전체 텍스트를 제공해 주시면, 해당 내용을 한국어로 번역해 드리겠습니다. (코드 블록이나 URL은 그대로 유지됩니다.)

권한 부풀림 문제

거의 모든 AI 에이전트 배포에서 90일 이상 운영되는 경우에 보이는 패턴이 있습니다:

에이전트는 읽기 전용 접근 권한으로 시작했습니다. 파일을 써야 했고, 알림을 보내야 했으며, Slack에 게시해야 했고, 웹훅을 트리거해야 했습니다.

각 추가는 개별적으로는 타당했습니다. 그러나 모두 합쳐지면 누구도 의도하지 않은 훨씬 더 큰 권한을 가진 에이전트가 됩니다.

이것이 권한 부풀림이며, AI 에이전트 운영에서 가장 과소평가된 신뢰성 위험 중 하나입니다.

왜 발생하는가

프로덕션에 있는 AI 에이전트는 지속적으로 설정된 권한의 한계에 부딪힙니다. 그럴 때 자연스러운 반응은 권한을 추가하는 것입니다:

• 에이전트가 결과를 기록해야 함 → 디렉터리에 대한 쓰기 권한을 부여
• 에이전트가 실패 시 알림을 보내야 함 → Slack 웹훅을 제공
• 에이전트가 레코드를 업데이트해야 함 → 데이터베이스 쓰기 권한을 부여
• 에이전트가 요약을 전송해야 함 → 이메일 전송 권한을 부여

이러한 개별 결정이 잘못된 것은 없습니다. 하지만 “이 에이전트가 지금 실제로 무엇을 할 수 있나요?” 라고 한 걸음 물러서서 묻는 경우는 거의 없습니다.

90일이 지나면 답은 보통 “생각보다 훨씬 많다” 입니다.

실수 비용은 접근 권한에 따라 확대됩니다

읽기 전용 에이전트가 흐트러지면 잘못된 출력을 생성합니다. 이를 잡아 수정하고 넘어갑니다.

이메일 전송 권한이 있는 에이전트가 흐트러지면 새벽 2시에 200명의 고객에게 혼란스러운 메시지를 보냅니다.

능력은 변하지 않았습니다 — 단지 영향 범위가 확대된 것일 뿐입니다.

월간 권한 감사

매달 10분 리뷰로 해결하세요. 각 에이전트마다:

1. 실제로 할 수 있는 작업을 나열
   문서에만 의존하지 마세요. 실제 자격 증명, API 키, 접근 가능한 파일 경로를 확인하십시오. 현실과 문서는 빠르게 달라집니다.

2. “이 에이전트가 취할 수 있는 최악의 단일 행동은 무엇인가?”
   그 행동이 재앙을 초래한다면, 가능성이 얼마나 낮아 보이든 문제가 됩니다.

3. 필요 최소 접근 원칙 적용
   각 권한에 대해: 에이전트의 핵심 기능에 필수적인가? 아니면 시간이 지나면서 쌓인 편의성인가?

4. 제거한 내용을 문서화
   제거한 모든 권한을 기록하십시오. 나중에 정당히 필요했음이 밝혀지면, 왜 제거했는지에 대한 기록이 필요합니다.

SOUL.md 권한 블록

제가 작업해 본 가장 신뢰할 수 있는 에이전트들은 신원 파일에 명시적인 권한 섹션을 가지고 있습니다:

## Permissions
### Can do without asking:
- Read any file in /workspace
- Write to memory/ and logs/
- Post to outbox.json

### Must ask before doing:
- Writing outside /workspace
- Sending any external message
- Making any API call with write access

### Never do:
- Send email
- Make financial transactions
- Modify SOUL.md or config files
- Access files outside designated directories

This isn’t just documentation — the agent reads this file every turn. The permission boundaries are part of its working context, not a one‑time setup.

재로드 규칙

권한 문서는 에이전트가 실제로 읽을 때만 의미가 있습니다. 대부분의 에이전트는 초기화 시에 한 번만 설정을 로드하고, 세션이 컨텍스트를 축적함에 따라 그 설정에서 벗어나게 됩니다.

수정: 매 턴 시작 시, 최소한 매 세션 시작 시에 권한 블록을 다시 로드하십시오. 에이전트가 매 행동 전에 자신의 권한 경계를 읽으면, 원래 들어가서는 안 되는 영역으로 떠돌아다니지 않게 됩니다.

Practical Setup

• Today: 에이전트가 접근할 수 있는 모든 자격 증명, API 키, 파일 경로를 10분 동안 나열하세요. 이를 에이전트를 만들 때 의도한 것과 비교해 보세요.
• This week: SOUL.md에 권한 블록을 추가하세요. 에이전트가 할 수 있는 일, 승인이 필요한 일, 절대로 해서는 안 되는 일을 명확히 명시합니다.
• Monthly: 권한을 재감사하기 위한 캘린더 알림을 설정하세요. 새로운 접근 권한은 반응적으로가 아니라 의도적으로 추가합니다.

권한 부풀림은 서서히 진행되다가 급격한 위기로 이어지는 문제입니다. 6개월 이상 사고 없이 운영된 에이전트는 거의 항상 명시적이고 적극적으로 관리되는 권한 경계를 가지고 있습니다.

작동하는 설정—다섯 개의 프로덕션 에이전트 전반에 걸쳐 사용하는 권한 블록 템플릿을 포함—은 Ask Patrick Library에서 확인할 수 있습니다.