AI 에이전트가 보고서를 작성하는 동안에는 권한 문제가 크게 보이지 않습니다. 하지만 메일을 보내고, 고객 정보를 조회하고, ERP의 주문 상태를 바꾸기 시작하면 가장 먼저 답해야 할 질문이 생깁니다. 지금 이 행동은 누구의 권한으로 실행되는가? 사용자의 로그인 세션을 그대로 넘기면 구현은 빠르지만 에이전트가 사용자의 모든 권한을 물려받습니다. 공용 서비스 계정을 쓰면 어느 에이전트가 무엇을 했는지 구분하기 어렵고, 퇴사자 계정이나 만료되지 않는 API 키는 장기간의 보안 부채가 됩니다.
2026년에는 에이전트 신원과 위임 권한이 별도의 기업 보안 주제로 빠르게 자리 잡고 있습니다. NIST NCCoE는 소프트웨어 및 AI 에이전트에 기존 신원 표준과 모범 사례를 적용하는 개념 문서를 발표하며 식별·인증, 인가, 감사, 부인방지, 프롬프트 인젝션 대응을 주요 과제로 제시했습니다. Microsoft도 사람 사용자와 일반 애플리케이션 신원에서 구분되는 에이전트 신원과 수명주기 관리 체계를 공개했습니다.
핵심은 에이전트에게 사람의 신분증을 빌려주는 것이 아닙니다. 에이전트 자체를 식별하고, 누가 어떤 목적의 권한을 위임했는지 보존하며, 그 작업에 필요한 범위와 시간만 허용해야 합니다. 이 글에서는 기업 시스템에 에이전트를 연결할 때 필요한 신원·위임·승인·감사 구조를 실무 관점에서 정리합니다.
인증했으니 안전하다는 착각
인증(authentication)은 호출자가 누구인지 확인하는 일입니다. 인가(authorization)는 그 호출자가 지금 이 자원에 이 행동을 해도 되는지 결정하는 일입니다. 에이전트가 올바른 인증서를 제시했다고 해서 모든 도구를 사용해도 되는 것은 아닙니다. 정상적으로 인증된 에이전트가 잘못된 문서를 읽거나 악성 지시를 받아 과도한 행동을 할 수 있기 때문입니다.
여기에 업무 의도(intent)가 하나 더 필요합니다. “재무 에이전트가 결제 API에 접근할 수 있다”는 장기 권한만으로는 부족합니다. 이번 요청이 어느 사용자의 어떤 업무에서 시작됐고, 어느 거래처에 얼마를 지급하려는지, 어느 시점까지 유효한지를 알아야 합니다. 따라서 에이전트 보안은 다음 세 질문을 함께 답해야 합니다.
- 신원: 지금 행동하는 에이전트 인스턴스는 누구인가?
- 권한: 어떤 자원에 어떤 행동이 허용되는가?
- 의도: 누가 어떤 목표와 제한으로 이 행동을 요청했는가?
이 셋 중 하나라도 빠지면 사고 조사에서 “유효한 토큰으로 호출됐다”는 사실만 남습니다. 왜 호출했는지, 사용자가 허용했는지, 모델이 업무 범위를 벗어났는지는 설명할 수 없습니다.
사람, 애플리케이션, 에이전트 신원을 분리한다
사람 사용자 신원
사람 신원은 비밀번호, 패스키, 다중 인증처럼 사람이 직접 증명하는 방식과 연결됩니다. 조직, 직무, 관리자 관계, 개인 메일함 같은 속성도 가집니다. 에이전트에게 사람 계정의 비밀번호나 세션 쿠키를 주면 이러한 권한과 속성 전체가 섞입니다. 감사 로그에는 사람이 직접 실행한 것처럼 보일 수 있고, 사용자가 자리를 비운 뒤에도 에이전트가 세션을 계속 사용할 수 있습니다.
일반 애플리케이션 또는 워크로드 신원
서비스 계정과 서비스 프린시펄은 서버, 배치, API처럼 목적과 동작이 비교적 안정적인 소프트웨어를 위해 사용해 왔습니다. 에이전트도 기술적으로 이 방식을 사용할 수 있지만, 에이전트는 사용자가 즉석에서 만들거나 작업마다 생성되고 폐기될 수 있습니다. 수천 개의 동적 인스턴스를 장기 서비스 계정 하나로 묶으면 소유자, 생성 근거, 현재 사용 여부와 권한을 관리하기 어려워집니다.
에이전트 신원
에이전트 신원은 에이전트를 별도의 비인간 행위자로 식별합니다. Microsoft Entra Agent ID 문서는 에이전트가 자체 권한으로 자율 접근하거나, 사람에게서 일부 권한을 위임받아 행동하는 두 방식을 구분합니다. 또한 에이전트가 대량으로 생성·폐기되는 특성, 소유자와 스폰서, 사용 중지와 감사 기록을 별도 수명주기로 관리할 필요성을 설명합니다.
중요한 점은 제품 이름보다 설계 원칙입니다. 에이전트 종류를 정의하는 청사진과 실제 실행 인스턴스를 구분하고, 각 인스턴스에 고유 ID를 부여하며, 소유 부서와 업무 목적을 연결합니다. 에이전트가 사라지면 자격 증명과 권한도 함께 폐기되어야 합니다.
자체 권한과 위임 권한은 다른 의미다
야간에 시스템 상태를 확인하는 운영 에이전트처럼 조직이 직접 권한을 부여하는 경우가 있습니다. 이때 에이전트는 자신의 신원과 권한으로 행동합니다. 반면 “내 일정을 확인해 회의실을 예약해 줘”처럼 사용자의 자원을 다루는 경우에는 사용자가 일부 권한을 에이전트에 위임합니다.
위임은 사칭과 다릅니다. IETF RFC 8693은 사칭에서는 행위자가 정해진 권한 범위 안에서 사용자와 구분되지 않을 수 있지만, 위임에서는 행위자와 권한의 주체가 분리되어 드러난다고 설명합니다. 에이전트 운영에는 대체로 후자가 적합합니다. 토큰과 감사 기록에 권한을 가진 주체와 현재 행동하는 에이전트가 모두 남아야 합니다.
예를 들어 김 대리가 구매 요청의 초안을 만들도록 에이전트에 위임했다면 감사 기록은 “김 대리가 실행함”이 아니라 “구매 에이전트 A가 김 대리의 제한된 위임을 사용해 요청 123의 초안을 생성함”으로 표현되어야 합니다. 그래야 사용자, 에이전트, 시스템 운영자의 책임 경계를 구분할 수 있습니다.
역할 하나보다 작업 단위 권한 묶음이 필요하다
기존 RBAC에서 에이전트에 ‘구매 담당자’ 역할을 통째로 주면 읽기, 생성, 승인, 취소 권한이 한꺼번에 따라올 수 있습니다. 사람은 상황 판단과 조직 규정을 학습하지만 에이전트는 화면이나 문서의 잘못된 지시에 영향을 받을 수 있습니다. 따라서 장기 역할은 권한의 최대 상한으로만 사용하고, 실제 실행에는 더 좁은 작업 권한을 발급하는 편이 안전합니다.
한 번의 권한 결정에는 최소한 다음 요소가 들어가야 합니다.
- 주체: 권한을 보유하거나 위임한 사용자 또는 조직
- 행위자: 실제 호출을 수행하는 에이전트와 인스턴스
- 목표: 수행하도록 허용된 업무와 실행 ID
- 자원: 접근 가능한 고객, 주문, 폴더, 시스템
- 행동: 조회, 초안 생성, 수정, 발송, 승인, 삭제 중 허용된 것
- 제한: 금액, 건수, 데이터 종류, 대상 조직, 채널
- 시간: 시작과 만료, 1회 사용 여부
- 조건: 위험도, 네트워크, 환경, 사람 승인 필요 여부
RFC 9396의 Rich Authorization Requests는 단순한 문자열 스코프보다 행동, 위치, 데이터 종류와 업무별 식별자 같은 세부 권한 정보를 표현하는 표준 방식을 제공합니다. 모든 시스템이 이를 직접 구현해야 한다는 뜻은 아니지만, “orders.write” 하나보다 “이 주문에 이 행동을 이 한도 안에서”라는 구조로 권한을 좁혀야 한다는 좋은 참고가 됩니다.
권한은 필요할 때 발급하고 작업 후 폐기한다
에이전트 코드나 프롬프트에 API 키를 넣지 않습니다. 실행 환경의 워크로드 신원을 먼저 검증한 뒤, 정책 서비스가 현재 작업에 필요한 대상과 행동만 담은 단기 토큰을 발급합니다. 토큰은 특정 API에서만 사용할 수 있도록 수신 대상을 제한하고, 몇 분 이내에 만료되며, 가능하면 한 실행 ID와 결합합니다.
일반적인 흐름은 다음과 같습니다.
- 업무 요청을 구조화하고 요청자·목표·대상·위험도를 확인합니다.
- 에이전트 인스턴스의 고유 신원과 실행 환경을 인증합니다.
- 정책 엔진이 사용자 권한과 에이전트의 최대 권한을 교집합으로 계산합니다.
- 고위험 행동이면 대상과 최종 값을 보여주고 사람 승인을 받습니다.
- 대상 자원과 행동, 만료가 제한된 토큰으로 교환합니다.
- 한정된 행동을 실행하고 실제 업무 결과를 독립적으로 확인합니다.
- 주체·행위자·승인·토큰·결과를 연결한 영수증을 남깁니다.
- 토큰과 세션을 폐기하고 임시 권한을 회수합니다.
장기 자격 증명이 반드시 필요한 레거시 시스템이라면 비밀정보 저장소가 실행 순간에만 값을 주입하고, 에이전트 모델에는 실제 비밀번호가 보이지 않게 해야 합니다. 가능하면 읽기 전용과 쓰기 계정을 분리하고, 쓰기 계정은 승인된 단계에서만 사용할 수 있게 합니다.
사람 승인은 구체적인 거래에 묶어야 한다
“이 에이전트가 재무 시스템을 사용하도록 허용하시겠습니까?”라는 광범위한 동의는 실질적인 통제가 아닙니다. 승인 화면에는 어떤 에이전트가, 어느 사용자를 대신해, 어떤 시스템에서, 무엇을, 어떤 값으로 바꾸려는지 보여줘야 합니다. 결제라면 수취인·금액·통화·계좌와 만료 시각을 확인할 수 있어야 합니다.
승인 결과는 해당 인자와 실행에 암호학적으로 또는 서버 상태로 결합합니다. 승인 후 에이전트가 금액이나 대상 계좌를 바꾸면 기존 승인은 무효가 되고 다시 승인받아야 합니다. 승인 대기 중 권한이나 데이터가 바뀌어도 재검증합니다. 단순히 UI의 ‘확인’ 버튼을 눌렀다는 로그만 남기면 어떤 내용에 동의했는지 증명하기 어렵습니다.
모든 행동을 승인받으면 자동화 효과가 사라집니다. 저위험 조회와 초안 작성은 정책으로 자동 허용하고, 외부 전송·금전 거래·삭제·권한 변경·법적 제출처럼 되돌리기 어려운 행동에 단계 상승 승인을 적용합니다. 일정 금액이나 건수를 넘을 때만 승인 수준을 높이는 방식도 가능합니다.
프롬프트는 권한을 만들 수 없다
사용자가 자연어로 “모든 고객 파일을 내려받아 보내라”고 요청했다고 해서 그 문장이 권한 증명은 아닙니다. 웹페이지나 문서 안의 악성 지시도 마찬가지입니다. 모델이 읽은 콘텐츠는 업무 판단의 입력일 수 있지만, 새로운 시스템 접근권이나 데이터 전송권을 만들 수 없어야 합니다.
도구 게이트웨이는 모델이 제안한 호출을 그대로 실행하지 않고, 구조화된 인자와 현재 토큰을 독립적으로 검사합니다. 호출 대상이 허용 목록에 있는지, 자원 ID가 위임 범위와 일치하는지, 행동과 금액이 한도를 넘지 않는지, 승인이 필요한지 서버 측에서 판단합니다. 모델 프롬프트에 “규칙을 지켜라”라고 적는 것만으로 인가를 대체할 수 없습니다.
NIST의 2026년 개념 문서가 에이전트 신원·인가와 함께 프롬프트 인젝션 완화, 데이터 흐름 추적을 언급하는 이유도 여기에 있습니다. 신뢰하지 않는 콘텐츠가 의도를 바꾸더라도 실제 권한 경계가 피해를 제한해야 합니다.
여러 에이전트로 위임될수록 권한은 줄어야 한다
상위 에이전트가 검색 에이전트, 결제 에이전트, 문서 에이전트에 작업을 나누면 위임 사슬이 생깁니다. 하위 에이전트는 상위 에이전트가 가진 권한보다 더 큰 권한을 받을 수 없어야 합니다. 검색만 필요한 하위 에이전트에 원래 사용자의 수정 권한까지 전달할 이유가 없습니다.
각 위임 단계에서 목표·자원·행동·시간 범위를 축소하고, 현재 행위자와 이전 위임 경로를 감사 정보로 남깁니다. RFC 8693의 행위자 정보를 활용한 위임 사슬은 이 관계를 표현하는 참고가 됩니다. 다만 감사용 이전 행위자 목록이 현재 접근 결정을 자동으로 정당화하는 것은 아닙니다. 자원 서버는 현재 토큰의 주체, 행위자, 수신 대상과 권한을 기준으로 판단해야 합니다.
에이전트끼리 메시지를 주고받을 때도 발신자를 인증하고 요청을 서명하거나 위변조를 방지해야 합니다. “상위 에이전트가 시켰다”는 자연어 문장은 신뢰 근거가 될 수 없습니다.
MCP 연결에서도 인증과 사용자 위임을 혼동하지 않는다
MCP 서버가 도구 목록을 제공한다고 해서 클라이언트가 모든 도구를 사용할 권한을 얻는 것은 아닙니다. 원격 MCP 연결에서는 서버와 권한 부여 서버의 관계, 토큰의 수신 대상, 요청한 범위와 사용자 동의를 확인해야 합니다. 2026년 7월 MCP 사양은 OAuth와 OpenID Connect의 실제 배포 방식에 맞추어 발급자 검증 등 인가 흐름을 강화했습니다.
에이전트 플랫폼이 여러 고객의 MCP 서버를 연결한다면 토큰을 고객·사용자·서버별로 분리합니다. 한 서버용 토큰을 다른 서버로 전달하거나, 서버가 받은 사용자 토큰을 임의의 외부 API에 재사용하지 못하게 해야 합니다. 도구 발견, 연결 인증, 도구별 실행 권한은 서로 다른 단계로 다룹니다.
감사 로그는 ‘누가’보다 ‘누가 누구를 대신했는가’를 남긴다
에이전트 행동의 감사 기록에는 최소한 다음 정보가 필요합니다.
- 업무 요청자와 권한 주체, 실제 에이전트 행위자 ID
- 에이전트 청사진·버전·인스턴스·소유자 또는 스폰서
- 업무 실행 ID와 원래 목표, 허용된 자원과 행동
- 발급된 권한의 수신 대상·범위·만료와 정책 버전
- 사람 승인자, 승인한 구체적 인자, 승인 시각
- 실제 도구 호출과 변경 전후 상태, 결과 검증 증거
- 하위 에이전트로 이어진 위임 사슬과 최종 종료·폐기 상태
비밀키와 전체 토큰은 기록하지 않습니다. 필요한 식별자와 해시, 발급자, 만료 정보만 남깁니다. 감사 로그는 에이전트가 수정할 수 없는 별도 저장소로 보내고, 시간 동기화와 무결성 보호를 적용합니다. 그래야 사고 후 에이전트의 설명이 아니라 독립적인 실행 증거로 책임을 판단할 수 있습니다.
신원에도 생성부터 폐기까지 수명주기가 있다
에이전트는 빠르게 만들어질 수 있기 때문에 등록 절차가 느리면 현업이 다시 공용 계정으로 돌아갑니다. 승인된 청사진에서 신원을 자동 발급하고, 소유 부서·스폰서·목적·최대 권한·만료 정책을 필수 항목으로 지정해야 합니다. 개발, 검증, 운영 환경의 신원은 분리합니다.
운영 중에는 최근 활동, 직접 부여된 권한, 위임 사용량, 실패와 정책 위반을 정기적으로 검토합니다. 담당자가 떠나거나 프로젝트가 종료되고, 에이전트 버전이 폐기되면 신원을 비활성화하고 자격 증명과 권한을 회수합니다. 일정 기간 사용되지 않은 신원과 소유자가 없는 고아 신원은 자동으로 격리해야 합니다.
Microsoft의 에이전트 신원 관리 문서는 에이전트별 상태, 청사진, 소유자와 스폰서, 부여된 권한, 로그인 및 감사 로그를 조회하는 관리 모델을 제시합니다. 어떤 신원 플랫폼을 사용하든 이러한 인벤토리가 없으면 조직은 자신이 운영하는 에이전트 수와 권한을 알 수 없습니다.
레거시 시스템은 별도의 현실적인 경계가 필요하다
일부 ERP와 데스크톱 프로그램은 에이전트 전용 신원이나 세밀한 API 권한을 지원하지 않습니다. 이 경우 사람 계정을 공유하기보다 업무 전용 제한 계정을 만들고, 격리된 실행 환경에서만 사용하도록 합니다. 네트워크와 접근 가능한 화면을 제한하고, 자격 증명 브로커가 실행 순간에만 로그인 정보를 주입합니다.
레거시 시스템 안에서는 권한을 잘게 나눌 수 없더라도 앞단의 정책 게이트웨이에서 작업·대상·시간·건수를 제한할 수 있습니다. 실행 후에는 별도 조회나 데이터베이스, 감사 테이블로 실제 결과를 검증합니다. 에이전트가 사용하는 화면 세션과 사람 세션을 구분하고 녹화·보존 정책을 적용하면 최소한 행위자를 식별할 수 있습니다.
30일 도입 로드맵
- 1주차 — 인벤토리: 에이전트, 소유자, 연결 시스템, 사용 중인 사람·서비스 계정, 장기 키와 최대 권한을 목록화합니다. 고위험 공유 계정을 우선 찾습니다.
- 2주차 — 신원 분리: 대표 에이전트 하나에 고유 신원을 발급하고 개발·운영 환경을 분리합니다. 업무 요청자와 에이전트 행위자가 함께 남도록 추적 ID를 연결합니다.
- 3주차 — 작업 권한: 장기 역할의 상한 아래에서 자원·행동·시간이 제한된 단기 토큰을 발급합니다. 고위험 행동의 거래 결합형 승인과 서버 측 정책 검사를 적용합니다.
- 4주차 — 감사와 폐기: 위임 사슬, 승인, 실제 결과를 감사 로그로 연결하고 만료·취소·소유자 변경·고아 신원 탐지 절차를 시험합니다.
처음부터 모든 시스템을 바꾸기보다 읽기 중심의 한 업무에서 시작합니다. “누가 어떤 권한을 왜 받았고, 실제로 무엇을 했으며, 언제 폐기됐는가”를 한 건의 기록으로 설명할 수 있으면 다음 시스템으로 확대합니다.
Nature Fractal이 보는 기업용 에이전트의 기본 조건
AI 에이전트의 모델과 도구 연결은 빠르게 만들 수 있습니다. 기업 환경에서 오래 운영하려면 기존 IAM, API 게이트웨이, 비밀정보 저장소, 승인 워크플로, 감사 시스템과 연결되어야 합니다. 에이전트 전용 보안 섬을 만드는 대신 현재 조직의 신원 정책 안에서 에이전트를 새로운 비인간 행위자로 수용하는 것이 현실적입니다.
Nature Fractal은 에이전트 도입을 모델 연동 프로젝트가 아니라 업무와 권한의 재설계로 봅니다. API와 레거시 시스템을 분석하고, 에이전트가 꼭 필요한 작업만 수행하도록 권한을 좁히며, 사람의 의도와 실제 실행 결과를 추적할 수 있어야 합니다. 모델이 바뀌어도 이 신원·권한·감사 기반은 그대로 남아 조직의 자동화 자산이 됩니다.
도입 전 체크리스트
- 모든 운영 에이전트와 인스턴스에 고유한 신원이 있는가?
- 사람 계정, 공용 서비스 계정과 에이전트 신원을 구분하는가?
- 권한 주체와 실제 행위자가 감사 기록에 함께 남는가?
- 에이전트의 자체 권한과 사용자 위임 권한을 구분하는가?
- 권한이 자원·행동·시간·금액·건수 단위로 제한되는가?
- 대상 시스템별 단기 토큰을 사용하고 장기 키 노출을 막는가?
- 중요 승인이 구체적인 대상과 최종 값에 결합되는가?
- 프롬프트나 화면 문구가 새로운 권한을 만들 수 없게 했는가?
- 하위 에이전트로 위임할 때 권한이 확대되지 않는가?
- 도구 게이트웨이가 모든 호출을 서버 측에서 다시 검사하는가?
- 소유자·스폰서·목적·권한·활동을 조회할 인벤토리가 있는가?
- 에이전트 종료 시 신원·토큰·세션·권한이 함께 폐기되는가?
에이전트에게 일을 맡긴다는 것은 권한을 맡긴다는 뜻입니다. 가장 안전한 에이전트는 아무것도 못 하는 에이전트가 아니라, 자신의 신원으로 식별되고 필요한 작업만 잠시 수행하며 모든 행동의 위임 근거와 결과를 설명할 수 있는 에이전트입니다. 사람 계정 공유를 끝내고 신원과 위임을 설계하는 일이 기업용 에이전트의 출발점입니다.
참고 자료
- NIST — Identity and authority of software agents
- Microsoft Entra Agent ID — What are agent identities?
- Microsoft Entra Agent ID — View and filter agent identities
- IETF RFC 8693 — OAuth 2.0 Token Exchange
- IETF RFC 9396 — OAuth 2.0 Rich Authorization Requests
- Model Context Protocol — 2026-07-28 specification
