에이전트가 IAM 워크로드가 되고 있다. 기존 서비스 계정은 준비되어 있지 않다

먼저 기존 접근법의 논리를 가장 강한 형태로 제시해 보자. 그 논리는 결코 어리석지 않다. 서비스 계정과 API 키는 20년 동안 머신 워크로드를 떠받쳐 왔다. 모두가 이해하고 있고, 감사 대상이며, 모든 클라우드와 SaaS 도구가 지원하고, 보안팀에는 이미 목록을 정리한 스프레드시트도 있다. 누군가 에이전트에 새로운 ID 범주가 필요하다고 말하면 합리적인 반응은 이렇다. 이미 비인간 ID라는 범주가 있으니 그걸 쓰면 된다.

하지만 바로 여기서 그 방식이 멈춘다. 서비스 계정은 "어떤 시스템이 호출하고 있는가?"라는 질문에 답한다. 에이전트는 더 어려운 질문을 요구한다. "어떤 에이전트가, 누구를 대신해, 어떤 목표를 향해 호출하고 있으며, 앞으로 30초 안에 누가 그 권한을 취소할 수 있는가?" IAM 업계 자체의 수치에 따르면 비인간 ID는 이제 인간 ID보다 한 자릿수 배 이상 많다. 또한 2026 Verizon DBIR은 에이전트형 AI가 도입되면서 서비스 계정과 머신 계정을 주의 깊게 봐야 한다고 경고했다고 Token Security의 보고서 해설은 설명한다. 이 글은 기존 매핑이 왜 실패하는지, 무엇이 그 대안으로 만들어지고 있는지, 그리고 그 실패가 이미 어떤 모습으로 나타났는지를 다룬다.

핵심 요약 - 서비스 계정과 API 키는 안정적이고 결정론적인 호출자를 전제로 한다. 에이전트는 일시적이고 비결정론적이며 서로 권한을 위임하므로, 공유 자격 증명에 전제된 감사, 취소, 최소 권한 모델을 깨뜨린다. - 표준의 방향은 에이전트별 워크로드 ID다. IETF WIMSE 워킹그룹에는 토큰 scope만이 아니라 ID 자체로 에이전트를 구별하도록 요구하고, 정책, 감사, 취소를 위해 SPIFFE 스타일의 에이전트별 식별자를 사용하자는 제안이 진행 중이다. - 사고는 이미 현실적이다. Salesloft Drift 생태계에서 탈취된 OAuth 토큰은 기업 Salesforce 환경으로 이동하는 데 사용됐고, 7월 Hugging Face 침해는 자율형 에이전트가 처음부터 끝까지 실행했다. - 구현 가이드도 수렴하고 있다. 에이전트별 전용 ID, 모델 컨텍스트 밖에서 발급되는 짧은 수명의 작업 범위 자격 증명, 그리고 공유 역할이 아니라 에이전트를 기준으로 연결되는 감사 추적이다. - 모든 에이전트가 하나의 공유 서비스 계정으로 인증한다면 로그만으로 어떤 에이전트가 무엇을 했는지 알 수 없다. 이번 주에 적용할 테스트가 바로 이것이다.

무슨 일이 있었나

8월 첫 몇 주 동안 두 흐름이 합쳐졌다. 첫째, 표준 논의가 구체화됐다. 8월 4일 제출된 IETF WIMSE 아키텍처 초안 issue는 AI 중개자에 대한 현재 초안의 문구가 너무 약하다고 주장한다. 초안은 자율 에이전트의 행동을 구분하기 위해 "separate workload identities or token scopes"를 허용하지만, 해당 issue는 token scope로는 충분하지 않다고 설명한다. Scope는 토큰이 무엇을 할 수 있는지를 제한할 뿐, 그 토큰이 누구인지는 바꾸지 않는다. 하나의 자격 증명을 공유하는 여러 에이전트는 scope가 아무리 달라도 감사 로그, 취소 시스템, 에이전트별 정책에서 구별되지 않는다. 제안된 해결책은 관리형 에이전트 플랫폼이 각 에이전트에 고유한 workload identifier를 부여하고, 전용 claim에 담아 정책, 감사, 취소를 위한 안정적인 키로 사용하는 것이다. 배포된 각 에이전트에 해당 agent resource와 연결된 SPIFFE 기반 ID를 부여하는 Google의 agent identity 설계가 실제 작동하는 예로 언급된다.

