AI 에이전트는 묻는 말에 답하는 데서 그치지 않습니다. 사람 대신 문서를 찾아 읽고, 메일 초안을 써서 보내고, 티켓을 만들고, 시스템에 명령을 내립니다. 일을 맡길 수 있다는 것은 곧 권한을 준다는 뜻입니다. "이 에이전트는 누구의 권한으로, 무엇까지 할 수 있는가"를 먼저 정하지 않으면, 편리함을 얻는 만큼 데이터 유출과 권한 오남용의 새 통로가 열립니다.
이 글은 에이전트를 도입하기 전에 정해 두어야 할 권한 원칙을 정리합니다. 특정 제품이 아니라 어떤 에이전트에도 적용되는 기준이고, 실제 적용 수단은 끝부분에 따로 적었습니다.
에이전트는 무엇이 다른가
회사에는 이미 사람 계정과 서비스 계정이 있습니다. 에이전트는 둘 중 어느 쪽과도 다릅니다.
| 구분 | 사람 계정 | 기존 서비스 계정 | AI 에이전트 |
|---|---|---|---|
| 일하는 방식 | 사람이 직접 판단하고 클릭 | 정해진 작업만 반복 | 상황을 보고 쓸 도구와 순서를 스스로 고름 |
| 무엇에 영향을 받나 | 본인 판단 | 정해진 입력 | 읽은 문서·메일·웹페이지 속 문장 |
| 속도와 규모 | 사람 속도 | 빠르지만 하는 일이 고정 | 빠르고, 여러 일을 동시에 |
| 관리 절차 | 입사·이동·퇴사 절차 | 주인을 모르는 경우가 많음 | 누가 만들었는지조차 모르는 경우가 많음 |
에이전트는 서비스 계정처럼 빠르고 지치지 않으면서, 사람처럼 스스로 판단합니다. 그리고 사람과 달리 읽은 글에 쉽게 휘둘립니다. 그래서 사람 계정처럼 신원과 책임자를 관리하는 동시에, 사람에게는 필요 없던 통제가 더 필요합니다.
무엇이 위험한가
생성형 AI 보안 기준으로 널리 쓰이는 OWASP Top 10 for LLM Applications(2025)는 에이전트와 관련된 대표 위험을 이렇게 설명합니다.
- 과도한 권한·기능·자율 (Excessive Agency): 에이전트가 예상치 못한 출력이나 조작된 입력 때문에 해로운 일을 실행하는 문제입니다. OWASP는 원인을 셋으로 나눕니다. 필요 이상의 기능(쓸 일 없는 도구까지 연결), 필요 이상의 권한(읽기만 하면 되는데 쓰기·삭제까지 허용), 필요 이상의 자율(큰일을 사람 확인 없이 실행)입니다.
- 숨은 지시 (Prompt Injection): 사용자가 직접 넣는 지시뿐 아니라, 에이전트가 읽는 웹페이지나 파일 속에 숨은 지시가 동작을 바꿀 수 있습니다(간접 주입). 숨은 지시가 담긴 웹페이지를 요약하게 했더니 대화 내용을 외부 주소로 빼돌리는 예, 공격자가 고쳐 놓은 사내 문서가 검색되어 엉뚱한 답을 내는 예가 대표적입니다.
- 과다 노출된 데이터: 에이전트는 연결된 저장소 안에서 답을 찾습니다. 전사 공개로 잘못 열어 둔 폴더가 있으면 그 내용이 아무에게나 답으로 나갑니다. 에이전트가 새 구멍을 만드는 것이 아니라, 원래 있던 구멍을 누구나 쉽게 찾게 만듭니다.
- 코드에 적힌 자격증명: 에이전트가 시스템에 접속하려고 쓰는 API 키와 비밀번호가 코드나 설정 파일에 그대로 적혀 있거나, 넓은 권한의 공용 계정을 여러 에이전트가 나눠 쓰는 경우입니다.
- 아무도 모르는 에이전트: 부서마다 만든 에이전트, 직원이 PC에 설치한 AI 도구, 협력사 서비스에 들어 있는 에이전트. 목록에 없는 에이전트는 통제할 수도 없습니다.
원칙 1. 에이전트에도 신원과 책임자를 둔다
모든 에이전트는 사람처럼 자기 신원을 갖고, 그 에이전트를 책임지는 사람이 정해져 있어야 합니다. 신원이 있어야 접근 정책을 걸 수 있고, 로그에서 "누가 했는지"를 가릴 수 있으며, 문제가 생겼을 때 그 에이전트만 골라 멈출 수 있습니다.
- 에이전트를 만들면 등록부터 합니다. 이름, 용도, 책임자, 연결된 시스템을 적습니다
- 여러 에이전트가 계정 하나를 나눠 쓰지 않습니다. 하나가 문제를 일으키면 전부를 멈춰야 하기 때문입니다
- 책임자가 퇴사하거나 부서를 옮기면 에이전트의 책임자도 함께 바꿉니다
Microsoft Entra Agent ID처럼 에이전트 전용 신원을 주고, 사람 계정과 같은 접근 정책·위험 탐지·수명 주기 관리·로그를 적용하는 기능이 이미 나와 있습니다. Microsoft 플랫폼 밖에서 만든 에이전트도 같은 신원 체계에 연결할 수 있습니다.
원칙 2. 에이전트는 사용자의 권한을 넘지 않는다
에이전트가 일하는 방식은 크게 둘입니다.
- 사용자를 대신해 일하는 에이전트: 요청한 사람의 권한으로 동작합니다. 이때 에이전트가 볼 수 있는 자료와 할 수 있는 일은 그 사람이 원래 할 수 있는 범위를 넘으면 안 됩니다. OWASP도 하위 시스템 접근은 사용자의 권한 맥락에서 실행하라고 권합니다.
- 자기 계정으로 일하는 에이전트: 정해진 업무를 스스로 처리합니다. 사람 대신이 아니므로, 그 업무에 필요한 최소 권한만 따로 설계합니다.
피해야 할 구성은 하나입니다. 넓은 권한을 가진 서비스 계정 하나로 에이전트를 돌리고 모든 직원이 그 에이전트를 쓰게 하는 것입니다. 이렇게 하면 신입 사원도 에이전트를 통해 임원 폴더를 읽을 수 있게 됩니다.
원칙 3. 읽기와 쓰기를 나누고, 큰일은 사람이 승인한다
문서 검색과 요약은 읽기, 메일 발송과 티켓 생성과 데이터 변경은 쓰기입니다. 읽기는 잘못돼도 답이 틀릴 뿐이지만, 쓰기는 되돌리기 어렵습니다. 그래서 동작마다 영향 범위를 보고 사람이 얼마나 개입할지 미리 정합니다.
- 확인 없이 실행되는 동작은 목록으로 문서화합니다. 목록에 없는 쓰기 동작은 기본적으로 사용자 확인을 거칩니다
- 영향이 큰 동작은 사람 승인을 필수로 합니다. OWASP는 영향이 큰 동작을 실행하기 전에 사람이 승인하도록(human-in-the-loop) 권합니다. 외부 발송, 결제, 삭제, 권한 변경이 여기에 들어갑니다
- 쓸 일 없는 도구는 연결하지 않습니다. 셸 명령이나 임의 주소 호출처럼 무엇이든 할 수 있는 도구 대신, 그 업무만 하는 좁은 도구를 씁니다
원칙 4. 연결할 데이터를 목록으로 정하고, 밖에서 온 글은 지시로 받지 않는다
에이전트에 연결하는 저장소, 폴더, 기간을 목록으로 관리합니다. 인사·재무·법무 자료처럼 민감한 범위는 기본으로 빼고, 필요하면 별도 승인을 받아 넣습니다.
- 연결 전에 과다 공유부터 정리합니다. 전사 공개로 열린 사이트, 퇴사자가 남긴 공유 링크를 먼저 닫습니다. 에이전트는 원래 있던 구멍을 가장 빨리 찾아냅니다
- 원본 권한을 지키는 검색을 씁니다. 사내 자료를 찾아 답하는 구성에서는 원본의 접근 권한과 민감도 라벨을 질의 시점에 확인해, 묻는 사람이 볼 수 있는 내용만 돌려주게 합니다
- 외부 콘텐츠는 데이터로만 다룹니다. 웹페이지, 외부 메일, 첨부파일 속 문장은 지시가 아니라 참고 자료입니다. OWASP는 신뢰할 수 없는 콘텐츠를 분리해 표시하고 그 영향을 제한하라고 권합니다. 브라우저 안에서 일하는 에이전트라면 페이지에 숨은 프롬프트 주입을 막는 브라우저 보안도 함께 검토합니다
원칙 5. 모든 실행을 기록하고, 정기 점검하고, 바로 멈출 수 있게 한다
에이전트가 무엇을 읽고 무엇을 실행했는지 로그를 남깁니다. 이상한 움직임은 대개 기록에서 먼저 보입니다. 짧은 시간에 평소보다 훨씬 많은 요청을 보내는 에이전트는 실행 횟수를 제한해 피해 범위를 줄입니다.
도입할 때의 설정은 조직이 바뀌면 금방 낡습니다. 분기마다 권한과 연결 범위를 다시 확인하고, 문제가 생기면 그 에이전트의 신원을 막아 즉시 멈출 수 있어야 합니다. 업무가 끝난 에이전트는 신원과 자격증명을 회수합니다. 사람의 입사부터 퇴사까지를 관리하듯, 에이전트도 처음부터 끝까지 관리합니다.
도입 전 체크리스트
에이전트 하나를 업무에 넣기 전에, 아래 여덟 가지 질문에 답할 수 있어야 합니다.
- 이 에이전트의 책임자는 누구인가
- 누구의 권한으로 동작하는가 (사용자를 대신하는가, 자기 계정으로 일하는가)
- 연결된 데이터는 어디까지이고, 일부러 뺀 범위는 무엇인가
- 확인 없이 실행되는 동작은 무엇인가
- 사람 승인이 필요한 동작과 아예 금지한 동작은 무엇인가
- 에이전트가 쓰는 자격증명은 어디에 보관되는가
- 실행 기록은 어디에 남고, 누가 보는가
- 문제가 생기면 누가, 어떻게 멈추는가
작게 시작하는 순서
- 읽기 전용으로 시작합니다. 한 부서, 민감하지 않은 자료, 검색·요약 업무부터
- 기록을 보고 고칩니다. 몇 주 동안 무엇을 읽고 어떻게 답했는지 보고 연결 범위와 지시를 다듬습니다
- 쓰기를 하나씩 더합니다. 사용자 확인을 붙인 쓰기 동작부터 추가하고, 확인 없이 둘 동작은 기록으로 충분히 검증한 뒤 정합니다
- 넓힙니다. 부서와 업무를 늘리되, 늘릴 때마다 체크리스트를 다시 거칩니다
원칙을 실제로 적용하는 수단
원칙은 도구로 운영되어야 지켜집니다. Microsoft 환경과 TDG가 공급하는 솔루션을 예로 들면 다음과 같이 대응됩니다.
| 원칙 | 적용 수단 |
|---|---|
| 신원과 책임자 | Microsoft Entra Agent ID로 에이전트 신원, 접근 정책, 로그 |
| 에이전트 목록과 통제 | Microsoft Agent 365로 회사 안의 에이전트를 한 목록에 모아 관리 |
| 데이터 범위 | Microsoft Purview 민감도 라벨·유출 방지를 에이전트에도 적용 |
| 자격증명 보관 | BeyondTrust Password Safe 금고에서 사람 계정과 같은 감사 추적 |
| 사람 승인 단계 | Copilot Studio 워크플로의 사람 검토 단계 |
| PC에서 실행 전 통제 | BeyondTrust AI Agent Security(출시 예정)로 직원 PC의 에이전트를 찾고 위험한 동작을 실행 전에 차단·승인 |
TDG는 우리 회사 AI 데이터 보호에서 이 원칙을 반영한 권한·데이터 설계를 함께 만들고, 도입 후 정기 점검까지 이어갑니다. 회사 안에 이미 어떤 에이전트와 서비스 계정이 있고 어떤 권한을 갖고 있는지부터 궁금하다면 내부 자산 집중 점검으로 시작할 수 있습니다.
참고: OWASP LLM06:2025 Excessive Agency, LLM01:2025 Prompt Injection, Microsoft Learn What is Microsoft Entra Agent ID?, Microsoft Agent 365 overview.
