기업이 AI 에이전트에 운영 업무를 맡기기 시작하면서 접근 제어의 전제도 달라지고 있다. 사람의 계정 아래 여러 자동화 주체가 연속해서 움직일 때 기존 인증 체계만으로는 행동의 책임과 허용 범위를 구분하기 어렵다.
봇 이름만 남은 커밋
Uber는 이런 상황을 예로 든다. 온콜(장애 대응을 위해 대기하는 당직) 엔지니어가 시스템 알림을 에이전트에게 맡기면, 한 에이전트가 오류를 찾고 다른 에이전트가 수정 PR(코드 변경을 병합해 달라는 요청)을 연다고 하자. 머지 기록에는 마지막 에이전트만 남고, 최초 요청자는 그렇게 사라진다.
그런데 기존 IAM(신원, 접근 관리)은 사람과 워크로드(애플리케이션이 실행되는 컴퓨팅 단위)는 구분하지만, 사람을 대신하는 에이전트까지 별도 주체로 다루지는 않는다. 여러 에이전트가 서비스 계정 하나를 쓰면 최초 요청자와 중간 작업자를 어떻게 추적하겠는가. 권한을 개별적으로 회수할 수도 없고, 키가 유출되면 피해 범위도 커진다.
코드 변경에서도 116,211개 저장소에서 에이전트가 만든 PR은 93만 건이 넘는다. 사람이 모든 변경을 검토하지 않는다면, 누가 어떤 목적으로 작업을 시작했는지는 기록으로 남아야 한다.
토큰에 위임 경로 남기기
Uber는 비밀키보다 현재 실행 중인 워크로드의 신원을 먼저 확인한다. 워크로드는 SPIRE(워크로드 신원을 발급, 검증하는 시스템)가 서명한 SVID(SPIFFE 신원 문서)로 실행 환경을 증명한다. STS(보안 토큰 서비스)는 요청의 agent_id를 레지스트리(워크로드와 에이전트의 허용 관계를 보관한 등록부)와 대조해 해당 워크로드가 쓸 수 있는 에이전트인지 확인한다.
검증이 끝나면 STS는 다음 호출에만 쓸 수 있는 단명 JWT(서명된 웹 토큰)를 발급한다. 토큰의 act_chain에는 최초 사용자와 중간 에이전트가 차례로 이어진다. MCP Gateway는 토큰만 보고도 사용자 → 온콜 에이전트 → 조사 에이전트라는 위임 경로를 알 수 있다.
다만 이 기록이 스스로 진위를 증명할까. Uber가 확장한 act 정보는 암호학적으로 검증되는 권한 감쇠 사슬이 아니다. 각 위임 단계가 앞 단계의 권한을 넘어설 수 없고 단계별 증거가 암호학적으로 이어져야 감쇠 사슬이 성립하는데, 지금의 act_chain은 여기에 못 미친다. 그래서 토큰을 발급하는 STS 자체를 보호하고 감사하는 일이 중요하다.
안전한 경로를 기본값으로 만들기
보안 절차가 느리거나 번거로우면 현장에 정착할 수 있을까. Uber의 토큰 교환 API는 대부분 10ms 안에 응답했고 P99(요청의 99%가 이 시간 안에 처리되는 백분위 지표)도 40ms 미만이었다. Uber가 A2A(에이전트 간 통신) 프로토콜 위에 만든 표준 클라이언트는 토큰 교환과 액터 체인 전달을 자동으로 처리했다. 그 결과 수천 개의 내부 에이전트가 이 경로를 채택하면서, 보안 절차도 문서보다 SDK의 기본 동작으로 자리잡을 때 더 잘 지켜진다는 점이 확인됐다.
하지만 신원 확인은 행동의 출처를 밝힐 뿐, 그 행동을 전부 허용한다는 뜻은 아니다.
프롬프트 인젝션(외부 입력으로 악성 지시를 삽입하는 공격)으로 목적이 바뀌면 액터 체인은 잘못된 행동의 출처만 알려줄 뿐 실행을 막지는 못한다. 그래서 게이트웨이에서 도구와 자원별 권한을 제한하고 고위험 작업에는 사람의 승인을 요구하는 장치가 필요하다.
권한이 에이전트 도입을 막지 않으려면
기업용 에이전트가 프로덕션에 들어가지 못하는 이유에는 성능 외에도 다른 요인이 있다. 누가 요청했고 어떤 권한으로 실행했는지 설명할 수 없다면 조직은 변경 권한을 넓게 주기 어렵다.
지난주 프로덕션 변경 하나를 골라 최초 요청자를 로그만으로 5분 안에 찾아보자. 기록이 서비스 계정이나 봇 이름에서 끝난다면 다단계 위임을 감사할 준비가 부족하다.
그렇다면 구축은 실행 중인 워크로드의 신원을 증명하는 데서 시작한다. 이어 워크로드가 쓸 수 있는 에이전트를 등록하고 호출마다 단명 토큰을 발급한다. 토큰에는 전체 위임 경로를 차례로 담고, 마지막으로 게이트웨이에서 작업별 권한을 검사한다.
또한 감사 로그에는 최종 호출자뿐 아니라 전체 위임 경로가 남아야 한다. 여기에 실행 목적과 권한까지 연결해야 기록이 사후 설명을 넘어 실제 통제 수단이 된다.
결국 에이전트의 자율성은 기술의 속성처럼 보이지만 실제 운영에서는 조직이 허용한 범위로 결정된다. 같은 기능을 갖춘 에이전트도 신원과 권한을 어떻게 나누느냐에 따라 자동화 도구가 되기도 하고 통제하기 어려운 공용 계정이 되기도 한다.