둘째, 사고가 계속 이어졌다. 7월 중순의 Hugging Face 침해는 이름이 공개된 기업에서 자율 에이전트가 처음부터 끝까지 수행한 최초의 공개 침입 사례였다. Dataset pipeline에서 코드 실행, 자격 증명 수집, 내부 클러스터 간 lateral movement, 주말 동안 수천 건의 작업이 이어졌다. 같은 해 초에는 AI 에이전트용 소셜 네트워크 Moltbook이 에이전트 계정 150만 개에 도달한 지 며칠 만에 설정이 잘못된 데이터베이스에서 API 토큰 150만 개를 노출했다고 Studio Global의 정리는 전한다. 그리고 DBIR이 반복적으로 드는 비인간 ID 공격 사례인 Salesloft Drift OAuth 토큰 침해는 Google, Cisco, Zscaler 등 주요 기업의 Salesforce 환경에 접근하는 데 사용됐다. 이것이 바로 에이전트가 의존하는 자격 증명의 위험 형태다.

2026년 8월 IETF WIMSE issue는 에이전트 행동을 token scope가 아닌 별도의 workload identity로 구별하고, 에이전트별 식별자를 정책, 감사, 취소를 위한 안정적인 키로 사용해야 한다고 제안했다. 이는 7월 Hugging Face의 에이전트 주도 침해와 1월 Moltbook 에이전트 플랫폼에서 API 토큰 150만 개가 유출된 사고 뒤에 나왔다.

서비스 계정과 API 키가 에이전트에 맞지 않는 이유

이 불일치에는 네 가지 측면이 있다. 해결책이 다르기 때문에 각각 따로 이름 붙일 가치가 있다.

공유 ID는 행위 귀속을 무너뜨린다. 서비스 계정은 공유되고, 정적이며, 넓은 권한을 갖도록 설계됐다. 하나의 계정 아래 에이전트 10개를 두면 감사 로그에는 행위자 하나만 나타난다. Cockroach Labs의 현장 분석이 설명하듯 어떤 에이전트가 어떤 데이터에 접근했는지 알 수 없고, 자격 증명 rotation은 모든 에이전트와 조정해야 하며, 계정 권한은 결국 어느 에이전트든 과거에 한 번이라도 필요했던 모든 권한의 합집합으로 늘어난다. 그들의 익명 사례는 내가 고객 팀에서 여러 형태로 들은 이야기와 비슷하다. 개발 과정에서 전체 고객 데이터베이스에 읽기 권한을 받은 지원 에이전트가 프로덕션 전에 권한이 축소되지 않은 채 세 달간 그대로 운영된 사례다.

에이전트는 일시적이지만 키는 그렇지 않다. 하나의 agentic workflow는 몇 초 안에 모델 공급자, 벡터 스토어, API 세 개, 클라우드 스토리지에 인증한 뒤 사라질 수 있다. 장기 API 키는 일정에 따라 rotation할 가치가 있는 지속적인 호출자를 전제로 한다. 이 불일치는 sprawl을 만든다. 아무도 기억하지 못하는 에이전트용 키가 여전히 유효하고, 여전히 넓은 권한을 갖고 남는다.

위임은 "누구를 대신하는가"라는 사슬을 끊는다. 사용자를 대신해 행동하는 에이전트와 자율적으로 행동하는 에이전트는 정책 엔진에서 전혀 다르게 보여야 한다. 공유 서비스 계정을 쓰면 둘은 동일하게 보인다. OAuth 위임은 사용자 사례를 비교적 잘 처리하지만, 자율 사례에는 에이전트 자체의 ID가 필요하다. 또한 multi-agent delegation에서는 각 hop이 전달받은 권한을 넓히는 것이 아니라 좁혀야 한다.

모델이 비밀을 직접 보유해서는 안 된다. 이것은 설정 문제가 아니라 구조 문제다. Context window에 전달된 자격 증명은 모델과 모델을 조작할 수 있는 모든 것에 노출된다. Prompt injection은 에이전트의 자체 출력을 이용해 이를 외부로 빼낼 수 있다. 해결책은 작업 시점에 token service가 발급하는 짧은 수명과 제한된 scope의 자격 증명을 tool-execution layer가 보관하는 것이다. 모델은 호출을 유발하지만 비밀은 모델 컨텍스트에 들어가지 않는다. Cockroach Labs가 이 점을 잘 설명하고 있으며, 내가 셀프호스팅 에이전트 스택을 구축하는 고객에게 말하는 것과도 같다. 키는 harness가 들고, 의도는 모델이 든다.

