AWS 위에서 실행되거나 AWS를 대상으로 동작하는 에이전트는 장기 자격 증명을 절대 보유해서는 안 된다. IAM 사용자도, 시크릿 매니저에 넣어둔 액세스 키도, 공유 "agents" 서비스 계정도 마찬가지다. AWS가 제공하는 진지한 인증 경로, 즉 인스턴스 프로파일, IRSA, EKS Pod Identity, OIDC 페더레이션, IAM Roles Anywhere, AgentCore Identity는 전부 같은 일을 하기 위해 존재한다: 검증 가능한 신원 증명을 스스로 만료되는 임시 자격 증명으로 교환하는 것이다. 에이전트 플랫폼이 이 규칙에서 출발하면 어려운 질문 대부분은 저절로 답이 나온다.

어제 자매 사이트에 이 문제의 프로토콜 계층을 다룬 글을 올렸다: SEP-1046이 MCP 에이전트에 제대로 된 client credentials 스토리를 부여한다는 내용으로, 서명된 JWT assertion이 공유 시크릿을 대체하는 이야기였다. 이 글은 그 아래 계층이다: 에이전트의 대상이 AWS 자체이거나, 에이전트가 AWS 위에서 돌면서 다른 모든 것에 접근해야 할 때, 그 신원은 실제로 어떤 모습인가? 거의 모든 경우에 답은 SEP-1046이 선택한 것과 같은 형태다: 수명이 짧은 서명 토큰을 넣으면 수명이 짧은 자격 증명이 나온다. AWS는 이 패턴을 수년간 대규모로 운영해 왔다. 정적 키로 그 흐름에 맞서는 일을 그만두기만 하면 된다.

모든 것의 바탕에 있는 하나의 패턴: OIDC 페더레이션

제품 이름을 걷어내면 AWS 에이전트 인증은 하나의 메커니즘이다. 아이덴티티 공급자가 워크로드에 대한 JWT에 서명한다. 그 공급자의 issuer URL을 IAM에 OIDC 아이덴티티 공급자로 등록하면, IAM이 /.well-known/openid-configuration 디스커버리 문서를 통해 공급자의 jwks_uri에서 공개 키를 가져온다. 워크로드가 sts:AssumeRoleWithWebIdentity에 토큰을 제시하면 한 시간 안에 만료되는 역할 자격 증명을 받는다. 역할의 신뢰 정책은 토큰의 aud와 sub 클레임에 대한 조건으로 누가 들어올 수 있는지 못 박는다.

플랫폼 팀이라면 누구나 이미 아는 버전이 GitHub Actions다: 러너가 받는 OIDC 토큰의 sub 클레임에 리포지토리와 브랜치가 인코딩되고, 역할 신뢰 정책이 repo:my-org/my-repo:ref:refs/heads/main을 매칭하며, 액세스 키는 리포지토리 시크릿에 결코 존재하지 않는다. 이것은 CI용 잔기술이 아니다. 에이전트를 포함한 모든 무인 워크로드의 템플릿이다. 저장된 시크릿을 서명되고 audience에 바인딩된, 수명 몇 분짜리 assertion으로 대체하는 것은 MCP 계층에서 private_key_jwt가 하는 일과 정확히 같다. 업계가 두 방향에서 하나의 답으로 수렴했고, 이는 대개 그 답이 옳다는 신호다.

에이전트가 어디서 도는지가 메커니즘을 결정한다

