AI 에이전트 권한 설계: 최소 권한·승인 경계·감사 로그 실무 가이드

고객 문의를 읽고 환불안을 작성하는 에이전트와 실제 환불을 실행하는 에이전트는 같은 시스템처럼 보여도 위험이 다릅니다. 첫 번째는 잘못된 초안을 사람이 버릴 수 있습니다. 두 번째는 금액과 계정 상태를 바꾸죠.

두 작업에 똑같은 계정과 도구를 주고 “신중하게 처리하라”고 적는 방식은 권한 설계가 아닙니다. 모델의 판단이 흔들려도 실행 범위는 유지되도록 신원, 정책, 승인과 기록을 모델 바깥에 둬야 합니다.

NIST AI RMF는 인간과 AI의 역할·책임을 구분하고, 인간 감독 과정을 정의·평가·문서화하도록 제시합니다. 자발적 위험관리 지침이지 제품별 구현 명세는 아닙니다. NIST AI RMF Core

권한 설계의 출발점은 모델이 아니라 행동 목록이다

“고객 지원 에이전트”라는 설명만으로 권한을 만들 수 없습니다. 주문 조회, 주소 수정, 쿠폰, 환불과 외부 메일 전송은 영향이 다르기 때문입니다.

먼저 행동을 원자적인 작업으로 나눕니다. 주문 조회와 답변 초안은 상태를 바꾸지 않지만 배송지 수정, 쿠폰, 환불과 계정 권한 변경은 영향이 다릅니다. 각 작업에 사용하는 데이터, 상태 변경, 되돌리기 가능 여부와 승인 단계를 적습니다.

AWS 지침도 프롬프트만으로 도구를 통제하는 방식은 충분하지 않으며, 실행 전에 외부의 결정론적 정책이 신원과 입력을 평가해야 한다고 설명합니다. AWS, Implement tool authorization

행동 목록이 있어야 “조회는 자동, 환불은 승인” 같은 규칙을 정책으로 옮길 수 있습니다.

사람과 에이전트의 신원을 분리한다

개인 계정이나 공유 서비스 계정을 여러 에이전트가 쓰면 사람이 실행했는지, 어느 에이전트가 어느 사용자의 요청을 받았는지 구분하기 어렵습니다.

AWS Agentic AI Lens는 에이전트용 서비스 신원을 사람과 분리하고 필요한 권한만 부여하도록 권고합니다. 사용자를 대신할 때도 사용자 자격 증명을 그대로 쓰기보다 사용자 맥락을 claim으로 전달해 하위 시스템이 다시 인가하는 구조를 제시합니다. AWS, Separate agent and human user permission

요청자 신원, 에이전트 이름·버전, 하위 API를 호출하는 실행 신원을 구분합니다. 에이전트에는 소유자와 업무 목적이 있어야 하고 사용자 위임의 범위와 만료 시점도 기록해야 합니다.

최소 권한은 네 축으로 자릅니다. 고객 DB 전체가 아니라 허용된 주문 행, 지원 도구 전체가 아니라 order.read, 임의 API가 아니라 승인된 메서드, 상시 권한이 아니라 특정 작업 시간만 허용하는 식입니다. 업무가 바뀌면 사용하지 않는 권한을 제거하고 에이전트 신원과 토큰을 따로 중지할 수 있어야 합니다.

자동 실행과 사람 승인의 경계를 나눈다

모든 작업을 승인받으면 중요한 요청까지 습관적으로 통과시킬 수 있습니다. AWS는 전수 검토가 승인 피로를 만든다고 지적하며 작업 종류, 대상, 빈도와 이상 징후를 결합한 위험 등급을 권고합니다. AWS, Human-in-the-loop for critical decisions

다음 세 단계면 첫 정책을 만들기 충분합니다.

등급	예시	처리 방식
자동	제한된 읽기, 계산, 폐기 가능한 초안	정책 통과 후 실행·기록
조건부	한도 내 가역 변경, 내부 상태 갱신	금액·횟수·민감도에 따라 승인
사람 승인	결제, 삭제, 외부 전송, 배포, 권한 변경	실행 전 검토, 고위험은 복수 승인 고려

자동 실행도 인증과 로그를 생략하지 않습니다. 같은 도구도 금액, 대상 수와 데이터 민감도에 따라 승인 단계가 달라질 수 있습니다.