공유 서비스 계정은 로그에 하나의 행위자만 남겨 에이전트 행위의 귀속을 깨뜨리고, 일시적인 에이전트 워크로드보다 오래 살아남으며, 사용자 위임 행동과 자율 행동의 경계를 흐리고, prompt injection이 닿을 수 있는 모델 컨텍스트로 자격 증명을 넘기게 만든다. Cockroach Labs와 miniOrange의 비교가 지적하는 문제다.

공급업체와 표준 기관이 만드는 것

새롭게 나타나는 구조는 세 계층이다. 고무적인 점은 공급업체와 표준 담당자들이 대체로 같은 형태에 수렴하고 있다는 것이다.

에이전트별 워크로드 ID. 앞서 본 WIMSE 방향이 표준 관점의 해법이다. 각 logical agent에 고유하고 안정적인 식별자를 부여한다. 제안된 형태는 SPIFFE URI이며, 공유 execution role과 별개다. 그리고 그 식별자를 정책, 감사, 취소의 키로 사용한다. 플랫폼 관리형 에이전트가 하나의 실행 자격 증명을 공유하더라도 에이전트별 claim을 추가해야 한다. 가장 중요한 변화는 이것이다. Deployment별 ID가 아니라 에이전트별 ID다.

저장된 secret 대신 federation. Descope의 에이전트용 workload identity federation 설명은 패턴을 잘 보여준다. AWS IAM role이나 IRSA를 통한 Kubernetes service account 같은 에이전트의 플랫폼 ID를 identity platform의 짧은 수명과 제한된 scope를 가진 토큰으로 교환한다. 플랫폼은 에이전트의 directory record도 만들어 토큰 수명이 끝난 뒤에도 audit trail이 남도록 한다. 유출될 장기 키가 없고, ID 레코드는 개별 자격 증명보다 오래 유지된다.

Discovery와 governance가 시장이 된다. 상용 시장에서는 Reco, Token Security, Oasis, Aembit 같은 non-human identity vendor들이 에이전트를 중심으로 제품을 재배치하고 있다. 모든 에이전트 자격 증명을 발견하고, 소유자와 매핑하고, 과도한 권한을 표시하고, 깨끗하게 revoke하는 것이다. Reco의 접근은 실무적이다. 사용자 행동에는 delegated OAuth, 자율 행동에는 dedicated workload identity처럼 에이전트 역할에 ID 유형을 맞추고, 책임이 커질수록 권한을 다시 검토한다. 에이전트는 직원이 건물 열쇠를 하나씩 더 갖게 되는 것처럼 권한을 축적하기 때문이다. 2025년 12월 발표된 OWASP Top 10 for Agentic Applications는 Identity and Privilege Abuse를 독립적인 최상위 위험 범주로 명시해 보안팀이 감사 결과를 논의할 공통 언어를 제공했다. 이 계층이 전체 스택 어디에 들어갈지는 tooling만큼 governance의 문제다. 조직 측면은 AI 에이전트 거버넌스에서 다룬다.

새 아키텍처는 WIMSE 논의가 제안하는 정책, 감사, 취소 키로서의 SPIFFE 스타일 에이전트별 workload identity, Descope가 보여주는 플랫폼 ID에서 짧은 수명의 scoped token으로의 federation과 지속되는 agent directory record, 그리고 non-human identity의 discovery와 least-privilege governance를 제공하는 vendor 시장으로 수렴하고 있다.

에이전트 ID가 잘못될 때

세 사고, 세 가지 서로 다른 실패 모드, 모두 배울 점이 있다.

Hugging Face, 2026년 7월: 공격자의 ID 문제는 방어자의 문제이기도 했다. 에이전트 주도 침입은 코드 실행 worker에서 클라우드 및 클러스터 자격 증명을 수집하고 lateral movement를 수행했다. 전형적인 과도한 권한의 workload 이야기다. 데이터 처리 구성 요소가 훔칠 가치가 있는 자격 증명을 갖고 있었다. 덜 알려진 세부 사항은 Hugging Face가 공개한 forensic asymmetry다. 공격 에이전트에는 사용 정책이 없었던 반면, 회사의 자체 포렌식은 처음에 사용하려던 hosted model의 guardrail 때문에 차단됐다. 결국 자체 인프라에서 open-weight 모델 GLM 5.2를 사용해 포렌식 분석을 수행했다. 같은 사고의 양쪽에서 나타난 ID와 접근 제어의 실패다.

