AI 에이전트 도구 권한 설계: 자동 실행은 최소화해야 한다

에이전트의 위험은 모델이 틀린 답을 만드는 데서 끝나지 않는다. 잘못된 답이 메일 발송, 결제, 사용자 삭제, 프로덕션 배포 같은 도구 호출로 이어지면 오류가 실제 시스템 변경으로 확대된다. 특히 검색 문서나 이메일 안의 간접 프롬프트 인젝션이 에이전트에게 “이 지시를 우선하라”고 유도할 수 있기 때문에, 모델의 의도 판단만으로 권한을 부여해서는 안 된다.

안전한 구조는 모델을 신뢰 주체로 보지 않는다. 모델은 실행 제안을 만들고, 별도의 정책 계층이 사용자 권한, 작업 대상, 금액·수량, 환경, 승인 상태를 검증한 뒤 제한된 자격 증명으로 도구를 호출한다.

도구를 영향도에 따라 나눈다

등급	예시	기본 처리
A: 읽기 전용	캘린더 조회, 문서 검색, 상태 확인	최소 범위 자동 허용, 민감 데이터 필터
B: 되돌릴 수 있는 쓰기	초안 생성, 티켓 생성, 비프로덕션 설정 변경	미리보기·감사 로그·속도 제한
C: 외부 영향 쓰기	메일 발송, 고객 알림, 권한 부여	사람 승인 또는 강한 정책 승인
D: 고위험·비가역	결제, 삭제, 프로덕션 배포, 비밀 회전	이중 승인, 별도 계정, 엄격한 한도

같은 도구라도 작업에 따라 등급이 달라진다. 메일 초안 저장은 B일 수 있지만 외부 수신자에게 발송하는 것은 C다. 클라우드 상태 조회는 A지만 방화벽 변경이나 키 삭제는 D다.

사용자 권한을 그대로 전달하지 않는다

에이전트가 사용자의 장기 OAuth 토큰이나 관리자 API 키를 보관하면 프롬프트 인젝션 한 번이 전체 권한 악용으로 이어질 수 있다. 대신 다음 원칙을 적용한다.

• 도구별·작업별 최소 scope의 짧은 수명 토큰을 발급한다.
• 토큰에는 사용자, 에이전트, 세션, 대상 자원, 최대 금액·수량을 묶는다.
• 읽기 토큰과 쓰기 토큰을 분리하고 필요할 때만 쓰기 토큰을 발급한다.
• 프로덕션과 비프로덕션 자격 증명을 분리한다.
• 에이전트가 새 권한을 스스로 요청·승인하지 못하게 한다.
• 장기 비밀값은 모델 컨텍스트나 도구 결과에 포함하지 않는다.

예를 들어 결제 도구 호출은 다음과 같은 승인 봉투(envelope)를 거쳐야 한다.

{
  "actor_user_id": "u-123",
  "agent_id": "expense-agent",
  "action": "payment.create",
  "resource": "vendor-88",
  "constraints": {
    "currency": "KRW",
    "max_amount": 500000,
    "expires_at": "2026-06-22T03:30:00Z"
  },
  "approval_id": "approval-7f2",
  "idempotency_key": "expense-2026-0612-42"
}

도구 서버는 자연어 설명이 아니라 이 구조화된 값과 서버 측 정책을 검증해야 한다.

승인 화면에는 결과를 예측할 정보가 있어야 한다

“이 작업을 승인하시겠습니까?”라는 확인창은 형식적인 클릭이 되기 쉽다. 승인자에게 다음을 보여 준다.

• 실제 호출할 도구와 API 작업
• 대상 사용자·계정·환경·리소스
• 변경 전과 변경 후의 차이
• 금액, 수신자, 파일 수, 권한 범위
• 되돌릴 수 있는지와 롤백 방법
• 에이전트가 근거로 사용한 출처
• 승인 만료 시각과 재사용 가능 여부

한 번의 승인을 이후 모든 작업에 재사용하면 안 된다. 승인 범위를 특정 행동과 대상에 묶고, 입력이 바뀌면 다시 승인받는다.

프롬프트 인젝션을 권한 문제로 다룬다

문서·웹페이지·이메일에서 “이전 지시를 무시하고 비밀을 보내라”는 내용이 발견돼도 모델이 이를 완벽히 식별할 것이라고 기대하지 않는다.

