AI 에이전트 권한분리 운영계약 설계

AI 에이전트에 저장소 읽기, 이슈 정리, 테스트 실행, 클라우드 조회 같은 도구를 연결하면 모델은 대화 상자보다 넓은 작업을 수행할 수 있다. 동시에 위험도 바뀐다. 모델이 잘못된 답을 내는 문제와, 잘못된 도구를 올바른 형식으로 호출하는 문제는 같은 방식으로 막을 수 없다. 프롬프트에 “배포하지 말라”고 적는 일은 의도를 전달할 뿐, 권한을 기술적으로 줄이거나 실행 이력을 남기지는 않는다.

Google Threat Intelligence Group은 2026년 9월 8일 AI Threat Tracker에서 위협 행위자가 기본 프롬프팅에서 AI 기반 자율 워크플로로 이동하는 흐름을 관찰했다고 밝혔다. 보고서는 AI 코딩 보조와 오픈소스 공급망의 결합으로 개발자·AI 도구·LLM 보안 스캐너가 공격 표면이 될 수 있다고 설명한다. 이 글은 그 관찰을 “모든 에이전트가 침해된다”는 예측으로 바꾸지 않는다. 대신 에이전트에 권한을 줄 때 팀이 먼저 정해야 할 분리 지점을 다룬다.

권한을 좁히는 관점은 AI에만 새로 생긴 규칙이 아니다. NIST SP 800-207은 네트워크 위치나 자산 소유만으로 암묵적 신뢰를 부여하지 않고, 기업 자원에 세션을 만들기 전에 인증과 인가를 별도 기능으로 수행하는 제로 트러스트 관점을 설명한다. 이 글은 그 문서를 AI 에이전트용 제품 설정으로 해석하지 않는다. 다만 에이전트가 쓰는 도구와 자격 증명도 ‘내부에서 실행되니 괜찮다’는 전제로 넓게 주기보다, 자원·작업·세션 단위로 질문해야 한다는 보조 근거로 사용한다.

1. 최신 보고서가 말하는 변화는 모델의 위험만이 아니다

원문 사실 카드

GTIG 보고서는 공격자가 AI 에이전트를 이용해 스캔 파이프라인을 관리하고 운영 오류를 해결하며 자격 증명 수집을 자동화하는 방향을 언급한다. 또 API 자격 증명, 모델·소스코드, 클라우드 컴퓨팅 자원이 표적이 될 수 있다고 설명한다. 이것은 특정 제품의 결함 목록이나 모든 조직에서 확인된 사고 통계가 아니다. 위협 인텔리전스 조직이 관찰한 활동과 방어자가 봐야 할 공격 표면의 변화다.

따라서 첫 질문은 “이 모델이 안전한가” 하나가 아니다. 에이전트가 실제로 접근 가능한 저장소, 문서, 비밀, 도구, 네트워크 목적지는 무엇인가를 묻는 편이 더 구체적이다. 읽기 전용 문서 검색과 운영 환경의 설정 변경은 모두 도구 호출일 수 있지만, 실수했을 때의 복구 비용과 검토 근거는 다르다. 동일한 토큰이나 서비스 계정으로 두 행동을 묶으면, 작은 작업을 위해 넓은 실패 반경을 함께 열어 두게 된다.

작동 원리 해설

권한분리는 모델의 추론 과정을 판별하려는 장치가 아니다. 요청이 도착했을 때 무엇을 읽을 수 있는가, 무엇을 제안할 수 있는가, 무엇을 실제로 바꿀 수 있는가를 다른 경로로 다루는 장치다. 읽기 경로는 대상 데이터와 검색 범위를 제한한다. 제안 경로는 패치·명령·설정 초안을 만들 수 있지만 외부 상태를 바꾸지 않는다. 실행 경로는 좁은 범위의 자격 증명, 승인 조건, 감사 기록을 추가로 요구한다.