AWS는 읽기는 자동, 낮은 위험의 쓰기는 단일 승인자, 금융 거래·삭제·외부 통신은 더 강한 검토를 적용하는 예를 제시합니다. 위험 분류도 비신뢰 입력을 읽은 LLM이 아니라 결정론적 규칙이 판정해야 합니다. AWS, Human-in-the-loop for critical decisions

승인 화면은 판단에 필요한 정보를 압축해야 한다

refund_order 실행을 허용할까요?만 표시되면 주문, 금액과 정책 위반 여부를 판단할 수 없습니다.

승인 패킷에는 요청자, 에이전트·정책 버전, 도구, 대상, 변경값, 근거와 데이터 출처, 되돌리기 가능 여부, 만료 시점을 넣습니다. 예를 들어 order-92318에 48,000원 환불처럼 실제 실행 단위를 보여줘야 합니다.

AWS는 관련 데이터 출처와 잠재적 결과를 함께 보여주고, 응답이 없을 때는 시간 제한, 대체 승인자와 안전한 기본 동작을 두도록 권고합니다. 기본 동작은 보통 실행 차단입니다. AWS, Human-in-the-loop for critical decisions

승인은 특정 호출에 묶어야 합니다. 반복 허용이 필요해도 대상, 최대 금액, 인자 형태, 유효 기간과 취소 방법을 제한합니다.

감사 로그는 최종 답변이 아니라 실행 경로를 남긴다

“환불을 처리했습니다”라는 답변만으로는 사고를 조사할 수 없습니다. 도구 선택, 정책 판정, 승인된 인자와 하위 API 결과를 연결해야 합니다.

OpenAI의 내부 Codex 운영 사례는 사용자 프롬프트, 승인 결정, 도구 결과, MCP 사용과 네트워크 허용·차단을 OpenTelemetry 로그로 내보냅니다. 제품 공통 표준은 아니지만 요청 의도와 행동을 함께 기록하는 사례입니다. OpenAI, Running Codex safely at OpenAI

권장 감사 이벤트

필드	목적
`correlation_id`	사용자 요청부터 하위 도구 결과까지 연결
`requester_id`	작업을 시작한 사람 또는 서비스 식별
`agent_id`, `agent_version`	에이전트와 정책 버전 구분
`tool`, `target`, `arguments`	승인·실행된 작업 비교
`policy_decision`	허용·차단·승인 필요와 적용 규칙 기록
`reviewer_id`, `reviewed_at`	사람의 결정과 시각 기록
`execution_result`, `parent_call_id`	결과와 연쇄 호출 재구성

AWS 지침은 승인 로그에 승인자 신원, 알림·응답 시각, 검토 대상 작업, 결정과 에스컬레이션 이벤트를 포함하도록 권고합니다. AWS, Human-in-the-loop for critical decisions

OpenAI Agents SDK의 tracing은 모델 생성과 함수 호출의 입력·출력을 저장하며 민감정보가 포함될 수 있다고 명시합니다. 민감 데이터 포함을 끄는 설정도 제공합니다. OpenAI Agents SDK, Tracing

비밀값을 마스킹하고 보존 기간과 접근 역할을 정하세요. 조사 식별자와 정책 판정은 유지하되 불필요한 원문은 줄입니다.

운영에 넣기 전 통과시킬 시나리오

정상 요청만 시험하지 말고 아래 실패 시나리오를 확인합니다.

NIST 생성형 AI 프로필은 인간 감독의 역할과 책임을 인벤토리에 포함하고, override와 배포 후 모니터링·사고 대응·복구를 추적하도록 제안합니다. NIST AI 600-1 Generative AI Profile

적용 한계

Human-in-the-loop는 모델 답변의 정확성을 확인하는 절차가 아닙니다. 근거가 잘못되거나 화면이 불완전하면 승인자도 오판할 수 있습니다. 정확성 평가와 정책 테스트는 별도로 필요합니다.

모든 작업을 사람에게 보내는 방식도 지속하기 어렵습니다. 사고 영향과 되돌리기 가능성으로 등급을 조정하고 거부율, 만료율, 승인 후 오류와 우회 시도를 함께 봐야 합니다.

NIST AI RMF와 생성형 AI 프로필은 자발적 지침이며 산업별 법적 의무를 대신하지 않습니다. 금융, 의료, 고용과 공공 서비스는 보안·준법 검토가 별도로 필요합니다.

첫 배포에서는 읽기 전용 업무 하나를 고르세요. 신원, 정책 판정, 승인과 실행 결과로 작업을 재구성할 수 있을 때 다음 쓰기 권한을 열면 됩니다.