도입 상담 신청
블로그 목록 도입과 관리

AI 에이전트 보안, 작업 등급별 권한과 승인 절차 설계

AI 에이전트 보안, 작업 등급별 권한과 승인 절차 설계

AI 에이전트 보안의 핵심은 작업을 위험도에 따라 등급으로 나누는 것입니다. 등급마다 권한과 승인 방식을 정하고, 지시문이 아니라 시스템 설정으로 적용합니다.

읽기 작업은 자동으로 허용합니다. 게시나 설정 변경처럼 외부에 반영되는 작업은 실행 직전에 멈추고 사람이 승인합니다. 승인자가 응답하지 않으면 실행하지 않도록 설정합니다. 이상 신호가 보이면 권한 범위부터 다시 점검합니다.

AI 에이전트 권한은 어떤 기준으로 등급을 나누나요?

OWASP는 대형 언어 모델 애플리케이션의 10대 위험을 정리해 공개합니다. 그 2025년판 문서는 과도한 권한(Excessive Agency)의 원인을 세 가지로 설명합니다. 필요 이상의 기능, 필요 이상의 권한, 필요 이상의 자율성입니다.

잘못된 출력은 환각이나 프롬프트 주입(입력에 숨긴 지시로 모델을 조종하는 공격)에서 생길 수 있습니다. 문서는 이런 출력이 나와도 피해가 커지지 않도록 세 원인을 줄이라고 설명합니다.

Anthropic의 Claude Code 권한 문서도 도구 유형별로 승인 방식을 나눕니다. 작업 폴더 안의 파일 읽기는 승인 없이 실행됩니다. 파일 수정과 셸 명령은 수동 모드에서 실행 전에 승인을 묻습니다. 실무에서는 이 구분을 SEO·GEO 업무에 맞게 네 등급으로 나누는 방법을 권합니다.

등급작업 예주는 권한승인 방식
1. 조회검색 실적 내려받기, 페이지 수집, 순위 기록 읽기읽기 전용승인 없이 실행하고 기록만 남김
2. 내부 초안원고·메타 설명 초안, 작업 폴더 저장작업 폴더 쓰기결과물 검수로 대신함
3. 외부 반영글 게시·수정, 리디렉션·robots.txt 변경, 사이트맵 제출해당 도구 하나의 쓰기 권한실행 직전에 건별 승인
4. 권한·계정사용자 추가·삭제, 소유권 확인, 결제주지 않음사람이 직접 수행

등급은 두 가지 기준으로 정합니다. 작업을 되돌릴 수 있는지, 그리고 외부에 보이는지입니다. 초안은 버리면 끝납니다. 반면 게시된 글과 바뀐 리디렉션은 검색 엔진이 이미 수집했을 수 있습니다. 그래서 같은 쓰기 작업이라도 2등급과 3등급으로 나뉩니다.

권한 제한을 지시문이 아니라 시스템 설정으로 적용하는 이유는 무엇인가요?

OWASP 문서는 완전 중재(complete mediation)를 권합니다. 허용 여부 판단을 모델에 맡기지 않고, 연결된 하위 시스템이 모든 요청을 보안 정책과 대조하는 방식입니다.

Claude Code 문서는 권한 규칙을 거부, 확인, 허용 순서로 평가한다고 설명합니다. 이 순서에서 처음 일치한 규칙이 결과를 정합니다. 넓은 거부 규칙에 걸리면 더 좁은 허용 규칙이 있어도 호출이 막힙니다.

OpenAI의 에이전트 안내서는 부작용을 일으키는 도구 바로 옆에 검증을 두라고 설명합니다. 게시·삭제·발송처럼 결과가 남는 도구가 이에 해당합니다.

OWASP 문서의 공격 사례는 이 차이를 잘 보여 줍니다. 메일함에 접근하는 비서가 받은 메일 속 숨은 지시에 속았습니다. 그 결과 민감한 정보를 공격자에게 전달했습니다. 문서가 제시한 대책은 세 가지입니다. 메일 읽기 기능만 연결하고, 읽기 전용 인증 범위를 쓰고, 작성된 메일은 사용자가 검토해 직접 보냅니다.

