AI Agent 계정 권한, API 키부터 분리해야 하는 이유
AI Agent를 업무에 연결하기 전, 사람 계정·서비스 계정·API 키·데이터 접근권한을 어떻게 분리해야 운영 사고를 줄일 수 있는지 정리했습니다.
AI Agent를 사내 업무에 붙일 때 가장 먼저 보이는 문제는 “어떤 일을 시킬까”입니다. 하지만 실제 운영에서는 그보다 먼저 정해야 할 질문이 있습니다.
이 Agent가 실패하거나 잘못 실행했을 때, 어디까지 접근하고 어디에서 멈춰야 할까?
메일, CRM, 문서함, 결제 관리, 내부 지식베이스를 한 번에 연결하면 자동화 범위는 넓어집니다. 동시에 사고 반경도 넓어집니다. 그래서 HeyRatty 관점에서는 프롬프트보다 권한 설계를 먼저 봅니다.
핵심 요약
- AI Agent는 사람 계정을 그대로 빌려 쓰기보다 업무용 서비스 계정과 제한된 API 키로 시작하는 편이 안전합니다.
- 읽기, 작성, 승인, 외부 발송 권한을 한 덩어리로 주면 작은 오류가 실제 고객 응대나 비용 집행 사고로 이어질 수 있습니다.
- 권한 분리는 보안을 어렵게 만드는 일이 아니라, 자동화를 운영 가능한 수준으로 낮추는 작업입니다.
- 처음부터 완벽한 제로트러스트 구조를 만들 필요는 없지만, 최소한 업무별 “허용 목록”과 “금지 목록”은 문서화해야 합니다.
왜 계정 권한부터 나눠야 할까
기존 RPA는 정해진 화면을 클릭하고, 정해진 순서대로 값을 입력하는 경우가 많았습니다. 반면 AI Agent는 중간 판단을 합니다. 문서를 읽고, 요약하고, 다음 행동을 선택하고, 필요하면 도구를 호출합니다.
이 차이 때문에 권한 설계가 더 중요해집니다. 사람이 실수했을 때는 맥락을 보고 멈출 수 있지만, Agent는 연결된 도구 안에서 “가능한 행동”을 실행하려고 합니다. 가능 권한이 넓을수록 사고도 커집니다.
실무 기준은 단순합니다. Agent에게 “필요하면 할 수 있는 권한”이 아니라 “이 업무를 끝내는 데 반드시 필요한 권한”만 줍니다.
권한을 나누는 4개 층
1. 사람 계정과 Agent 계정을 분리합니다
처음 자동화를 만들 때 가장 쉬운 방법은 담당자 계정으로 로그인해 API나 브라우저 자동화를 붙이는 것입니다. 하지만 이 방식은 감사 로그가 섞이고, 담당자가 퇴사하거나 부서 이동을 해도 자동화가 계속 남는 문제가 생깁니다.
가능하면 “마케팅 리포트 Agent”, “CS 요약 Agent”처럼 업무 목적이 드러나는 별도 서비스 계정을 만듭니다. 서비스 계정 이름만 봐도 누가, 어떤 목적으로 쓰는지 알 수 있어야 나중에 끄거나 회수하기 쉽습니다.
2. API 키는 업무 단위로 쪼갭니다
하나의 마스터 API 키를 여러 자동화가 공유하면 장애 원인을 찾기 어렵습니다. 비용이 튀었을 때 어떤 Agent가 호출했는지도 흐려집니다.
- 고객 문의 분류용 키
- 내부 문서 검색용 키
- 리포트 생성용 키
- 운영자 승인 후 발송하는 키
이렇게 쪼개두면 문제가 생겼을 때 해당 키만 비활성화하면 됩니다. 전체 AI 기능을 모두 멈추지 않아도 됩니다.
3. 읽기와 쓰기를 분리합니다
많은 자동화는 처음부터 쓰기 권한이 필요하지 않습니다. 예를 들어 고객 상담 내용을 분류하거나 문서를 요약하는 Agent는 대부분 읽기 권한만으로도 충분합니다.
쓰기 권한이 필요한 업무라도 초반에는 “초안 생성”까지만 허용하고, 실제 발송·수정·삭제는 사람 승인 루프 뒤에 두는 편이 안전합니다.
4. 데이터 접근 범위를 업무 폴더 기준으로 제한합니다
사내 AI 비서가 모든 드라이브와 모든 Notion 페이지를 읽을 수 있게 하면 편해 보입니다. 하지만 계약서, 급여, 인사평가, 고객 개인정보가 섞인 공간까지 읽는 순간 운영 리스크가 커집니다.
먼저 Agent용 지식 폴더를 따로 만들고, 자동화에 필요한 문서만 복사하거나 동기화하는 방식을 추천합니다. 원본 전체를 열어주는 것보다 느릴 수 있지만, 어떤 정보가 AI 업무에 들어가는지 통제하기 쉽습니다.
실무 도입 체크리스트
- ☐ Agent 이름과 목적이 계정명·문서명에 드러나는가?
- ☐ 사람 개인 계정이 아니라 서비스 계정 또는 전용 토큰을 쓰는가?
- ☐ API 키별 사용량 한도와 월 비용 알림이 설정되어 있는가?
- ☐ 읽기 전용으로 가능한 업무에 쓰기 권한을 주지 않았는가?
- ☐ 외부 발송, 삭제, 결제, 고객정보 수정은 사람 승인 뒤에만 실행되는가?
- ☐ 접근 가능한 문서·테이블·채널 목록이 문서화되어 있는가?
- ☐ 테스트용 키와 운영용 키가 분리되어 있는가?
- ☐ 퇴사자·외주·프로젝트 종료 시 회수해야 할 계정과 키 목록이 있는가?
업무별로는 이렇게 시작하면 됩니다
CS 문의 요약 Agent
권장 권한은 문의 채널 읽기, 내부 FAQ 검색, 답변 초안 작성까지입니다. 고객에게 직접 발송하는 권한은 초반에 주지 않는 편이 좋습니다. 사람이 승인한 뒤 발송하게 만들면 품질과 책임 범위가 분명해집니다.
영업 리드 정리 Agent
CRM에 새 메모를 추가하는 정도는 허용할 수 있습니다. 다만 거래 단계 변경, 견적 금액 변경, 고객 삭제 같은 행동은 승인 절차를 둡니다. 특히 기존 영업 파이프라인을 수정하는 권한은 작게 시작해야 합니다.
RAG 기반 사내 지식 검색
가장 먼저 할 일은 모델 튜닝이 아니라 문서 경계 정리입니다. “Agent가 읽어도 되는 문서함”과 “절대 읽으면 안 되는 문서함”을 구분하고, 민감 문서는 원본 대신 요약본이나 마스킹본으로 제공하는 방식을 검토합니다.
운영 중 꼭 남겨야 할 로그
권한을 잘 나눠도 운영 로그가 없으면 문제가 생겼을 때 원인을 찾기 어렵습니다. 최소한 아래 정보는 남겨야 합니다.
- 어떤 Agent가 실행됐는지
- 어떤 사용자 요청 또는 스케줄에서 시작됐는지
- 어떤 데이터 소스와 도구를 호출했는지
- 읽기·쓰기·발송 같은 주요 행동이 있었는지
- 사람 승인이 필요한 단계에서 누가 승인했는지
- 실패했을 때 어떤 권한 또는 외부 API에서 막혔는지
로그는 감시를 위한 장치가 아니라 복구를 위한 장치입니다. 담당자를 탓하기보다 “어디에서 멈췄어야 했는지”를 찾기 위한 자료로 설계해야 합니다.
처음부터 과하게 설계하지 않는 방법
소규모 팀이 처음부터 복잡한 IAM 구조를 만들기는 어렵습니다. 그래서 HeyRatty는 보통 아래 순서로 시작하는 것을 권합니다.
- 1단계: 읽기 전용 자동화부터 만든다.
- 2단계: 초안 작성과 내부 알림까지 허용한다.
- 3단계: 사람 승인 뒤 외부 발송을 붙인다.
- 4단계: 반복적으로 안전성이 확인된 업무만 제한적 자동 실행으로 전환한다.
이 순서를 지키면 자동화 속도는 조금 느려져도, 팀이 신뢰할 수 있는 방식으로 범위를 넓힐 수 있습니다.
FAQ
Q. 개인 계정으로 먼저 테스트해도 되나요?
짧은 내부 실험은 가능하지만, 운영에 붙이는 순간 전용 계정과 전용 키로 바꾸는 것이 좋습니다. 테스트가 오래가면 사실상 운영 자동화가 되기 때문입니다.
Q. API 키를 많이 나누면 관리가 더 어려워지지 않나요?
처음에는 번거롭습니다. 하지만 비용 추적, 장애 차단, 권한 회수는 훨씬 쉬워집니다. 적어도 업무 영역이 다른 Agent끼리는 키를 분리하는 편이 안전합니다.
Q. 사내 AI 비서에 모든 문서를 연결하면 더 똑똑해지지 않나요?
검색 범위가 넓다고 항상 좋은 답이 나오는 것은 아닙니다. 오히려 오래된 문서, 민감 문서, 관련 없는 자료가 섞이면 답변 품질과 보안 리스크가 함께 나빠질 수 있습니다. 필요한 문서부터 작게 연결하는 편이 실무적으로 안전합니다.
HeyRatty가 도와드릴 수 있는 부분
HeyRatty는 AI Agent를 단순히 “붙이는” 작업보다, 실제 업무에서 안전하게 굴러가도록 권한·승인·로그·복구 흐름을 함께 설계합니다.
우리 팀의 자동화 후보가 어디까지 권한을 가져야 할지 애매하다면, 먼저 한 업무를 골라 읽기 전용 PoC부터 작게 설계해보는 것을 추천합니다. 필요하면 HeyRatty가 업무 흐름을 같이 정리해드릴 수 있습니다.
참고 및 이미지 출처
이미지: Role-based access control.svg — Author: Babbage, License: CC0 Public Domain Dedication. Wikimedia Commons의 공개 라이선스 이미지를 사용했습니다.
개념 참고: NIST RBAC Library 및 일반적인 역할 기반 접근제어 원칙을 AI Agent 운영 맥락에 맞게 재구성했습니다.