페더레이션을 직접 구축하는 일은 드물다. 런타임에 맞는 패키징을 고르면 된다:

  • EC2 또는 ECS 위: 인스턴스 프로파일 또는 태스크 역할. SDK 자격 증명 체인이 알아서 집어 가므로 에이전트에서 설정할 것이 없다. 여기서 에이전트 프레임워크가 액세스 키를 요구한다면 그것은 프레임워크의 냄새지, AWS의 요구 사항이 아니다.
  • EKS 위: 선택지가 둘이다. IRSA(IAM Roles for Service Accounts)는 오래된 쪽이다: 클러스터가 OIDC issuer를 노출하고, 이를 IAM에 등록한 뒤 ServiceAccount에 역할 ARN을 어노테이션으로 단다. EKS Pod Identity는 새로운 쪽이다: 클러스터별 OIDC 공급자 등록이 없고, 노드의 에이전트 애드온이 자격 증명을 교환하며, 역할 신뢰 정책은 클러스터별 issuer URL 대신 pods.eks.amazonaws.com을 한 번만 대상으로 잡는다. 클러스터가 여러 대라면 Pod Identity가 실질적인 수고를 덜어 주고, 한 대뿐이라면 어느 쪽이든 괜찮다. 둘 다 종착지는 같다: 에이전트 워크로드당 IAM 역할 하나, 파드 안에는 키 없음.
  • AWS 밖, IdP가 있는 경우: 위에서 설명한 그대로의 OIDC 페더레이션이다. 데이터센터 워크로드든, 다른 클라우드든, SaaS 러너든 자신의 아이덴티티 공급자에 인증한 뒤 페더레이션으로 들어온다. GitHub Actions 패턴의 일반화다.
  • AWS 밖, IdP가 없는 경우: IAM Roles Anywhere. 워크로드가 신뢰 앵커로 등록한 CA(AWS Private CA 또는 자체 PKI)가 발급한 X.509 인증서를 제시하고, 프로파일을 통해 임시 역할 자격 증명으로 교환한다. 솔직한 단서 하나: 인증서 수명 주기 관리, 즉 발급, 교체, 폐기를 떠안게 된다. 이미 PKI를 운영하고 있지 않다면, 아이덴티티 공급자를 세우는 편이 PKI를 도입하는 것보다 대개 운영 부담이 적다.

AgentCore Identity: 그 위에 얹힌 에이전트 전용 계층

IAM은 "이 워크로드가 AWS를 어떻게 호출하는가"에 답한다. 에이전트에는 문제가 둘 더 있다: 누가 에이전트를 호출할 수 있는가, 그리고 에이전트가 Slack, GitHub, Google 같은 비 AWS 서비스에 사용자를 대신해 어떻게 접근하는가. Amazon Bedrock AgentCore Identity가 맡는 부분이 바로 이 조각이고, AgentCore를 쓸 일이 없더라도 알아둘 가치가 있다. 역할 하나로는 부족한 에이전트 신원의 요건을 AWS가 문서로 정리해 둔 셈이기 때문이다.

  • 에이전트용 워크로드 아이덴티티. 각 에이전트가 공유 principal이 아니라 자기만의 디렉터리 항목을 갖는다. IAM 역할의 워크로드당 아이덴티티 하나 규칙을 한 단계 위에 그대로 적용한 것이다.
  • 인바운드 인증. 호출자는 평범한 SigV4(늘 하던 IAM 방식)로, 또는 JWT authorizer를 통해 에이전트에 도달한다: 디스커버리 URL과 허용 audience를 설정하면 Cognito, Okta, Entra ID 토큰이 에이전트의 관문이 된다. AgentCore Gateway는 툴 엔드포인트에도 같은 CUSTOM_JWT authorizer를 노출하는데, AWS 위의 MCP 성격 게이트웨이가 이전 글에서 다룬 토큰 발급의 결과물을 검증하는 방식이 바로 이것이다.
  • 아웃바운드 인증. 토큰 볼트가 서드파티 서비스용 OAuth 그랜트를 보관한다. 서비스 간에는 2-legged, 사용자가 한 번 동의하고 에이전트가 나중에 그 동의를 바탕으로 행동하는 경우에는 3-legged다. 환경 변수에 붙여 넣은 refresh token 대신 동의를 서버 쪽에 저장하는 대리 행동 패턴이다.
  • 가격 각주. AgentCore Runtime이나 Gateway를 통해 쓰면 추가 비용이 없고, 단독 사용은 성공한 OAuth 토큰 또는 API 키 요청당 과금된다. 어느 쪽이든 저렴하다. 비싼 것은 언제나 이렇게 해서 피하게 되는 인시던트였다.