Salesloft Drift, DBIR의 경고: 토큰이 만능열쇠가 될 때. 한 공급업체 생태계에서 침해된 OAuth 토큰은 주요 기업의 Salesforce 환경으로 이동하는 데 사용됐다. 비밀번호도, 사람 대상 phishing도 없었다. 넓게 신뢰되고 조용히 재사용되는 비인간 자격 증명이었다. 장기 OAuth grant로 SaaS 도구에 연결한 모든 에이전트는 같은 형태의 위험을 갖는다. 대응책 역시 같은 형태다. 짧은 수명, 좁은 scope, 에이전트별 분리, revoke 가능성이다.

Moltbook, 2026년 1월: 에이전트 플랫폼은 ID 위험을 한곳에 모은다. 에이전트 계정 플랫폼의 잘못 구성된 데이터베이스에서 API 토큰 150만 개와 이메일 주소, 에이전트 간 메시지가 노출됐다고 Studio Global은 전한다. 에이전트 ID를 중앙화하면 blast radius도 중앙화된다. 다만 유통되는 사고 세부 사항 중 일부는 감사된 사실이 아니라 보도된 내용으로 보는 것이 맞다. Hugging Face 자체 공개는 1차 자료지만, Moltbook 수치는 2차 보도에서 나온다.

문서화된 에이전트 ID 실패 사례에는 자율 에이전트가 클라우드와 클러스터 자격 증명을 수집해 lateral movement를 수행한 2026년 7월 Hugging Face 침해, Waxell 분석, Salesloft Drift OAuth 토큰으로 기업 Salesforce tenant에 접근한 사례, 2026 DBIR에 대한 Token Security 분석, 그리고 Moltbook의 에이전트 API 토큰 150만 개 유출이 포함된다.

지금 해야 할 일

1. 이번 주: 에이전트의 자격 증명을 전부 열거하고 귀속 테스트를 적용하라. 로그에서 아무 에이전트 작업 하나를 골라 어느 에이전트가 했는지, 누구를 대신했는지, 다른 에이전트에는 영향을 주지 않고 그 에이전트만 revoke할 수 있는지 확인한다. 답이 "아니다"라면 공유 ID 문제가 있고, 가장 먼저 고칠 항목이다.

2. 이번 달: 자율 에이전트 하나를 장기 자격 증명에서 분리해, token service나 identity platform이 발급하는 짧은 수명과 task scope의 토큰으로 옮긴다. 자격 증명은 tool-execution layer에 두고 모델 컨텍스트에는 절대 넣지 않는다. 가장 넓은 접근권한을 가진 에이전트부터 시작하라. 대개 누군가 급하게 "임시로" 넓은 scope를 준 에이전트다.

3. 이번 분기: 각 logical agent에 고유한 안정적 ID를 부여하라. 인프라가 있다면 SPIFFE ID, 없다면 에이전트별 고유 서비스 계정을 사용하고, audit과 alerting을 그 ID에 연결한다. 필요해지기 전에 revoke runbook도 작성한다. 아직 초기 단계에서 에이전트를 어디서 실행할지 결정 중이라면 로컬 대 클라우드 AI 에이전트의 trade-off가 이 계층을 얼마나 직접 통제할 수 있는지 결정한다.

FAQ

IAM 관점에서 에이전트 ID란 무엇인가

개별 AI 에이전트에 부여되는 독립적이고 검증 가능한 ID다. 에이전트가 실행되는 플랫폼 및 대신 행동하는 사용자와 분리된다. 인증, 권한 부여 정책, 감사 추적, 취소를 위한 안정적인 키로 사용된다. Workload identity가 마이크로서비스를 식별하는 것과 비슷하지만, 일시적이고 비결정론적이며 서로 위임할 수 있는 호출자에 맞춰 설계된다.

에이전트가 서비스 계정을 그냥 공유하면 왜 안 되는가

