Ch5. 접근제어·비밀관리
사람, 서비스 계정, 에이전트 아이덴티티를 분리하고 비밀정보 저장·회전·감사 기준을 최소권한 운영 체계로 정리합니다.
핵심 요약
- 신뢰 수준을 사람(High) > 서비스 계정(Medium) > 에이전트(Low)로 고정하고, 에이전트 권한은 항상 서비스 계정 이하로 유지하세요.
- 에이전트 아이덴티티는 자동 생성·폐기가 기본이며 생성 시 TTL 90일, credential 로테이션 30일, 폐기 시 grace period 24시간을 적용합니다.
- 토큰은 Short-lived(15~60분)·Scoped Service(24시간)·Long-lived API Key(90일)·Ephemeral(요청 단위)·Delegated로 구분하고, 결제·삭제·외부 전송 같은 고위험 작업엔 Ephemeral 토큰을 씁니다.
- RBAC로 역할을 고정한 뒤 ABAC 조건(
env == "prod",amount <= 300000,approval == true)으로 동적 제한을 겁니다. - Exposure Window = 로테이션 주기 - 탐지 시간이므로, 로테이션 단축과 실시간 유출 탐지를 병행해 노출 시간을 줄입니다.
AI 제품에서는 사람 계정만 움직이지 않습니다. 서비스 계정과 에이전트 아이덴티티가 함께 돕니다. 권한 모델을 분리해두지 않으면 사고가 났을 때 원인과 책임 경계를 되짚기 어렵습니다.
권한 주체 모델
| 주체 | 권한 범위 | 필수 통제 |
|---|---|---|
| 사람 계정(Human) | 업무 수행 권한 | MFA, SSO, JIT 승인 |
| 서비스 계정(Service) | 시스템 간 호출 | 최소 권한 범위(scope), 키 로테이션 |
| 에이전트(Agent) | 도구 실행 권한 | 도구 허용 목록(allowlist), 실행 한도 |
에이전트는 항상 최하위 신뢰
에이전트가 사람 수준의 권한을 갖는 순간 prompt injection 하나로 전체 시스템 권한이 넘어갑니다. 에이전트 신뢰 수준은 항상 Service Account 이하로 유지하세요.
Agent Identity Lifecycle
에이전트 아이덴티티는 사람 계정과 달리 자동 생성·자동 폐기가 기본입니다. 손으로 관리하다 보면 폐기되지 않고 남는 좀비 에이전트가 쌓입니다.
생성(Provisioning)
- 에이전트 등록 시 고유
agent_id+ 소유자(owner) + 목적(purpose)을 태깅합니다. - 허용 도구 목록(allowlist)과 호출 한도(rate limit)를 정의합니다.
- 생성 즉시 만료일(TTL)을 부여합니다. 기본값 90일.
범위 지정(Scoping)
- 에이전트에 부여할 scope를 최소 권한 원칙으로 설정합니다.
- 환경(dev/staging/prod)별로 별도 credential을 발급합니다.
- 고위험 도구(결제, 삭제, 외부 전송)는 별도 승인 플로우를 경유합니다.
로테이션(Rotation)
- credential은 주기적으로 자동 교체합니다(기본 30일).
- 로테이션 시 이전 credential은 grace period(24시간) 후 폐기합니다.
- 로테이션 실패 시 자동 알림 + 에이전트 일시 중지 트리거.
폐기(Revocation)
- 만료일 도달, 이상 행동 탐지, 소유자 퇴사 시 즉시 폐기합니다.
- 폐기 시 해당 에이전트의 활성 세션도 함께 무효화합니다.
- 폐기 이력은 감사 로그에 90일 이상 보관합니다.
Token Scope Matrix
에이전트와 서비스 계정에 발급하는 토큰은 유형별로 허용 범위를 분명히 정해둡니다.
| 토큰 유형 | 유효 기간 | 허용 Scope | 갱신 방식 | 사용 시나리오 |
|---|---|---|---|---|
| Short-lived Access Token | 15~60분 | 단일 API 호출 | 자동 재발급 | 에이전트 도구 실행 |
| Scoped Service Token | 24시간 | 특정 서비스 그룹 | Refresh token | 배치 처리, 파이프라인 |
| Long-lived API Key | 90일 | 읽기 전용 | 수동 로테이션 | 모니터링, 대시보드 |
| Ephemeral Session Token | 요청 단위 | 단일 트랜잭션 | 재사용 불가 | 고위험 작업(결제, 삭제) |
| Delegated Token | 위임자 세션 | 위임자 권한 이하 | 위임 해제 시 폐기 | Human→Agent 위임 실행 |
Ephemeral Token 우선 원칙
고위험 작업(결제·삭제·외부 전송)에는 반드시 Ephemeral Session Token을 사용하세요. 토큰이 단일 트랜잭션 직후 폐기되므로 유출되더라도 다시 쓸 수 없습니다.
RBAC + ABAC 혼합 전략
- RBAC: 역할(개발, 운영, 보안, 분석)을 먼저 고정합니다.
- ABAC: 환경/시간/리스크 레벨 같은 조건으로 동적으로 제한합니다.
access_policy:
subject: agent_support_bot
action: refund.create
resource: payment_api
conditions:
- env == "prod"
- amount <= 300000
- approval == trueZero Trust for Agents
AI 에이전트 환경에서는 전통적인 네트워크 경계 기반 신뢰가 통하지 않습니다. 에이전트는 매 요청마다 검증해야 합니다.
Zero Trust 원칙 적용
| 원칙 | 전통 시스템 | AI 에이전트 적용 |
|---|---|---|
| Never Trust, Always Verify | IP/VPN 기반 인증 | 매 도구 호출 시 토큰 + scope 검증 |
| Least Privilege | 역할 기반 권한 | 도구 단위 allowlist + 호출 한도 |
| Assume Breach | 침입 탐지 후 대응 | 에이전트 출력이 항상 변조 가능하다고 가정 |
| Continuous Validation | 세션 기반 인증 | 매 실행 단계마다 context 재검증 |
에이전트 Zero Trust 체크리스트
- 에이전트 간 직접 통신 금지 — 반드시 중앙 오케스트레이터를 경유
- 에이전트 출력을 다른 에이전트 입력으로 직접 전달하지 않음 (sanitization 필수)
- 에이전트가 자기 자신의 권한을 상승시키는 경로를 차단
- 도구 실행 결과에 대한 무결성 검증 (체크섬, 스키마 검증)
- 이상 패턴 탐지 시 자동 격리 (circuit breaker 패턴)
AI 에이전트 보안 위협 (2026 동향)
AI 에이전트 도입이 늘면서 새로운 공격 표면도 함께 늘었습니다. OWASP Top 10 for LLM Applications 2025는 LLM06(Excessive Agency, 과도한 에이전시)을 주요 위협으로 올렸습니다.
에이전트 고유 공격 벡터
| 공격 유형 | 설명 | 영향 | 방어 통제 |
|---|---|---|---|
| 도구 호출 조작 | 프롬프트 인젝션으로 에이전트가 의도하지 않은 도구를 실행하도록 유도 | 데이터 삭제, 무단 결제, 정보 유출 | Tool Allowlist + HITL 승인 + 호출 전 Policy Check |
| 과도한 에이전시 | 에이전트에 불필요하게 넓은 권한과 도구를 부여하여 공격 영향 극대화 | 단일 취약점으로 전체 시스템 침해 | 최소 권한 원칙, 도구별 scope 제한, 정기 권한 감사 |
| 권한 에스컬레이션 | 에이전트가 자기 자신의 권한을 상승시키거나, 다른 에이전트의 권한을 탈취 | 고위험 도구 무단 실행 | 권한 상승 경로 차단, 위임 토큰 만료 강제 |
| 에이전트 간 공격 전파 | 침해된 에이전트의 출력이 다른 에이전트 입력으로 전달되어 연쇄 침해 | 멀티 에이전트 시스템 전체 오염 | 에이전트 간 출력 sanitization, 오케스트레이터 경유 필수 |
| 도구 결과 변조 | 도구 실행 결과를 조작하여 에이전트의 후속 판단을 오염 | 잘못된 의사결정, 데이터 무결성 훼손 | 도구 결과 스키마 검증, 체크섬 확인 |
| 세션 하이재킹 | 에이전트 세션 토큰 탈취로 진행 중인 작업을 가로챔 | 작업 결과 탈취, 무단 명령 실행 | Ephemeral Token, 세션 바인딩, 이상 행동 탐지 |
에이전트 보안 설계 원칙
도구 최소 연결(Minimal Tool Binding)
- 에이전트에 연결하는 도구 수를 최소화합니다. "혹시 필요할 수 있는" 도구를 미리 연결하지 마세요.
- 고위험 도구(
sql_write,shell_exec,payment_refund,file_delete)는 반드시 별도 승인 플로우를 거칩니다. - 도구 연결 변경 시 보안 리뷰를 필수로 수행합니다.
도구 호출 전 검증(Pre-Invocation Check)
- 에이전트가 도구를 호출하기 전에 Policy Engine이 실시간으로 허용 여부를 판단합니다.
- 호출 파라미터가 예상 스키마와 일치하는지 검증합니다(SQL 인젝션, 경로 조작 등 방지).
- 고위험 도구는 Human-in-the-loop(HITL) 승인을 기본값으로 설정합니다.
에이전트 행동 모니터링
- 에이전트의 도구 호출 패턴, 빈도, 파라미터를 실시간으로 모니터링합니다.
- 비정상 패턴(급격한 호출 증가, 미사용 도구 호출, 권한 외 접근 시도) 탐지 시 자동 격리합니다.
- 에이전트 행동 로그를 감사 목적으로 최소 90일 보관합니다.
에이전트 권한 과잉 부여 금지
에이전트에 "관리자 수준" 권한을 주는 것이 가장 위험한 안티패턴입니다. 프롬프트 인젝션 한 건으로 전체 시스템의 관리자 권한이 통째로 넘어갑니다. 에이전트 권한은 항상 최소 필요 수준으로 제한하고, 고위험 작업은 반드시 사람이 승인하세요.
비밀정보(Secrets) 생명주기
Secret Exposure Window
비밀정보가 유출됐을 때 실제 노출 시간(exposure window)은 로테이션 주기와 탐지 속도가 좌우합니다.
Exposure Window 최소화
Exposure Window가 길수록 공격자가 유출된 credential을 써먹을 수 있는 시간도 늘어납니다. 로테이션 주기 단축과 실시간 유출 탐지를 함께 가져가세요.
Secret Management 도구 비교
Google Cloud KMS / Azure Key Vault
- 클라우드 네이티브 환경에 최적화
- IAM과 자연스러운 통합, 별도 인프라 불필요
- 자동 로테이션 기본 지원
- 멀티 클라우드 환경에서는 벤더 종속 리스크
# GCP KMS 로테이션 설정 예시
rotation_period: "2592000s" # 30일
next_rotation_time: "2026-04-01T00:00:00Z"운영 지표
- 목표: 권한 상승 세션 비율을 분기 단위로 감소
- 목표: 만료 기한이 없는 비밀정보 0건
감사 포인트
- 공유 계정은 금지하고, 개인별 추적 가능성을 확보합니다.
- 쓰기/삭제/환불/결제 같은 고위험 권한은 이중 승인을 기본값으로 둡니다.
- Joiner-Mover-Leaver(입사/이동/퇴사) 프로세스로 권한을 주기적으로 정리합니다.
완료 산출물
Ch5 완료 기준
이 장을 적용한 뒤에는 권한 주체 모델, Agent Identity Lifecycle, Token Scope Matrix, 고위험 도구 승인 정책, 비밀정보 로테이션 기준, 접근제어 감사 포인트가 남아 있어야 합니다.