이 모든 것 위의 프로토콜 계층도 계속 움직이고 있다. MCP 스펙 저장소의 auth 대기열에는 게이트웨이가 1년 안에 만나게 될 제안들이 있다. 혼합 인증 서버를 위한 도구 메타데이터의 securitySchemes(SEP-1488), 세션 중간에 OAuth 플로우를 트리거하는 표준화된 도구 오류(SEP-1489), 원격 서버의 인증 방식 사전 선언(SEP-2742). AWS에서 MCP 게이트웨이를 운영한다면 EKS 릴리스 노트를 보듯 이 라벨을 지켜봐야 한다.

감사에서 실제로 묻는 것은 귀속이다

임시 자격 증명은 탈취 문제를 해결하지만, "이 일을 한 것이 어느 에이전트인가"까지 저절로 해결해 주지는 않는다. 세 가지 습관이 그 틈을 메운다. 에이전트당 역할 하나: CloudTrail의 역할 세션 이름만으로 워크로드가 드러난다. assume 시점에 설정하는 sts:SourceIdentity: 에이전트를 트리거한 사람이나 시스템이 역할 체이닝을 거쳐도 모든 다운스트림 로그 라인까지 살아남는다. 그리고 넓은 역할을 당면 작업 수준으로 좁히는 세션 정책: 프롬프트 인젝션을 당했거나 그냥 잘못 동작한 에이전트의 폭발 반경이 역할 전체가 아니라 그 작업의 권한에 그친다. 상시 권한은 읽기 전용으로 유지하고 모든 변경 작업에는 게이트를 세워라. 이 주장은 이미 여러 번 해서 단골 독자라면 외울 정도다.

월요일에 할 일

  • aws iam list-users를 돌리고, 자동화에 속하면서 활성 액세스 키를 가진 IAM 사용자를 전부 발견 사항으로 취급하라. 에이전트도 자동화다.
  • 각 에이전트를 런타임에 매핑하고 맞는 메커니즘을 도입하라: 인스턴스/태스크 역할, IRSA 또는 Pod Identity, OIDC 페더레이션, Roles Anywhere. 선호 순서도 이 순서다.
  • 모든 OIDC 신뢰 정책을 aud와 작성 가능한 가장 좁은 sub 패턴에 고정하라. sub 조건이 없는 신뢰 정책은 그럴듯한 간판이 달린 열린 문이다.
  • 모든 에이전트의 assume-role 호출에 sts:SourceIdentity를 설정하고 CloudTrail 쿼리가 이를 사용하게 하라. 인시던트가 터진 뒤에 귀속을 소급 적용하는 것은 통하지 않는다.
  • AgentCore를 쓰고 있다면 에이전트 앞에 JWT authorizer를 세우고 서드파티 OAuth 그랜트를 토큰 볼트로 옮겨라. 쓰지 않는다면 그 형태를 그대로 가져와라: 에이전트별 아이덴티티, 검증된 인바운드 토큰, 서버 쪽 동의 저장.

MCP 글과 이어지는 흐름은 놓치기 어렵다. 프로토콜마다, 플랫폼마다, 에이전트 신원은 서명된 단기 assertion, audience 바인딩, 워크로드별 principal로 수렴하고 있고, 이제 두 계층 모두에 필요한 조각이 존재한다. 아직도 에이전트 설정에 액세스 키를 복사해 넣는 팀은 무언가의 얼리 어답터가 아니다. 2026년 워크로드에 2015년 보안 태세를 돌리고 있는 것이다.

이어서 읽기

Agent Toolkit for AWS: The Docs Have a New Reader는 이렇게 인증된 에이전트가 AWS 접근 권한으로 실제로 무엇을 하는지 다룬다. 자매 사이트의 Enterprise MCP Auth: Agents Finally Get Service Accounts는 이 글의 프로토콜 계층 절반이고, ercanermis.com에는 내가 쓰는 나머지 모든 글이 정리되어 있다.

참고 자료