권한 경계와 자격증명 격리

에이전트에게 마스터 키를 주지 마세요

🔄 Quick Recall: 지난 레슨에서 5가지 Docker 하드닝 플래그로 에이전트를 컨테이너화했어요. 컨테이너가 에이전트가 시스템에 할 수 있는 것을 제한해요. 하지만 컨테이너 안에서 에이전트는 여러분이 준 모든 것에 접근할 수 있어요 — 그리고 대부분의 사람들이 너무 많이 줘요.

Argus Security의 OpenClaw 감사에서 OAuth 토큰이 암호화 없이 평문 JSON 파일에 저장되어 있음을 발견했어요. 파일 권한은 0o600(소유자 전용)으로 설정되었지만, OpenClaw가 파일 소유자로 실행되므로 에이전트가 로드하는 모든 스킬이 해당 토큰을 읽을 수 있었어요.

512개의 취약점. 8개가 치명적. 가장 근본적인 문제: 에이전트가 여러분과 같은 접근 권한을 가진다는 것.

이 레슨을 마치면 다음을 할 수 있어요:

AI 에이전트 설정에 최소 권한을 적용
에이전트가 원시 비밀을 직접 다루지 않도록 자격증명 격리를 설정

문제: 에이전트가 곧 여러분

에이전트에게 API 키를 주면 “약간의 접근"을 주는 게 아니에요. 여러분의 접근을 주는 거예요. 같은 권한, 같은 범위, 같은 피해 반경.

그 키가 프로덕션 데이터베이스를 읽고 쓸 수 있으면, 에이전트도 그래요. 악성 스킬이 그 키를 유출하면, 공격자가 여러분의 전체 데이터베이스 접근을 얻어요. 에이전트의 접근이 아니라 — 여러분의 접근.

나쁜 관행	좋은 관행
에이전트와 개인 API 키 공유	제한된 범위의 에이전트 전용 키 생성
모든 파일에 읽기/쓰기 접근	특정 디렉토리에 읽기 전용 접근
관리자 레벨 데이터베이스 자격증명	특정 테이블에 읽기 전용 역할
무제한 API 속도 제한	사용량을 제한하는 속도 제한 토큰
만료되지 않는 장기 토큰	자동 교체되는 단기 토큰

원칙 1: 범위 제한 토큰

마스터 키 대신, 에이전트가 필요한 것에 정확히 범위가 제한된 토큰을 만드세요.

예시: 이메일 통합

접근 레벨	리스크
전체 Gmail 접근 (읽기, 쓰기, 발송, 삭제)	에이전트가 여러분 명의로 이메일 발송, 대화 삭제 가능
읽기 전용 Gmail 접근	에이전트가 읽을 수 있지만 행동 불가 — 분류에 안전
특정 라벨만 읽기 전용	에이전트가 사전 필터링된 이메일만 확인

가장 제한적인 범위로 시작하세요. 에이전트가 더 필요하면 명시적으로 추가하세요 — 넓게 시작해서 나중에 좁히려 하지 마세요.

예시: 파일 시스템 접근

# 전체 홈 디렉토리를 마운트하는 대신:
volumes:
  - ~/:/app/home:rw  # 이렇게 하지 마세요

# 에이전트가 필요한 디렉토리만 마운트:
volumes:
  - ~/projects/current:/app/workspace:rw
  - ~/documents/reference:/app/reference:ro  # 읽기 전용

✅ Quick Check: 에이전트가 Documents 폴더의 파일을 요약해야 해요. 올바른 볼륨 마운트는? (답: ~/Documents:/app/docs:ro — Documents 폴더에만 읽기 전용 접근. 에이전트가 파일을 읽어 요약할 수 있지만 수정, 삭제하거나 해당 디렉토리 밖에 접근할 수 없어요.)

원칙 2: 자격증명 격리

자격증명은 에이전트의 컨텍스트 안에 절대 존재하면 안 돼요. Composio의 Managed Auth 접근이 패턴을 보여줘요:

자격증명이 별도 서비스에 보관 (시크릿 매니저, 볼트, 또는 인증 프록시)
에이전트가 행동을 요청 (“이 이메일 보내줘”) 토큰을 직접 보지 않고
인증 서비스가 작업 실행 에이전트가 접근할 수 없는 자격증명 사용
감사 로그에 기록 무엇이 요청되고 실행되었는지

개인 사용을 위한 간단한 버전:

# 환경 변수로 API 키를 전달하는 대신:
OPENAI_API_KEY=sk-abc123  # 에이전트가 읽을 수 있음

# 인증을 주입하는 프록시 사용:
# 에이전트가 http://localhost:8080/api를 호출
# 프록시가 전달 전에 API 키 헤더를 추가
# 에이전트는 키를 절대 볼 수 없음

프록시가 자격증명 경계 역할을 해요. 악성 스킬이 받지 못한 키를 추출할 수 없어요.

원칙 3: JIT(Just-In-Time) 접근

CyberArk의 프레임워크는 AI 에이전트를 아이덴티티 — 건물 접근이 필요한 직원처럼 — 로 취급해요. 핵심 인사이트: 영구 자격증명을 주지 마세요. 임시 자격증명을 주세요.

개인 사용에서의 의미:

모든 API 키를 항상 활성 상태로 두지 마세요. 에이전트를 적극적으로 사용하지 않을 때 키를 비활성화하세요.
토큰 교체를 사용하세요. 에이전트의 토큰이 손상되면 단기 토큰이 노출 기간을 제한해요.
활성 세션을 검토하세요. 주기적으로 활성 토큰을 확인하고 인식하지 못하는 것은 취소하세요.

✅ Quick Check: 일주일간 휴가를 가고 AI 에이전트를 사용하지 않아요. 자격증명으로 무엇을 해야 하나요? (답: 모든 활성 토큰을 취소하거나 비활성화하세요. 돌아오면 새 토큰을 만드세요. 유휴 자격증명의 일주일은 손상된 경우 노출의 일주일이에요. JIT 접근은 자격증명이 필요할 때만 존재한다는 뜻이에요.)

원칙 4: 행동 허용 목록

에이전트가 도구를 책임감 있게 사용하리라 신뢰하는 대신, 어떤 도구를 사용할 수 있는지 정확히 정의하세요:

# 기본 거부: 명시적으로 허용된 도구만 사용 가능
allowed_actions:
  - read_file
  - write_file
  - web_search

# 명시적으로 차단 (allowed_actions가 더 넓더라도)
blocked_actions:
  - shell_execute
  - delete_file
  - send_email
  - browser_control

이것은 위협 모델의 OWASP A1(도구 오용)과 A2(과도한 에이전시)의 구현이에요. 허용 목록이 그 제어의 실행이에요.

모든 것을 결합하기

네 가지 원칙을 결합한 권한 경계 설정:

1. 범위 제한 토큰: 하나의 프로젝트에 읽기 전용 접근이 가능한 에이전트 전용 API 키

2. 자격증명 격리: API 키가 프록시에 보관, 에이전트는 직접 볼 수 없음

3. JIT 접근: 토큰이 4시간 후 만료, 에이전트 활성 시에만 자동 갱신

4. 행동 허용 목록: 파일 읽기/쓰기와 웹 검색만 허용; 셸, 이메일, 브라우저 불가

악성 스킬이 에이전트를 손상시키면: 자격증명을 얻을 수 없고(격리), 셸 명령을 실행할 수 없고(허용 목록), 하나의 프로젝트 디렉토리만 접근 가능하고(범위 제한 토큰), 토큰이 몇 시간 내 만료돼요(JIT).

핵심 정리

에이전트는 여러분의 접근 권한을 가져요 — 손상된 에이전트는 손상된 여러분을 의미해요
범위 제한 토큰이 피해 반경을 제한해요: 에이전트 전용, 읽기 전용, 프로젝트 특정
자격증명 격리는 에이전트가 원시 비밀을 직접 다루지 않게 해요 — 프록시나 시크릿 매니저 사용
JIT 접근은 자격증명이 필요할 때만 존재 — 유휴 시 취소
행동 허용 목록이 에이전트가 사용할 수 있는 도구를 정확히 정의 — 셸, 이메일, 브라우저는 기본 거부
네 가지를 결합해 심층 방어: 한 레이어가 실패해도 나머지가 피해를 제한

다음 레슨

에이전트가 격리(Docker)되고 제한(권한)되었어요. 하지만 설치하는 스킬은 어떨까요? 악성 스킬 하나가 여러분의 모든 신중한 설정을 우회할 수 있어요. 다음 레슨에서 스킬을 검증하는 방법을 배워요 — 안전한 스킬과 트로이목마를 구분하는 5단계 프레임워크.