이 구분은 자동화를 포기하자는 뜻이 아니다. 테스트처럼 격리된 환경에서 반복되는 실행은 사전 정의한 입력과 권한으로 자동화할 수 있다. 하지만 프로덕션 설정 변경, 외부 전송, 권한 부여, 비밀 조회처럼 되돌리기 어렵거나 영향이 넓은 동작은 같은 경로에 두지 않는 편이 낫다. ‘사람이 검토한다’는 문장보다, 어떤 호출이 어느 권한 게이트를 지나야 하는지 적는 편이 실제 통제에 가깝다.

2. 도구를 열기 전에 확인할 제약 조건

제약 조건 매트릭스

표는 제품 설정값을 대신하지 않는다. 예를 들어 읽기 권한은 안전하다고 자동으로 말할 수 없다. 로그와 문서에도 토큰·개인정보·운영 구조가 포함될 수 있기 때문이다. 반대로 실행 권한이 있다고 해서 매번 사람의 클릭을 요구해야 하는 것도 아니다. 제한된 테스트 환경에서 미리 정한 명령을 실행하는 일과, 고객 데이터가 있는 환경의 설정을 바꾸는 일은 분리해 자동화 수준을 다르게 둘 수 있다.

3. PR 리뷰 에이전트에 계약을 적용하는 방법

실제 순서 흐름도

아래는 특정 제품의 설정, 검증 결과, 또는 실제 조직 사례가 아니다. GTIG의 관찰과 제로 트러스트의 자원 중심 관점을 바탕으로, 팀이 PR 리뷰 에이전트에 적용해 볼 수 있는 편집부 제안이다. 이 작업을 고른 이유는 리뷰 초안 생성은 유용하지만, 병합·라벨 변경·비밀 접근 같은 쓰기 권한 없이도 시작할 수 있기 때문이다.

제안 정책 예시

다음은 실행 가능한 권한 설정 파일이 아니라, 승인 전에 팀이 합의할 항목을 구체화한 편집부 제안이다. 사용 중인 Git 호스트, CI, 비밀 관리 도구의 실제 문법과 권한 모델로 검토·변환해야 한다.

# PR 리뷰 에이전트 운영 계약 예시 — 개념용, 미실행

작업: "승인된 저장소의 PR 리뷰 초안"
입력:
  허용: "PR 번호, 변경 diff, 명시된 코드 경로"
  제외: "비밀 파일, 배포 자격 증명, 고객 데이터 경로"
도구:
  읽기: "PR diff와 지정 파일 조회만"
  제안: "리뷰 초안과 근거 위치 생성만"
  실행: "코멘트 게시, 라벨 변경, 병합, 워크플로 실행은 허용하지 않음"
보류:
  - "입력이 허용 범위를 벗어남"
  - "비밀·개인정보 가능성이 있는 경로를 만남"
  - "리뷰 근거 위치를 특정할 수 없음"
기록:
  - "입력 PR과 읽은 경로"
  - "제안한 항목과 근거 위치"
  - "사람이 채택·수정·보류한 이유"

이 예시가 보여 주는 핵심은 ‘리뷰 에이전트’라는 이름으로 권한을 주지 않는다는 점이다. 같은 이름의 도구라도 어떤 저장소, 어떤 이벤트, 어떤 파일, 어떤 외부 호출을 허용하는지에 따라 실패 반경이 달라진다. NIST 문서가 말하는 자원 중심의 관점도 여기에서 도움이 된다. 에이전트 자체를 신뢰하거나 불신하는 이분법 대신, 접근하려는 자원과 세션마다 인증·인가·기록의 근거를 확인하는 질문으로 바꿀 수 있다.

검증 절차

계약 초안을 만든 뒤에는 기능 시연보다 먼저 경계를 확인한다. 먼저 허용된 PR과 허용되지 않은 경로를 각각 넣어 조회 범위가 실제로 좁아지는지 확인한다. 다음으로 에이전트가 코멘트 게시이나 라벨 변경을 시도했을 때, 권한 거부가 남고 초안만 반환되는지 본다. 마지막으로 한 리뷰 제안에서 입력 PR, 읽은 파일, 근거 위치, 사람의 최종 결정이 연결되는지 살핀다. 이 검증은 안전을 보장하는 인증 절차가 아니라, 계약과 실제 도구 동작이 어긋나는 지점을 찾기 위한 운영 점검이다.

