사이버 보안

AI 에이전트의 권한은 왜 0에서 시작해야 하는가?

실제 실험은 작업에 따라 AI 에이전트의 권한을 제한하면 작업 완료에 실질적인 영향을 주지 않으면서도 피해 범위를 줄일 수 있음을 보여준다. 반면 고정 권한 역할은 어떤 부분에서는 지나치게 광범위하고 다른 부분에서는 부족하기 때문에 실패할 수 있다. 이 글은 모델이나 지시가 바뀌더라도 최소 권한 원칙이 가장 안정적인 방어선으로 남는다고 결론짓는다.

2026-10-15
3 분 읽기
32 조회수
certi.news Editorial Team
AI 에이전트의 권한은 왜 0에서 시작해야 하는가?

The New Stack에 게재된 실험은 AI 에이전트에게 필요한 범위를 넘어선 권한을 부여하면 단순한 논리적 오류가 에이전트 스스로 중단하지 못하는 반복적인 금융 조치로 이어질 수 있음을 보여준다. 고객 청구서 테스트에서 지원 에이전트는 결제가 실패했고 고객의 자금이 인출되지 않았다고 확인했지만, 주어진 정보가 이를 뒷받침하지 않았음에도 환불을 실행했으며 같은 오류를 다섯 번 반복했다.

Claude Sonnet 5는 이 결함을 시험하기 위해 설계된 여섯 가지 상황을 모두 발견했지만, Claude Haiku 4.5는 모두 실패했다. 또한 금융 조치를 실행하기 전에 거래 상태를 확인하라는 한 줄의 시스템 지시를 추가하자 문제가 처리되었다. 그러나 필자는 두 해결책 모두 취약하다고 본다. 조직이 모델을 더 저렴한 버전으로 교체하거나 실험 중 지시를 수정하면 명확한 경고 없이 보호 기능이 사라질 수 있기 때문이다.

보안 장벽으로서의 거부된 권한

이러한 변경에도 견뎌낸 보호책은 애초에 에이전트가 billing:refund 권한을 보유하지 못하도록 하는 것이었다. 그러면 모델이나 지시의 표현과 관계없이 권한 계층에서 실행이 실패한다. 이것이 AI 에이전트 아키텍처에서 최소 권한 원칙이 의미하는 바다. 목표는 공격자를 막거나 비밀 토큰을 보호하는 데 그치지 않고, 선의의 에이전트가 잘못된 지시를 자동화된 방식으로 신속하게, 인간의 감독 없이 실행하지 못하도록 하는 것이다.

Advertisement

에이전트의 성격은 고정된 기능을 수행하는 전통적인 서비스 계정과 다르다. 지원 에이전트는 09:00에 티켓을 읽고, 09:04에 환불을 실행하며, 09:11에 좌석 수를 변경할 수 있다. 따라서 일주일 동안 가능한 모든 작업에 필요한 권한 집합이 특정 작업 하나에 실제로 필요한 권한을 반드시 반영하는 것은 아니다.

실험은 무엇을 측정했는가?

필자는 가상의 기업 API에서 티켓, 사용자, 청구, 구독, 파일, 메시지, 감사, 관리, 검색을 포함하는 9개 영역에 30개 권한을 배분한 테스트 환경을 구축했다. 이 가운데 13개 권한은 상태를 변경하거나 추출할 수 있었다. 실험에는 20개 작업이 포함되었으며, 각 작업에는 티켓 종료나 청구 금액 환불처럼 자동으로 검증할 수 있는 결과가 있었다.

Claude Haiku 4.5와 Claude Sonnet 5에서 네 가지 권한 모델을 비교했으며, 총 160회 실행했다.

  • 광범위한 권한: 30개 권한을 포함하는 장기 자격 증명.
  • 고정 역할: 일반적인 직무 설명에서 도출한 17개 권한을 포함하는 지원 역할.
  • 작업별 제한: 각 실행에 필요한 권한을 부여하고 실행이 끝나면 회수.
  • 즉시 활성화: 권한 없이 시작하고 필요할 때마다 사유를 명시해 각 권한을 요청.

작업별 제한은 피해 범위를 줄인다

작업별 제한 모델은 광범위한 권한 부여와 비교해 약 15분의 1에 해당하는 권한만 사용하면서 작업을 완전히 완료했다. 일시적인 거부와 재시도는 API 호출 수를 유의미하게 늘리지 않았다.