SEO·GEO 업무에서 에이전트는 경쟁 페이지와 고객 문의처럼 외부에서 들어온 글을 자주 읽습니다. 실무에서는 「게시하지 않는다」는 지시를 쓰는 데서 그치지 않는 방법을 권합니다. 해당 업무에는 게시 도구를 아예 연결하지 않습니다.

승인 절차는 어떤 순서로 설계하나요?

OpenAI 안내서는 승인 흐름을 이렇게 설명합니다. 승인이 필요한 도구 호출이 나오면 도구를 실행하지 않고 실행이 멈춥니다. 승인하거나 거절하면 저장된 상태에서 같은 실행을 이어 갑니다. 검토가 오래 걸리면 상태를 저장하고 나중에 재개할 수 있습니다.

같은 안내서의 사이버보안 작업 흐름 부분은 검토가 시간 초과되거나 불가능해지면 실행하지 않는 쪽(fail closed)으로 처리하라고 설명합니다. 실무에서는 이 원칙을 모든 3등급 작업에 적용하는 방법을 권합니다. 설계 순서는 다음과 같습니다.

  1. 3등급 도구마다 승인 필요 설정을 켭니다.
  2. 승인 범위 밖의 요청은 승인을 묻지 않고 바로 거부합니다.
  3. 범위 안의 3등급 요청은 모두 실행 직전에 멈추고 승인 요청을 보냅니다.
  4. 승인·거절 결과와 사유, 승인자, 시각을 기록합니다.
  5. 정한 기한 안에 응답이 없으면 실행하지 않고 요청을 종료합니다.

승인자가 판단하려면 요청서에 필요한 정보가 모두 들어 있어야 합니다. 다음 양식은 그대로 따라 쓸 수 있습니다.

  • 요청 작업: 게시된 글 1건의 제목·메타 설명 수정
  • 대상: 페이지 주소, 바뀌는 항목 이름
  • 변경 전·후: 바뀌는 문구를 나란히 표시
  • 근거: 검수 통과 회차와 참고한 자료 이름
  • 되돌리는 방법: 이전 버전 번호와 복원 절차
  • 응답 기한: 기한까지 응답이 없으면 실행하지 않음

실무에서는 에이전트를 운영하는 사람과 승인자를 다른 사람으로 정하는 방법을 권합니다. 요청을 만든 사람이 직접 승인하면 확인이 형식에 그치기 쉽습니다.

Search Console 같은 검색 도구 권한은 어떻게 주고 회수하나요?

Google Search Console 도움말은 권한을 네 종류로 설명합니다. 소유자, 전체 사용자, 제한된 사용자, 연결된 사용자(associate)입니다.

  • 소유자: 속성을 완전히 제어하며 사용자를 추가·삭제하고 모든 데이터를 봅니다. 확인 토큰으로 소유권을 증명한 확인된 소유자와, 확인된 소유자가 토큰 없이 지정한 위임된 소유자가 있으며 권한은 같습니다.
  • 전체 사용자: 모든 데이터를 볼 수 있고 일부 작업을 할 수 있습니다.
  • 제한된 사용자: 대부분의 데이터를 단순 조회할 수 있습니다.
  • 연결된 사용자: 사이트를 대신해 활동하거나 특정 데이터에 접근하는 사람·계정입니다. Search Console 계정과 데이터를 직접 열어 보지는 못합니다.

실무에서는 필요한 가장 낮은 권한부터 주는 방법을 권합니다. 에이전트가 쓰는 계정은 사람 계정과 분리합니다. 실적 수집만 하는 에이전트라면 제한된 사용자로 시작합니다.

OWASP 문서도 모든 사용자의 파일에 접근하는 고권한 공용 계정을 위험 사례로 듭니다. 대책은 해당 사용자의 맥락에서 필요한 최소 권한으로 실행하는 것입니다.

