AI 에이전트는 서비스 계정의 실수를 반복한다: 아무도 규모를 재지 않은 거버넌스 공백

업계는 이 실험을 이미 한 번 했다. 서비스 계정으로. 에이전트는 그 재연이다. 실패는 똑같고 속도만 10배 빠르다.

우리는 이 영화를 봤다

인간 신원은 좋은 인프라를 받았다. SSO가 자리를 잡았고 IdP가 프로비저닝을 가져갔다. SCIM이 입퇴사 처리를 자동으로 연결했다. 20년을 다듬은 끝에 "이 사람이 누구이고 무엇을 만질 수 있는가"는 대체로 풀린 문제가 됐다. 머신 신원은 그중 아무것도 못 받았다. 서비스 계정과 API 키와 토큰은 시스템 사이 틈에 쌓였고 소유자라고 적힌 스프레드시트는 작성한 날부터 틀려 있었다. 그래서 업계는 지난 15년을 그 스프롤을 사후에 치우는 제품군을 만드는 데 썼다. 우리도 그중 하나다.

이제 에이전트가 왔다. 그리고 머신 신원의 실패를 인간 신원의 규모, 기계의 속도로 물려받는다. 에이전트가 파일을 읽고 DB에 질의하고 Slack에 글을 올리고 PR을 열고 외부 API를 부를 때마다, 그 동작은 크리덴셜로 인증된다. 토큰, API 키, OAuth 인가, 짧은 수명 인증서. 에이전트의 모든 행동은 크리덴셜 행동이다. 그러니 기업 안의 비인간 신원(NHI) 수는 사람 속도에 맞춘 어떤 인벤토리 절차도 따라잡지 못할 만큼 빠르게 는다. 게다가 서비스 계정이 그랬던 그대로, 거버넌스 없이 는다. 예전엔 한 분기가 걸리던 순환이 이제 반나절이면 끝난다는 점만 다르다.

여기서 반사적으로 이걸 프로비저닝 문제로 다루게 된다. 에이전트에 크리덴셜을 발급하고, 돌리고, 로그를 남기고. 바로 그 반사가 우리가 같은 실수를 반복하려는 이유다. 서비스 계정 스프롤은 프로비저닝이 실패해서 생긴 게 아니었다. 프로비저닝 도구가 덧칠로 가려 버린 거버넌스 공백이었다. 에이전트는 그 공백을 더 넓히고 도구는 그 위에 또 덧칠을 한다.

에이전트가 무너뜨리는 전제

표준 처방들이 하나같이 피해 가는 지점이 여기 있다. 지금 돌아가는 모든 신원 시스템은 접근하는 순간 사람이 판단한다고 전제한다. OAuth의 동의 화면, 승인 절차, 필요할 때 즉석에서 여는 접근 요청, "정말 진행할까요?" 창까지. 전부 크리덴셜이 쓰이는 그 순간 옆에 판단할 사람이 있다는 전제 위에 서 있다. 이 전제가 구조를 떠받치는 기둥인데, 에이전트가 그 기둥을 빼 버린다.

에이전트는 한 시간에 수백 번 인증한다. 그 개별 호출 어디에도 사람은 없다. 동의는 배포하는 순간 딱 한 번, 그것도 운영자가 절반밖에 예측하지 못한 행동들을 뭉뚱그려 받아 둔 게 전부다. 그 뒤로는 에이전트가 위임받은 권한을 기계 속도로 행사할 뿐이고 신원 레이어는 정상 행동과 침해 행동을 가려낼 방법이 없다. 그 판단을 하던 사람이 사라졌기 때문이다.

에이전트 인증을 OAuth 2.1에 덧대는 건, 레거시 데스크톱 OS 위에서 자율 에이전트를 돌리는 것과 신원 레이어에서 똑같은 실수다. 한 종류의 행위자를 염두에 두고 설계한 권한 모델에게 전혀 다른 행위자를 통제하라고 맡기면서 그 어긋남이 작게 끝나기를 바라는 셈이다. 작게 끝나지 않는다. 그 어긋남이 문제의 전부다.

표준 처방이 임시방편인 이유

아래 중 틀린 건 하나도 없다. 전부 필요하다. 다만 하나같이 증상만 관리하고 전제는 그대로 둔다는 점은 솔직히 짚고 가야 한다.