고정 역할 모델은 두 축 모두에서 가장 약했다. 17개 권한을 부여했지만 그중 4개는 어떤 작업에서도 사용되지 않았고, 반면 핵심 권한 9개가 빠져 있었다. 모든 작업이 성공하도록 역할을 확장하려면 26개 권한이 필요했지만, 작업 하나당 권한 수의 중앙값은 단 2개였다. 이처럼 고정 역할은 실제 작업이 아니라 직함을 기준으로 판단하기 때문에 지나치게 광범위하면서 동시에 부족해진다.

즉시 활성화 모델은 비슷하게 낮은 피해 범위를 달성했지만, 추가 API 호출이 약 80% 더 필요했다. 또한 작업 모델에서의 권한 거부는 대체로 선택적인 탐색 경로에 대한 것이었던 반면, 고정 역할 모델에서의 거부는 핵심 권한을 차단했기 때문에 최종적이었다.

이것이 조직에 중요한 이유

결과는 모델의 능력과 시스템 지시가 변경될 수 있는 방어 계층인 반면, 부여되지 않은 권한은 모델을 교체하거나 프롬프트를 수정하더라도 계속 효과적임을 보여준다. 따라서 팀은 현재 작업을 중심으로 에이전트 권한을 설계하고, 민감한 권한은 영구적이고 광범위한 역할에 모으기보다 일시적이며 감사 가능한 형태로 만들어야 한다.

다만 이 실험은 인공적인 환경, 20개 작업, 두 가지 Claude 모델로 제한되어 있으므로 결과가 모든 조직이나 모든 모델에서 동일하게 나타난다는 것을 입증하지는 않는다. 그럼에도 실질적으로 분명한 시사점을 제시한다. 구조상 에이전트가 필요하지 않은 행동을 실행할 수 있다면 에이전트 테스트만으로는 충분하지 않다. 모델이나 지시를 변경하면 행동은 달라질 수 있지만 피해를 일으킬 능력은 그대로 남기 때문이다.

뉴스 출처
The New Stack - Software Development
원문 보기 ↗
c
작성자

certi.news Editorial Team

핵심 내용

이 실험은 AI 에이전트에 작업과 연계된 권한을 부여하면 작업 수행에 실질적인 영향을 주지 않으면서 피해 범위를 줄일 수 있음을 보여준다. 모델이나 시스템 지침에만 의존하는 것보다 최소 권한 원칙이 더 일관된 효과를 보였지만, 결과는 합성 환경과 두 개의 모델에만 기반한다.

  • 고객 지원 에이전트가 고객 청구서를 잘못 처리하고, 입력 정보가 뒷받침하지 않았음에도 환불을 다섯 차례 실행했다.
  • billing:refund 권한을 차단하자 모델이나 지침의 문구와 관계없이 권한 계층에서 실행이 차단됐다.
  • 작업별 제한은 작업을 완전히 완료하면서도 광범위한 권한 부여와 비교해 약 15분의 1의 권한만 사용했다.
  • 고정 역할 방식은 실제 작업이 아니라 직책에 의존했기 때문에 사용하지 않는 권한을 부여하고 필수 권한은 누락했다.
  • 즉시 활성화 방식은 피해 범위를 줄였지만 추가 API 호출이 약 80% 더 필요했다.
  • 실험에는 20개 작업, 30개 권한, 두 개의 Claude 모델이 포함됐으므로 모든 조직이나 모델에서 결과가 동일하다고 입증하는 것은 아니다.

자주 묻는 질문

AI 에이전트를 보호하기에 시스템 지침만으로는 왜 충분하지 않은가?

지침은 수정될 수 있으며, 모델을 변경하거나 새로운 지침을 시험하면 명확한 경고 없이 보호 기능이 사라질 수 있기 때문이다.

작업별 제한이란 무엇인가?

특정 실행을 수행하는 데 필요한 권한을 에이전트에 부여한 뒤 작업이 끝나면 회수하는 방식이다.

고정 역할 모델의 결과는 어땠는가?

가장 약한 방식이었다. 17개 권한을 부여했지만 그중 4개는 어떤 작업에서도 사용되지 않았고, 필수 권한 9개는 누락됐다.

같은 카테고리

추천 기사

모든 뉴스 보기