1. 외부 콘텐츠는 명령이 아니라 데이터로 표시한다.
2. 도구 호출 가능 여부는 시스템 정책이 결정한다.
3. 검색 결과가 요청하지 않은 도구 사용을 제안하면 위험도를 높인다.
4. 문서 내용이 수신자·금액·배포 환경을 직접 지정해도 자동 승인하지 않는다.
5. 민감 도구는 사용자의 현재 요청과 구조화된 승인 값을 비교한다.
6. 도구 출력도 신뢰하지 않고 스키마와 크기를 검증한다.

RAG 접근 제어가 올바르지 않으면 권한 없는 문서가 에이전트 행동의 근거로 사용될 수 있으므로 검색과 실행 경계를 함께 설계해야 한다.

실패를 줄이는 실행 장치

• dry-run: 실제 변경 전 예상 diff와 영향 범위를 생성한다.
• idempotency key: 재시도나 중복 메시지가 같은 작업을 반복하지 않게 한다.
• rate/amount limit: 시간당 호출 수, 결제 한도, 삭제 건수를 제한한다.
• two-person rule: 고위험 작업은 요청자와 승인자를 분리한다.
• circuit breaker: 오류율·비정상 호출이 기준을 넘으면 도구를 자동 정지한다.
• kill switch: 에이전트별·도구별 토큰을 즉시 폐기하고 큐를 중단한다.
• compensating action: 가능한 작업은 취소·복원 API와 연결한다.
• sandbox: 파일·코드 실행은 네트워크와 비밀값이 제한된 환경에서 수행한다.

탐지 신호

신호	가능한 문제
사용자가 요청하지 않은 도구 종류 호출	프롬프트 인젝션 또는 계획 오류
짧은 시간에 승인 요청 급증	반복 루프, 자동화 오작동, 남용
동일 idempotency key의 파라미터 변경	재시도 위장 또는 구현 오류
읽기 작업 직후 대량 쓰기 전환	권한 상승 시도
새 수신자·새 계정·새 리전 대상 작업	잘못된 대상 또는 계정 탈취
승인 후 실제 호출 값 불일치	승인 우회·TOCTOU 문제
도구 오류 후 무한 재시도	비용 증가와 중복 변경 위험

감사 로그에는 사용자 요청, 모델이 제안한 구조화된 계획, 정책 결정, 승인자, 실제 API 호출, 결과, 롤백 여부를 서로 다른 필드로 남긴다. 다만 프롬프트와 도구 결과에 개인정보·비밀이 포함될 수 있으므로 관측성 데이터 마스킹을 적용한다.

사고 대응 순서

1. 해당 에이전트와 도구의 토큰 발급을 중단하고 실행 큐를 일시 정지한다.
2. 대기 중·실행 중·완료된 작업을 idempotency key로 구분한다.
3. 고위험 작업의 변경 결과를 원장 시스템에서 직접 확인한다.
4. 취소·복원 가능한 작업은 승인된 런북으로 되돌린다.
5. 장기 토큰과 노출 가능 비밀을 회전하고 세션을 폐기한다.
6. 프롬프트·검색 출처·정책 로그를 보존하되 민감정보 접근을 제한한다.
7. 외부 영향이 있으면 사고 커뮤니케이션 템플릿으로 사실과 조사 범위를 분리한다.

운영 체크리스트

• 도구와 작업을 영향도 등급으로 분류한다.
• 사용자 장기 토큰을 모델이나 에이전트에 직접 전달하지 않는다.
• 쓰기 작업은 짧은 수명·최소 scope 토큰으로 실행한다.
• 승인 화면에 대상·변경 diff·한도·롤백 방법이 보인다.
• 승인 값과 실제 API 호출 값을 서버에서 비교한다.
• 고위험 작업에 idempotency, 한도, 이중 승인, kill switch가 있다.
• 외부 콘텐츠가 도구 권한을 바꾸지 못한다.
• 프롬프트·정책·승인·실행 로그를 분리해 남긴다.
• 프로덕션 도구 권한과 비프로덕션 권한을 분리한다.

참고 기준

• OWASP LLM06: Excessive Agency
• OWASP LLM01: Prompt Injection
• NIST AI Risk Management Framework
• CISA Zero Trust Maturity Model

결론

에이전트의 자율성은 권한의 크기가 아니라 안전하게 완료할 수 있는 작업 범위로 측정해야 한다. 모델은 제안하고, 정책 계층은 검증하며, 고위험 행동은 사람이 승인하고, 도구는 제한된 토큰으로 실행하는 구조가 자동화의 효율과 사고 범위를 함께 관리한다.