기술적으로 가능하고, 오늘날 대부분 그렇게 한다. 문제는 감사 로그에 실제 에이전트가 아니라 공유 계정이 표시되어 행위 귀속을 잃고, 계정 권한이 모든 에이전트의 필요 권한을 합친 수준으로 커지며, 하나의 에이전트를 revoke하려면 모두의 자격 증명을 rotation해야 하고, 사용자 위임 행동과 자율 행동을 구분할 수 없다는 것이다. 첫 사고가 나기 전까지는 작동한다. 사고 후에는 무슨 일이 있었는지 재구성할 수 없다.

표준 기관은 에이전트 ID에 대해 무엇을 하고 있는가

IETF WIMSE 워킹그룹은 workload identity architecture를 AI intermediaries로 확장하고 있다. Token scope에 의존하는 대신 에이전트별 식별자를 요구하는 활성 제안이 있으며, SPIFFE URI가 권장 메커니즘으로 제시된다. OWASP는 2025년 12월 Top 10 for Agentic Applications를 발표하면서 identity and privilege abuse를 명시적 범주로 포함했고, Cloud Security Alliance에는 에이전트별 고유 ID를 권장하는 agent identity governance framework가 있다.

에이전트 자격 증명이 모델 컨텍스트에 들어가도 되는 경우가 있는가

없다. Context window에 있는 것은 모두 모델에 보이며 prompt injection으로 유출될 수 있다. 받아들여지는 패턴은 작업 시점에 token service가 자격 증명을 발급하고, 모델과 API 사이의 tool-execution layer가 이를 보관하며, 작업에만 scope하고 수명을 짧게 하는 것이다. 모델은 작업을 요청하고, harness가 secret을 보관한다.

결론

ID 업계에는 "ID가 control plane이다"라는 말이 있다. 에이전트는 이 명제를 마이크로서비스보다 더 거칠게 시험할 것이다. 방향은 지금부터 준비할 수 있을 만큼 충분히 명확하다. 에이전트별 ID, 모델 밖의 secret, 사고가 퍼지기보다 빨리 만료되는 토큰, 그리고 "어떤 에이전트가, 누구를 대신해, 어떤 목표로"를 답할 수 있는 감사다. 이번 여름 피해를 입은 조직들은 특이한 아키텍처를 운영한 것이 아니었다. 공유 자격 증명을 사용하며 잘 되기를 바랐을 뿐이다. 그것이 닫아야 할 격차이며, 이를 해결할 기술은 대부분 이미 존재한다.

기존 IAM 환경에 에이전트 ID를 매핑하고 있고 실무 경험이 있는 사람이 논의에 함께하길 원한다면, 그것은 내가 하는 일이다. 연락하기.

출처

• IETF WIMSE WG, draft-ietf-wimse-arch issue #139, "AI and ML-Based Intermediaries: token scopes do not create per-agent identity": https://github.com/ietf-wg-wimse/draft-ietf-wimse-arch/issues/139 (제출 2026-08-04, 확인 2026-08-29)

• Cockroach Labs, "AI Agent Identity Security": https://www.cockroachlabs.com/blog/ai-agent-identity-security/ (게시 2026-07-17, 확인 2026-08-29)

• Token Security, "The 2026 Data Breach Investigations Report Confirms It: Identity Is the Control Plane for Agentic AI": https://www.token.security/blog/the-2026-data-breach-investigations-report-confirms-it-identity-is-the-control-plane-for-agentic-ai (게시 2026-05-20, 확인 2026-08-29)

• Descope, "What Is Workload Identity Federation for AI Agents?": https://www.descope.com/learn/post/workload-identity-federation-for-agents (게시 2026-06-22, 확인 2026-08-29)

• miniOrange, "Why AI Agents Need Workload Identity, Not Shared Secrets": https://www.miniorange.com/blog/workload-identity-ai-agents/ (게시 2026-05-20, 확인 2026-08-29)

• Reco, "Non-Human Identities for AI Agents: How to Govern Access": https://www.reco.ai/blog/non-human-identities-for-ai-agents (게시 2026-07-20, 확인 2026-08-29)

• Waxell, "Hugging Face Breach: How an AI Agent Ran the Attack": https://www.waxell.ai/blog/hugging-face-agentic-attacker-ai-breach-2026 (게시 2026-07-17, 확인 2026-08-29)

• Studio Global, "EU AI Act August 2026: Enforcement Powers Go Live as Autonomous Agent Breach Tests Regulators": https://www.studioglobal.ai/discover/answers/what-key-enforcement-powers-and-transparency-obligations-6a6bff1f2240a0fb8c880846 (게시 2026-08-17, 확인 2026-08-29)