▲ 자격 증명·승인·감사 기록과 예외 처리를 한 경로로 묶지 않는 관계를 보여줍니다.

4. 팀의 운영 계약으로 남기는 최소 기록

검토 기록·체크리스트

다음 양식은 GTIG의 공식 운영 절차가 아니라, 위협 보고서의 관찰을 팀의 도구 연결 결정에 과장 없이 옮기기 위한 편집부 제안이다. 기존 IAM 정책, 보안 검토, 변경 승인, 사고 대응 절차를 대체하지 않는다.

# AI 에이전트 도구 권한 운영 계약

- 작업 목적과 사용자 영향:
- 에이전트가 읽을 수 있는 대상과 제외 대상:
- 제안만 가능한 도구와 실제 실행 도구:
- 실행에 필요한 서비스 계정·토큰의 최소 범위와 만료:
- 별도 승인이 필요한 동작: 권한 변경 / 외부 전송 / 배포 / 데이터 변경
- 실행 전 확인할 입력·환경·되돌리기 경로:
- 실행 뒤 남길 로그·감사 기록·관찰 신호:
- 예외 요청의 승인자·유효 기간·재검토 날짜:
- 아직 확인하지 못한 조건과 보류 이유:

이 기록에서 중요한 것은 도구 목록을 길게 적는 일이 아니다. 하나의 도구가 어떤 데이터와 어떤 권한을 만나는지, 작업이 끝난 뒤 무엇을 남기는지 짧게 연결하는 일이다. 서비스 계정은 사람의 계정을 대신하는 편의 기능이 아니라, 에이전트가 할 수 있는 행동의 경계를 정의하는 신원이다. 토큰을 오래 유지하거나 여러 작업이 공유하면 실행은 편해질 수 있지만, 나중에 한 호출의 책임·대상·만료 조건을 찾기 어려워진다.

실패 모드와 완화책

가장 흔한 실패는 ‘읽기 전용’이라는 이름만 믿고 자료의 민감도와 유출 경로를 확인하지 않는 경우다. 다음은 도구가 할 수 있는 일과 실제 작업에 허가된 일을 구분하지 않는 경우다. 마지막은 예외 승인을 한 번 받았다는 사실이 영구 권한처럼 남는 경우다. 이 세 경우는 모델의 품질과 무관하게 발생한다. 따라서 실패를 감지하는 신호도 모델 답변의 정확도만으로 정할 수 없다. 예상하지 않은 경로의 조회, 범위를 벗어난 명령, 만료되지 않은 예외 토큰, 감사 기록의 누락을 함께 봐야 한다.

실행이 실패했을 때 재시도만 반복하지 않도록 중단 조건도 정해 둔다. 권한 거부는 프롬프트를 더 길게 써서 우회할 이유가 아니라, 해당 작업에 그 권한이 필요한지 다시 판단하라는 신호일 수 있다. 예상하지 않은 입력이나 민감 자료가 발견되면 결과를 계속 처리하기보다 격리하고 담당자에게 넘긴다. 이러한 중단 경로가 있어야 자동화가 빨라진 뒤에도 손실을 좁은 범위에 묶을 수 있다.

도입 순서를 정하는 세 가지 질문

권한을 분리하는 일은 대형 플랫폼을 도입하는 프로젝트로 시작할 필요가 없다. 먼저 실제 업무 요청 열 개 정도를 모아, 각각이 읽기·제안·실행 중 어디까지 가는지 표시해 볼 수 있다. 이때 “에이전트가 할 수 있으면 편하다”는 기준 대신, 사람이 같은 일을 할 때도 별도 변경 요청이나 승인 기록을 남겼는지를 기준으로 삼는다. 사람이 별도 권한 없이 하지 못하는 작업이라면 에이전트에도 같은 경계를 적용하는 편이 일관적이다.

둘째 질문은 권한을 어디에 둘 것인가다. 대화 세션에 넓은 비밀을 넣는 방식보다, 작업 단위로 범위와 만료가 제한된 자격 증명을 기존 실행 파이프라인에서 발급하는 방식이 추적하기 쉽다. 여기서 토큰 자체를 본문 로그에 남기라는 뜻은 아니다. 어떤 신원으로, 어떤 도구에, 어느 시간까지, 어떤 승인 근거 아래 접근했는지를 남기라는 뜻이다. 감사 기록은 사후에 누군가를 탓하기 위한 문서가 아니라, 예상 밖 호출을 정상 작업과 구별하기 위한 운영 데이터다.