회수할 때는 확인 토큰을 함께 정리합니다. 도움말은 사용자의 확인 토큰이 남아 있으면 삭제된 소유자가 다시 소유권을 확인할 수 있다고 설명합니다. 그래서 소유자를 삭제할 때 그 사용자의 확인 토큰도 모두 삭제합니다.

확인된 소유자는 사람 계정으로 최소 한 명 유지합니다. 도움말은 확인된 소유자가 모두 삭제되면 남은 사용자와 위임된 소유자도 유예 기간 뒤 접근 권한을 잃는다고 설명합니다.

도움말에서는 소유자 추가·삭제 이력도 확인할 수 있습니다. 모르는 소유자가 보이면 해킹되었을 수 있다고도 설명합니다. 실무에서는 이 이력을 정기적으로 점검하는 방법을 권합니다.

어떤 이상 신호가 보이면 권한과 승인 설계를 다시 점검하나요?

OWASP 문서는 활동 기록·감시와 실행 횟수 제한을 피해를 줄이는 통제로 소개합니다. 둘 다 과도한 권한 자체를 막지는 못합니다. 대신 잘못된 행동을 발견하고 피해가 커지기 전에 막을 수 있게 합니다. 다음 표는 기록에서 찾을 이상 신호와 원인 후보를 짝지은 것입니다.

이상 신호원인 후보먼저 점검할 것
요청하지 않은 삭제·발송·게시 시도가 기록됨불필요한 기능 연결, 읽은 자료 속 숨은 지시연결된 도구 목록, 직전에 읽은 외부 자료
승인 없이 외부 반영이 실행됨승인이 지시문에만 있고 도구 설정에는 없음도구별 승인 설정, 거부 규칙 순서
승인 요청이 너무 많아 내용 확인 없이 승인함2등급 작업까지 승인 대상에 포함됨등급 분류, 요청서 항목
승인자 부재 중 작업이 진행됨시간 초과 시 실행하도록 설정됨시간 초과 처리 방식
짧은 시간에 수정이 대량으로 발생함실행 횟수 제한 없음시간당 실행 한도, 감시 알림
기록에서 실행자와 승인자를 구분할 수 없음공용 계정 사용, 기록 항목 누락에이전트 전용 계정, 기록 양식
검색 도구 소유자 목록에 모르는 계정이 있음회수 때 남은 확인 토큰, 사이트 침해소유자 추가·삭제 이력, 남은 확인 토큰

예를 들어 가상의 ○○ 기업이 주간 회의 때 기록을 점검한다고 가정합니다. 이 기업은 표의 일곱 줄을 차례로 대조하고, 해당하는 신호가 있으면 다음 실행 전에 원인을 확인합니다.

원인이 확인될 때까지는 그 에이전트를 2등급 권한으로 낮춰 운영합니다. 조회와 내부 초안은 계속하되 외부 반영만 막는 방식입니다.

정리

  1. 에이전트가 하는 작업을 조회, 내부 초안, 외부 반영, 권한·계정의 네 등급으로 분류합니다.
  2. 등급별로 연결할 도구와 계정 권한을 정하고, 지시문이 아니라 도구 설정과 계정 권한으로 적용합니다.
  3. 외부 반영 도구에 승인 설정을 켜고, 승인 요청서 양식과 응답이 없을 때 실행하지 않는 처리를 정합니다.
  4. Search Console 등 검색 도구에는 에이전트 전용 계정을 가장 낮은 권한으로 추가하고, 소유자 이력을 점검합니다.
  5. 이상 신호 표로 실행 기록을 주기적으로 대조하고, 신호가 보이면 권한을 낮춘 뒤 원인을 확인합니다.

참고 자료

오늘 밤부터 맡겨 보십시오

맡기실 업무와 월 처리량을 알려 주시면 구성과 요금을 함께 정리합니다.

도입 상담 신청