짧은 수명 크리덴셜은 피해 범위를 줄인다. 유출된 토큰이 몇 분 만에 죽으면 피해가 벌어질 시간 대부분이 그와 함께 닫힌다. 우리가 유일하게 양보 못 한다고 보는 패턴인데, 그 효과가 사람의 존재에 기대지 않는 유일한 패턴이라서다. 걸리는 건 이거다. 모든 다운스트림이 짧은 수명 토큰을 받아 주지는 않는다. 수십 개 API를 건드리는 에이전트라면 정적 키를 요구하는 곳을 적어도 하나는 만난다. 그러니 이건 절대 원칙이 아니라 지향점이고 장기 키가 불가피한 예외는 대충 넘길 게 아니라 담당자를 붙여야 한다.

에이전트용 OAuth 2.1 프로파일, 그러니까 동적 클라이언트 등록, 촘촘한 오디언스 바인딩, 기본값이 된 짧은 수명은 분명 진전이다. Clutch Security는 MCP 안에서 이 적용이 어떤 모습인지 눈에 보이게 정리해 왔다. 하지만 바인딩을 아무리 촘촘히 해도 결국 토큰을 에이전트에 묶는 일이지, 접근하는 순간의 판단을 되돌려 주는 일은 아니다. 재전송(replay)은 줄여도 "이 행동이 지금 일어나도 되는가"에는 답하지 못한다. 게다가 토큰 발급을 맡은 팀이 에이전트 신원까지 떠안게 되는데, 이건 아무도 사람을 붙여 두지 않은 업무 확장이다.

민감한 행동에만 사람을 끼워 넣기는 사람을 실제로 다시 데려오는 유일한 패턴이다. 그래서 정말 가둘 만한 좁은 행동, 즉 돈을 쓰거나 권한을 주거나 데이터를 내보내는 일에만 쓴다. 전제가 중요했다는 사실을 정책으로 인정하는 셈이다. 대신 가두는 행동에 대해서는 자동화의 값어치를 통째로 깎아 먹으니 기본값이 될 수는 없다. 진짜 물어야 할 건 어떤 행동이 이 관문을 통과할 자격이 있느냐인데, 대부분의 팀은 그 선을 제대로 그어 두지 않았다.

중앙 에이전트 레지스트리, 즉 어떤 에이전트가 있고 누가 소유하며 무엇에 닿는지를 한곳에 모은 단일 원천은 "일단 정리부터 하자"는 마음이 도착하는 곳이다. 보통 스프레드시트로 시작해 위키가 되고 끝에는 다른 시스템이 조회할 수 있는 API 서비스가 되고 싶어 한다. 문제는 낡은 레지스트리가 없느니만 못하다는 데 있다. 인벤토리가 갖춰졌다는 착각을 만들기 때문이다. 이걸 정직하게 유지하는 힘은 자동 디스커버리로 채우는 것뿐이고 그러면 문제는 다시 탐지로, 즉 우리가 파는 그 영역으로 돌아온다. 레지스트리가 알아서 최신 상태를 유지하는 척하느니 이 사실을 그냥 밝히는 편이 낫다.

이 중 어느 하나도 에이전트 신원을 해결하지 못한다. 넷을 엮으면 버틸 만해지고 그 바닥엔 짧은 수명 크리덴셜이 깔린다. 그러나 네 개를 다 도입해 놓고 문제를 풀었다고 믿는 보안 프로그램은, 임시방편 묶음을 거버넌스로 착각한 것이다.

인벤토리에서 실제로 바뀌는 것

처방은 잠깐 내려놓고 인벤토리 자체를 보자. 범주로 따로 잡을 만큼 뚜렷한 변화가 넷이다.

에이전트는 독립된 NHI 종류다. 기존 분류 어디에도 깔끔히 들어가지 않는다. 목표를 가진 행위자라 인간 사용자 같지만 크리덴셜은 서비스 계정처럼 들고 만들어지기는 머신 아이덴티티처럼 프로그램으로 찍힌다. 이걸 "애플리케이션"으로 로그에 남기는 순간, 위험을 만드는 바로 그 정보가 지워진다. 별도 종류로 잡아라. 머신 아이덴티티 기본값인 짧은 수명과 최소 권한 위에, 에이전트 고유 항목을 얹는다. 어떤 모델로 돌아가는지, 누가 배포했는지, 어떤 도구에 닿는지, 앞단에 어떤 정책 엔진이 있는지.