셋째 질문은 거부했을 때의 경험이다. 권한 게이트가 단순히 “안 됩니다”만 반환하면 사용자는 더 넓은 공용 계정이나 우회 경로를 찾기 쉽다. 거부 응답에는 부족한 승인 유형, 허용되는 대안 경로, 재검토 담당자처럼 다음 행동을 안내할 수 있다. 예를 들어 프로덕션 쓰기가 막혔다면 에이전트는 변경 초안과 검증 결과까지만 만들고, 기존 변경 관리 절차에 제출할 수 있다. 이렇게 하면 생산성을 위해 통제를 포기하는 대신, 생산성과 통제를 서로 다른 단계에 배치할 수 있다.

운영 계약도 고정 문서가 아니다. 새 도구를 붙이거나 서비스 계정의 범위가 바뀌거나 사고·오탐이 발생했을 때 계약의 입력과 중단 조건을 다시 본다. 검토 주기를 정하지 않으면 일회성 예외가 누적되어 설계 당시보다 더 넓은 권한이 남는다. 반대로 모든 항목을 매주 처음부터 승인하면 현업이 계약을 우회할 가능성이 높다. 변화가 큰 실행 경로와 안정적인 읽기 경로에 서로 다른 재검토 주기를 두는 방식이 현실적이다.

처음부터 모든 권한을 수치화할 필요도 없다. 다만 각 경로에 책임자를 한 명씩 두고, 실제 호출 표본을 함께 검토하면 빈틈이 빨리 드러난다. 운영 담당자는 시스템 영향과 롤백 가능성을, 보안 담당자는 신원과 비밀 노출 가능성을, 업무 담당자는 작업 목적과 허용 범위를 확인한다. 세 역할이 같은 기록을 보아야 ‘누가 승인했는가’와 ‘무엇을 승인했는가’가 분리되지 않는다. 계약은 승인자의 이름만 남기는 서류가 아니라, 다음 검토자가 당시의 판단을 재구성할 수 있게 하는 최소한의 맥락이다.

5. 자율성을 넓히지 않는 선택도 운영 전략이다

반론·대안 경로

모든 팀이 복잡한 권한 게이트웨이를 새로 만들 필요는 없다. 도구가 문서 검색과 로컬 초안 생성에만 쓰이고 외부 쓰기·비밀 접근이 없다면, 명시적 금지 목록과 저장소 범위 제한만으로도 충분할 수 있다. 반대로 이미 승인된 배포 자동화가 있다면 에이전트에 새 권한을 주기보다, 기존 파이프라인에 변경 요청을 넘기고 그 파이프라인의 승인·감사·롤백을 재사용하는 편이 낫다.

핵심은 AI 에이전트를 가장 넓은 권한의 새 운영자로 만드는 데 있지 않다. 팀이 이미 이해하는 신원·권한·승인·감사 경계 안에 에이전트의 작업을 넣는 데 있다. 자율성을 높이기 전에 “이 호출이 실패하거나 오용되면 어디에서 멈추는가”를 답할 수 없다면, 더 많은 도구를 연결하지 않는 것이 합리적인 운영 결정일 수 있다.

출처와 적용 범위

• GTIG AI Threat Tracker: From Prompting to Autonomy — 2026년 9월 8일 Google Threat Intelligence Group이 공개한 관찰과 공격 표면 설명이다. 본문은 이를 모든 AI 도구나 조직에 대한 침해 예측으로 일반화하지 않았다.
• NIST SP 800-207: Zero Trust Architecture — 위치·소유만으로 암묵적 신뢰를 부여하지 않고 자원 접근 전 인증·인가를 분리하는 제로 트러스트의 일반 원칙이다. 이 글의 PR 리뷰 계약은 NIST의 AI 에이전트 제품 설정이 아니라, 그 원칙을 검토 질문으로 옮긴 편집부 제안이다.