한 줄 정의

Agent Identity라는 말은 Agent마다 검증 가능한 신원을 주고, 그 agent가 어떤 도구와 리소스에 접근했는지 추적하게 만드는 거버넌스 개념이야. 사람 사용자 로그인과도 다르고, 여러 워크로드가 같이 쓰는 서비스 계정 하나로 모든 호출을 처리하는 방식과도 달라.

Google Cloud의 엔터프라이즈 에이전트 플랫폼 문맥에서는 이 기능이 govern 묶음에 들어가. Google Cloud는 2026년 4월 23일 발표에서 Agent Identity, Agent Registry, Agent Gateway를 함께 제시했고, 공식 문서는 Agent Identity가 SPIFFE 기반의 암호학적 신원으로 MCP 서버, 클라우드 리소스, 엔드포인트, 다른 agent에 인증한다고 설명해.

어떻게 작동하나

핵심은 agent를 하나의 접근 주체로 다루는 거야. 이 기능은 agent마다 고유한 암호학적 신원을 주고, Google Cloud 쪽 access token을 agent의 고유한 X.509 인증서에 묶어서 토큰 탈취 위험을 줄이는 방식으로 설명돼. 서비스 계정처럼 여러 워크로드가 기본으로 같이 쓰거나, 개발자가 장기 서비스 계정 키를 만들어 들고 다니는 구조와는 결이 달라.

인증 모델도 하나가 아니야. 공식 overview는 5가지를 이렇게 나눠.

  • 3-legged OAuth: agent가 Jira나 GitHub 같은 외부 서비스를 특정 사용자 대신 접근할 때 쓴다.
  • Cloud-based identity: Agent Runtime 위의 agent가 Google Cloud 서비스에 자기 권한으로 접근할 때 쓴다.
  • 2-legged OAuth: 외부 서비스가 machine-to-machine OAuth를 지원할 때 쓰는 경로야.
  • API key: 암호 키가 필요한 외부 서비스의 credential provider로 관리해.
  • HTTP basic 인증: 표에는 있지만 평문 비밀번호를 쓰기 때문에 권장하지 않는 방식으로 따로 표시돼.

여기서 auth manager의 역할이 나온다. API key, OAuth client ID, OAuth client secret, 사용자 위임 OAuth token을 어떻게 취득하고 보관하고 보호할지 provider 설정으로 관리해. MCP 서버나 SaaS API를 부르는 agent를 만들 때, 모델 프롬프트 안에 비밀값을 넣는 게 아니라 신원과 토큰 관리 계층을 따로 두는 셈이야.

로그도 같이 봐야 해. Agent Runtime guide는 Cloud Logging을 켜면 agent가 사용자 대신 행동할 때 agent 신원과 사용자 신원이 모두 로그에 남고, agent가 자기 권한으로 행동하면 agent 신원만 남는다고 설명해. 이 차이가 중요해. 고객지원 agent가 상담원의 권한으로 CRM을 읽는 경우와, 야간 배치 agent가 자기 권한으로 BigQuery 작업을 실행하는 경우는 감사 로그에서 다른 사건으로 남아야 해.

왜 중요한가

에이전트가 답변만 만들 때는 “어떤 모델이 좋은가”가 먼저 보인다. 그런데 외부 도구를 호출하고, 사내 데이터에 접근하고, 여러 사용자를 대신해 작업하면 질문이 바뀌어. 어느 agent가 어떤 권한으로 어떤 리소스에 접근했는지, 사용자를 대신한 건지 자체 권한으로 행동한 건지, 나중에 감사 로그에서 재구성할 수 있는지가 더 중요해져.

예를 들어 채용 agent가 후보자 정보를 읽고 캘린더 초대를 만든다고 해보자. 이때 agent 자체 권한으로 모든 캘린더를 수정하게 두면 사고가 났을 때 책임 경계가 흐려져. 사용자 위임 OAuth라면 특정 사용자의 동의와 scope 안에서 움직이고, 로그에도 agent와 사용자 신원을 같이 남길 수 있어. 같은 “캘린더 API 호출”이어도 운영 판단은 완전히 달라진다.

다른 장면은 데이터 분석 agent야. 이 agent가 매일 아침 BigQuery를 읽고 보고서를 만들면 사람 사용자 위임보다 agent 자체 권한이 더 자연스러울 수 있어. 대신 IAM은 좁게 줘야 해. Agent Runtime identity guide는 특정 agent, 프로젝트의 모든 agent, 조직의 모든 agent 같은 principalSet 패턴을 보여 주는데, 공통 권한은 넓게 주더라도 민감한 데이터 권한은 개별 agent에 좁게 주는 식으로 읽는 게 맞아.

Agent Platform 관점에서도 신원은 가운데에 있어. Agent Observability가 실행 흔적과 지표를 보여 주고, Agent Gateway가 통신과 정책을 통제한다면, 이 신원 계층은 “그 일을 한 주체가 누구였나”를 잡아 준다. 셋 중 하나만 있어도 부족해. trace가 있어도 신원이 없으면 책임을 묻기 어렵고, 신원이 있어도 관측이 없으면 어디서 실패했는지 좁히기 어렵다.

주의해서 볼 점

첫째, Agent Identity를 API key 보관함 정도로 축소하면 안 돼. auth manager가 API key와 OAuth token을 관리하긴 하지만, 이 개념의 중심은 agent별 신원, 사용자 위임과 자체 권한의 분리, IAM과 감사 로그야. 비밀값 저장만 필요하다면 그건 더 좁은 문제야.

둘째, 신원이 있다고 안전이 자동으로 끝나는 건 아니야. Agent Identity가 있어도 agent가 과한 OAuth scope를 받거나, MCP 도구가 민감한 데이터를 그대로 반환하거나, 로그에 개인정보가 남으면 여전히 운영 문제가 생겨. 도구별 scope, 승인 절차, 로그 마스킹, 보관 기간은 따로 정해야 해.

셋째, Preview 표시를 가볍게 넘기면 안 돼. Google 문서는 Agent Identity와 여러 인증 모델에 Preview 표시를 붙이고, Use Agent Identity with Agent Runtime 문서는 2026년 5월 5일 UTC 기준으로 갱신돼 있어. 실제 도입 전에는 리전, IAM, Gateway 연동, Cloud Logging 동작을 현재 문서로 다시 확인해야 해.

넷째, SPIFFE 기반이라는 말과 벤더 독립성을 같은 뜻으로 읽으면 곤란해. SPIFFE는 동적 환경에서 software system을 식별하기 위한 오픈 표준 묶음이지만, Google Cloud의 agent principalSet, Agent Runtime, Context-Aware Access, Agent Gateway 정책은 Google Cloud 운영 표면 안에서 동작해. 여러 클라우드에 agent를 나눠 둘 계획이면 신원 표준과 각 벤더 정책을 따로 비교해야 해.