소유자 추적은 나아지기는커녕 나빠진다. 서비스 계정은 소유자가 하나였고 그마저 대개 틀렸다. 에이전트 토큰은 그걸 짠 개발자의 것일 수도, 불러 쓴 사용자의 것일 수도, 밑단 인프라를 깐 플랫폼 팀의 것일 수도 있다. 작정하고 정해 두지 않으면 결국 누구의 것도 아니게 된다. 그게 바로 문제가 터졌을 때 부를 담당자가 없는 고스트 키(ghost key)로 가는 길이다. 임자 없는 키는 돌려야 할 때 돌지 않는다. 일회성으로 뜨는 특성이 이걸 더 키운다. 에이전트는 끝나도 키는 살아 있고 다음 개발자가 볼트에서 그 키를 찾아 다시 쓰면, 키는 붙어 있는 프로세스 하나 없이 늙어 버린 오래된 키(aged key)가 된다.

권한 과다는 예외가 아니라 기본값이다. 권한이 모자란 에이전트는 요란하게 실패한다. 사용자가 시키고, 에이전트가 못 한다 하고, 사용자가 항의한다. 반대로 권한이 넘치는 에이전트는 사고가 나는 날까지 조용히 잘 돌아간다. 그래서 현장의 힘은 늘 권한을 넉넉히 주는 쪽으로 기운다. 그 찌꺼기가 정작 필요한 범위를 한참 넘어 권한이 불어난 과공유 키(over-shared key)로 차곡차곡 쌓인다.

섀도 에이전트는 노트북 한 대면 뜬다. 노트북에서 MCP 서버를 돌리는 개발자, OpenAI 키로 n8n을 엮는 마케팅 팀, 브라우저 확장으로 Claude를 Zendesk 큐에 붙이는 지원 엔지니어. 이들 각자가 중앙 인벤토리에는 절대 안 잡히는 태생부터 섀도인 크리덴셜(shadow credential)을 찍어낸다. 도구가 편해질수록 그 수는 는다. 막으면 지하로 숨을 뿐이다. 버틸 수 있는 유일한 답은 공식 경로를 가장 편한 경로로 만들어 두고 나머지는 계속 스캔하는 것이다. 이것들이 가장 많이 숨는 자리가 새로 생긴 프로토콜 표면이다. MCP 서버, 에이전트끼리의 호출, 프로토타입이 돌아간 뒤에야 뒤늦게 붙은 신뢰 경계들. 이 표면은 MCP·A2A와 비인간 신원 보안을 다룬 글에서 더 깊이 짚었다.

우리가 연재해 온 NHI 킬체인의 모든 패턴이 여기에도 그대로, 그것도 평범한 서비스 계정보다 더 날카롭게 적용된다. 에이전트는 새 실패를 발명한다기보다, 이미 있던 실패를 더 빠른 박자로 돌린다.

우리가 실제로 목격하는 것

패턴을 꺼내기 전에 하나 밝혀 둔다. 이건 통제된 실험이 아니라 고객 환경에서 얻은 현장 관찰이다. 연구인 척 포장하느니 있는 그대로 부르는 게 낫다.

가장 또렷한 신호는 타이밍이다. 어떤 조직이 MCP나 에이전트 통합을 처음으로 제대로 켜면 시크릿 탐지 이벤트가 오른다. 그것도 매번 같은 모양으로 오른다. 통합이 라이브가 되고 개발자들이 에이전트를 쓸 만한 도구에 서둘러 붙인다. 그 과정에서 크리덴셜이 기존 통제가 안 보던 자리에 떨어진다. 리포에 커밋된 MCP 서버 설정 안의 개인 액세스 토큰. 노트북에서 대충 만들어 보느라 프로덕션만큼 관리되지 못한 채 커밋된 `.env` 속 `OPENAI_API_KEY`. 사람들이 막 굴려서가 아니다. 에이전트 통합 코드를 짜는 사람의 폭이 백엔드 코드를 짜는 사람보다 넓은데, 뒤쪽을 잡던 가드레일이 아직 앞쪽까지 닿지 못해서다.

그 밑에 깔린 가장 흔한 이야기는 편의용 키다. 개발자가 에이전트에 뭔가 쓸 만한 일을 시키려 한다. 제일 빠른 길은 넓은 권한을 가진 장기 키를 쥐여 주는 것이다. 에이전트는 잘 돌아간다. 그러다 그 키가 헬퍼 리포로 들어가고, 다른 에이전트 두 개에 공유되고, 팀원이 그대로 재현하라고 Slack에 붙는다. 6주 뒤 에이전트는 잊혔지만 키는 여전히 살아 있고 여전히 넓고 볼트가 아닌 여기저기에 흩어져 있다. 문제였던 건 에이전트가 아니다. 에이전트를 개발하는 습관이 크리덴셜을 퍼뜨렸다. 이 글의 논지가 그대로 담긴 장면이다. 프로비저닝 버그가 아니라 거버넌스 공백이라는 것.

게다가 업계 스스로의 채점이 이걸 가린다. 아웃 오브 스코프 루프홀에서 다룬 분류 사각지대가 에이전트가 만든 크리덴셜에는 더 세게 걸린다. 유출된 크리덴셜조차 스코프 안으로 받기 버거워하던 버그바운티가, 에이전트가 프로비저닝한 토큰을 정식 이슈로 값을 매기기는 더 어렵다. 평가 틀이 이걸 어떻게 다뤄야 할지 몰라 "스코프 밖"으로 밀어내고 그러면 문제는 정작 그걸 잡기 가장 좋은 자리에서 안 보이게 된다. 심각도는 어디서 왔느냐가 아니라 얼마나 번지느냐로 판단해야 한다.

스프롤이 눈덩이가 되기 전에 할 일

흔한 체크리스트보다 적고 날카로운 것들만, 효과가 큰 순서로.

에이전트 크리덴셜은 이미 있다고 치고 찾아 나서라. 새는 자리부터 보면 된다. 코드 호스트, 시크릿 매니저, CI/CD 변수 저장소. 지난 90일 안에 만들어졌고 소유자가 애플리케이션이 아니라 개별 개발자 계정으로 잡힌 키를 전부 긁어낸다. 그중 상당수가 에이전트와 얽힌 키다. 인벤토리가 인정하든 말든, 이미 당신 환경 안에 들어와 있다.

"에이전트"를 1급 종류로 세우고 그 위에 킬체인을 돌려라. 스키마 손질은 작지만 그 덕에 에이전트 고유의 위험이 "서비스 계정"으로 뭉뚱그려져 사라지는 일이 멈춘다. 그다음엔 서비스 계정에 이미 돌리는 감사를 그대로 에이전트 결합 크리덴셜에도 돌린다. ghost, shadow, aged, over-shared 그대로다. 결과는 더 나쁠 각오를 해 두는 게 좋다. 인벤토리가 더 새것이고 가드레일이 아직 세워지는 중이라서다.

짧은 수명을 기본값으로, 정적 키는 서명받은 예외로. AWS를 부를 땐 STS, 내부 서비스를 부를 땐 그 서비스에만 맞춘 오디언스 바인딩 토큰을 호출하는 순간에 발급한다. 정적 키로 되돌아가는 건 누군가 명시적으로 승인해야 하는 예외여야 한다. 사람이 빠진 뒤에도 효력이 남는 유일한 통제이니, 다른 것보다 먼저 정치적 자본을 쓸 값어치가 있다.

설계상 무엇을 하도록 만들었는지가 아니라, 실제로 무엇에 닿을 수 있는지를 분기마다 본다. 한 번씩 열어 준 권한이 쌓이면서 실효 권한이 흘러가고 배포 몇 달 뒤 "이 에이전트가 실제로 어디까지 닿나"의 답은 배포 티켓과 좀처럼 맞지 않는다. 바로 그 어긋남 속에서 다음 사고가 지금 자라고 있다.

Cremit이 들어가는 자리

거버넌스 공백이라는 이 프레이밍에 고개가 끄덕여지는데 이걸 어떻게 실무로 옮길지 막막하다면, 그 틈을 메우려고 우리가 만든 게 Argus다. 에이전트 크리덴셜이 새는 자리, 그러니까 코드 리포, CI/CD, 에이전트 설정 파일, 채팅 채널을 계속 스캔하고 찾아낸 크리덴셜을 그걸 만든 에이전트와 배포한 사람까지 거슬러 잇는 소유권 매핑, 거기에 에이전트가 실제로 도는 일회성 리듬에 맞춘 회전 자동화까지. 어떻게 접근하는지는 argus.cremit.io에서 볼 수 있다. 정직하게 한마디 덧붙인다. 탐지는 필요하지만 그것만으로는 부족하다. 탐지는 공백이 얼마나 큰지 재 주는 계기판일 뿐이다. 그 공백을 메우는 건 당신 조직만이 내릴 수 있는 거버넌스 결정이다.

에이전트의 모든 행동은 크리덴셜 행동이다. 이걸 거버넌스의 전환으로 받아들이는 팀은 앞으로 2년을, 이미 믿고 쓰던 신원 프로그램을 넓히는 데 쓴다. 이걸 프로비저닝 작업쯤으로 넘기는 팀은 그 2년을, 서비스 계정 사후 보고서를 다시 쓰는 데 쓴다. 맨 위에 적힌 숫자만 더 커진 채로.