프롬프트 하나, 에이전트 하나, AWS 계정 전체: Amazon Bedrock AgentCore의 AgentCorruption 내막

2026년 10월 8일, Zenity Labs가 공개한 AgentCorruption은 Amazon Bedrock AgentCore의 일련의 결함으로 인해, 외부에 공개된 에이전트 하나에 전달된 단일 자연어 프롬프트만으로 동일한 AWS 계정과 리전 내 모든 AgentCore 에이전트를 제어할 수 있게 되었다. Amazon Bedrock AgentCore는 AWS가 AI 에이전트를 배포하고 실행하기 위한 관리형 플랫폼이다. 이 연구는 SecTor 2026이 열린 토론토에서의 발표와 함께 공개되었다. Zenity의 보안 연구 책임자인 Tamir Ishay Sharbat가 이를 발표했다(Dark Reading, 2026년 10월 8일). Sharbat, Lana Salameh, Dmitry Lozovoy, João Donato의 이름으로 실린 Zenity 자체의 보고서는 그 메커니즘으로 시작한다. 아웃바운드 요청을 할 수 있는 도구를 하나라도 가진 AgentCore 에이전트는 AWS Instance Metadata Service (IMDS)를 호출하도록 유도될 수 있으며, 링크-로컬 주소 169.254.169.254에 위치한 이 서비스는 해당 에이전트 자체의 실행 역할에 대한 임시 자격 증명을 반환한다. Zenity는 이 자격 증명을 자사 머신으로 내보냈고 그곳에서도 작동함을 확인했다고 밝혔다. CVE 식별자는 부여되지 않았다.

아카이브는 이를 취약점으로 기록한다 — 발견된 것이지 반드시 악용된 것은 아니며, 높음 수준의 심각도, 신뢰도 A, 기록된 실제 피해 없음, AI 연관성 확인됨이다. 당사자들은 행위 자체에는 동의하면서도 프레이밍에 대해서는 의견이 갈린다. AWS는 Dark Reading에 이 연구가 "예상되고 문서화된 동작을 취약점으로 부정확하게 묘사한다"고 말했다.

그 체인이 실제로 무엇이었는지

AgentCore는 각 에이전트를 컨테이너로 패키징하고 세션별 Firecracker MicroVM에서 실행합니다. Zenity의 시리즈 첫 번째 글은 Strands SDK, AWS의 오픈소스 에이전트 프레임워크로 구축된 테스트 에이전트에 평범한 언어로 요청을 보내 전체 거점을 재현합니다. 이 프레임워크에는 기본 제공 HTTP 요청 도구와 셸 도구가 포함되어 있습니다. 마이크로VM은 메타데이터 서비스로 가는 트래픽을 제한하지 않았기 때문에 요청은 인스턴스 내부에서 발생했고 IMDS가 응답했습니다. 그 후 연구원들은 엔드포인트들을 하나씩 살펴봤습니다. IAM 역할 이름, 임시 STS 자격 증명 자체, user-data 엔드포인트—계정 ID, 전체 ARN, 런타임 URL, 그리고 에이전트의 Amazon Elastic Container Registry (ECR) 이미지 URI—그리고 mTLS 인증서 체인, 프라이빗 키, 내부 스토리지로의 presigned URL을 포함한 인스턴스 태그까지 확인했습니다. Zenity는 셸 도구를 통해서도 같은 결과가 나왔다고 말합니다. 격리 실패가 특정 도구가 아니라 플랫폼 수준에 있기 때문입니다.

그 흐름에 있는 두 가지 세부 사항은 그냥 지나치기 쉽다. 자격 증명은 샌드박스에 국한되지 않았다. Zenity는 자격 증명을 AgentCore 외부로 내보내고, 에이전트의 수임된 역할로 반환된 AWS 자격 증명 호출을 실행했다. 그리고 탈취된 역할은 컨테이너 이미지를 가져올 수 있었고, 그렇게 해서 에이전트의 소스 코드를 읽을 수 있게 되었다 — Zenity의 게시물은 이미지에 하드코딩된 키, 남겨진 토큰, 그리고 이미지에 내장되지 말았어야 할 구성이 흔히 들어 있으며, 가져온 이미지는 근간이 되는 비즈니스 로직의 지도라고 지적한다.

기본 역할은 발판이 계정으로 바뀐 지점입니다.

별도로 보고된 두 번째 결함은 AgentCore가 기본적으로 에이전트에 할당한 실행 역할이 단일 에이전트로 범위가 지정되지 않았다는 점입니다. Zenity는 권한이 계정과 리전의 모든 AgentCore 리소스 전반에 걸쳐 미친다고 설명하며, 그 대상에는 bedrock-agentcore:InvokeAgentRuntime, bedrock-agentcore:ListEvents, bedrock-agentcore:CreateEvent, bedrock-agentcore:DeleteEvent 그리고 자격 증명 체인의 끝에는 bedrock-agentcore:GetResourceApiKey 및 secretsmanager:GetSecretValue.

열거 가능성은 그 와일드카드를 대상 목록으로 바꾸었습니다. Zenity는 역할의 logs:DescribeLogGroups 권한을 사용했습니다. 왜냐하면 AgentCore는 각 에이전트의 CloudWatch 로그 그룹을 /aws/bedrock-agentcore/runtimes/AGENT_NAME-{ENDPOINT_NAME}로 명명하고, 그 로그 그룹 이름에서 에이전트 ID를 도출했기 때문입니다. ECR 리포지토리 이름은 연구자들이 관찰한 패턴을 따랐습니다 — bedrock-agentcore-<agent_name> — 따라서 해당 리전의 모든 에이전트 이미지를 풀할 수 있었습니다. 메모리 리소스도 같은 방식으로, 로그 그룹 패턴 /aws/vendedlogs/bedrock-agentcore/memory/APPLICATION_LOGS/{MEMORY_ID}에서 발견되었습니다. 그리고 역할의 ListActors, ListSessions 및 ListEvents 권한은 대화 내용을 읽는 데 필요한 액터 및 세션 식별자를 생성했습니다.

Zenity의 분석 글은 구체적인 측면 이동 시연을 제시한다: 공개적으로 노출된 에이전트를 통해 진입하여, billing_agent의 도구를 동일한 리전에서 발견하고, 파일 이름이 billing.json인 파일을 발견하고 파일 읽기 도구를 통해 유출한다. 보도자료는 동일한 시나리오를 일반적인 표현으로 설명한다 — 인터넷에 노출된 고객 서비스 에이전트를 통해 진입한 공격자는 동일한 리전에 배포된 내부 금융 에이전트로 이동하고, 이를 호출하여 해당 에이전트의 데이터, 도구, 관련 자격 증명 및 비공개 대화에 접근할 수 있다.

기억은 프롬프트보다 오래 남은 부분이었다

AgentCore Memory는 대화 자체를 단기 메모리로 유지하고 추출된 레코드를 장기 메모리로 저장하며, 다음 전략들을 사용합니다: SEMANTIC, USER_PREFERENCE, SUMMARIZATION 및 EPISODIC. Zenity는 CreateEvent를 사용해 다른 에이전트의 메모리 리소스에 대화 이벤트를 기록했습니다. 이 게시글은 해당 기본 연산이 무엇을 할 수 있고 무엇을 할 수 없는지 신중하게 다룹니다: CreateEvent는 호출자가 장기 네임스페이스를 선택하거나 레코드를 직접 덮어쓰도록 허용하지 않습니다 — 대상 메모리에 구성된 전략이 무엇이 추출되고 어디에 저장되는지를 결정합니다. Zenity는 또한 DeleteEvent가 도구 결과 이벤트를 제거해 에이전트가 누락된 데이터로 인해 잘못된 결론을 내리게 하고, 메모리를 심은 이벤트를 삭제해 흔적을 감추는 데 사용된다고 설명합니다.

쓰기 프리미티브가 만들어낸 것은 지속성이었다. Zenity의 시연은 에이전트가 답변하기 전에 연구진이 통제하는 페이지를 가져오고 그 페이지의 내용을 따르도록 하는 요청을 심었는데, 이는 또 다른 메모리를 심지 않고도 지침을 변경할 수 있는 명령 제어 엔드포인트였다. 그런 다음 동일한 채널이 대화 내용을 외부로 유출했다. 보고서는 에이전트가 사용자의 메시지와 자신의 답변을 수집 엔드포인트로 보낸다고 설명하고, 해당 역할에 대한 메모리 권한이 손상된 에이전트에만 국한되지 않고 계정과 리전 전반에 걸쳐 확장되었다고 밝힌다. 연구와 함께 공개된 영상은 사용자가 대화를 계속하는 동안 그 내용이 연구진의 서버에 도착하는 모습을 보여준다.

AWS 이외의 자격 증명

시리즈의 마지막 글은 연결된 도구에 대한 논의를 마무리합니다. AgentCore Identity와 Outbound Auth는 도구 자격 증명을 비밀 정보로 저장합니다. 저장 위치는 AWS Secrets Manager이며, 이름은 제공자 이름과 다음과 같은 고정 패턴으로 구성됩니다. 예: bedrock-agentcore-identity!default/apikey/{provider_name}. Zenity는 이미 ECR에서 가져온 에이전트 소스 코드를 스크래핑하여 제공자 이름을 알아냈고, 다른 이름들은 무차별 대입으로 알아냈습니다. 기본 5자 접미사는 숫자와 소문자로 클라이언트 측에서 생성되며, 두 제공자 유형에 걸쳐 2 x (10+26)^5 = 120,932,352개의 조합이 나온다고 보고합니다. Secrets Manager를 상대로 유지할 수 있었던 요청 속도에서 Zenity는 전체 열거에 몇 시간이 걸린다고 말합니다 — 이는 STS 자격 증명이 지속되는 것보다 더 오래 걸립니다 — 그래서 이전 자격 증명이 만료될 때 새 자격 증명을 위해 에이전트의 IMDS 엔드포인트를 다시 쿼리하는 루프를 만들었습니다. Zenity는 또한 환경 변수가 메타데이터 user-data 엔드포인트를 통해 읽을 수 있었으며 모든 이름에 CONTAINER_ENV_ 접두사가 붙었고, 여기에는 에이전트가 모델 제공자에 인증하는 데 사용하는 키가 포함되어 있으며, 발견된 각 에이전트를 적절한 프롬프트로 호출하면 그러한 값들을 대규모로 수집할 수 있었다고 덧붙입니다.

확립되었으나, 형식적 문제로 논란이 되고 있다

확립된 사실은 좁고 구체적이다. AgentCore 에이전트는 IMDS에 접근해 자신의 실행 역할에 대한 임시 자격 증명을 받을 수 있었다. AWS는 이를 부인하지 않으며, 성명에서 "문서화되어 있고 예상된 동작"이라고 설명했다. 기본 실행 역할은 단일 에이전트가 아니라 계정과 리전에 범위가 지정된 권한을 갖고 있었다. AWS는 이후 이를 변경했으며, Zenity는 자체 테스트로 권한 축소를 확인했다고 말한다. 이 연구는 관찰된 공격 캠페인이 아니라 시연이다. Sharbat은 Dark Reading에 Zenity가 수정 전에 이 취약점이 실제 환경에서 악용되었다는 증거를 보지 못했다고 말했으며, 그 이유 중 일부는 어떤 조직이 AgentCore에서 에이전트를 실행하는지 식별하기 어렵기 때문이라고 설명했다. 또한 그는 "그렇게 할 방법이 있다고 100% 확신한다"고 덧붙였다.

무엇이 논란이 되고 있는지는 그것 중 어느 것이 취약점이라고 불려야 하는지 여부입니다. Dark Reading과 The Next Web에 제공된 AWS의 성명은 다음과 같습니다. "AWS는 Amazon Bedrock AgentCore에 관해 발표된 연구를 인지하고 있으며, 해당 연구는 예상되고 문서화된 동작을 취약점으로 부정확하게 묘사하고 있습니다. 에이전트는 개발자가 에이전트의 실행 역할과 대상 리소스 모두에 대해 명시적으로 권한을 부여한 경우에만 다른 AWS 계정의 리소스에 액세스할 수 있습니다." Zenity의 자체 게시물에 재현된 AWS 성명은 첫 번째 문장의 요지를 유지합니다 — "설명된 동작은 문서화되었고 예상된 것입니다" — 그리고 고객은 실행 역할에 에이전트가 필요로 하는 권한만 부여해야 한다고 덧붙입니다. 이 의견 차이 아래에는 두 가지가 있습니다. AWS는 경계를 다른 AWS 계정의 리소스에 대한 액세스 측면에서 규정하는 반면, Zenity의 발견은 단일 AWS 계정과 리전 내의 에이전트에 관한 것입니다. 그리고 Zenity가 설명하는 역할은 고객이 정책을 직접 작성한 것이 아니라 플랫폼의 기본값에서 비롯되었습니다.

The Next Web의 자사 기사에 대한 정정은 기록할 가치가 있다. 이는 연구진이 아닌 다른 누군가가 그 주장을 더 엄격하게 다듬었음을 보여주기 때문이다. 이 매체는 처음에 연구진이 한 리전의 모든 AgentCore 에이전트를 장악했다는 제목의 기사를 보도했다가 나중에 정정했다. 정정된 버전은 해당 연구가 단일 AWS 계정과 리전 내의 에이전트들을 대상으로 했다고 밝히고, 앞선 제목이 연구진의 주장을 사실인 것처럼 서술했다는 점을 언급한다.

공개 일정

Zenity는 보고서를 하나가 아니라 두 건 제출했으며, 두 보고서는 서로 다르게 답변되었다. IMDS 접근 보고서는 2025년 12월 25일에 제출되었고, AWS는 2026년 4월 12일에 이를 "정보성"으로 종결하면서, AgentCore는 2026년 2월 14일에 이르러서야 IMDSv2를 사용했고 새로 배포된 에이전트들은 그 방식으로 시작된다고 밝혔다. 이 수정 사항은 이 연구의 세부 내용에서 중요하다. IMDSv2는 요청마다 세션 토큰을 요구하여, 연구진이 자격 증명을 얻기 위해 사용했던 단순한 비인증 페치를 무력화하기 때문이다. 기본 역할과 그 영향 범위에 관한 두 번째 보고서는 2026년 1월 12일에 제출되었다. AWS는 2026년 2월 25일에 Zenity에게 팀이 이 문제를 작업 중이며 역할은 그대로 유지되고 있다고 알렸다. Zenity는 2026년 6월 22일에 역할을 다시 검토했고 권한이 변경되지 않았음을 확인했다. 2026년 9월 29일의 최종 검토에서는 역할이 상당히 축소된 것을 확인했으며, Zenity의 보도자료에 따르면 제거된 항목에는 다른 에이전트 호출, 비공개 대화 읽기, AWS Secrets Manager의 보안 암호 접근이 포함되었고 다른 권한들도 상당히 제한되었다. Zenity의 자체 게시물은 이후 AWS가 AgentCore 배포에서 IMDSv2를 기본값으로 설정했으며 양측이 그 과정 전반에서 협력했다고 언급한다.

무엇이 알려져 있지 않은가?

Zenity는 2월의 IMDSv2 변경과 9월 말의 범위 축소 사이의 기간 동안 얼마나 많은 에이전트나 조직이 기본 역할로 실행되었는지 발표하지 않았으며, 인용된 출처 어디에도 연구자 자체 환경 외부에 고객 데이터가 노출되었다고 명시되어 있지 않습니다. IMDSv2 변경은 Zenity가 보도한 AWS에 따르면 2026년 2월 14일 이후 배포된 에이전트에 적용됩니다; 해당 날짜 이전에 배포된 에이전트에 그것이 무엇을 의미하는지는 여기에서 검토된 출처에 명시되어 있지 않습니다. 아카이브에는 실제 피해가 기록되어 있지 않으며, 출처들은 시연을 설명하고 AWS가 자체 사건을 보고하기보다 취약점 레이블에 이의를 제기함으로써 그러한 해석을 뒷받침합니다.

샤르바트는 Dark Reading에 Zenity가 현재 유사한 메타데이터 접근 문제가 있는지 다른 클라우드 플랫폼들을 조사하고 있으며, 아직 그 플랫폼들의 이름은 밝히지 않고 있다고 말했다. 그가 밝힌 핵심은 메타데이터 서비스만이 아니라 권한에 관한 것이다: "누군가 IMDS에 접근하더라도 영향 범위는 훨씬 작을 것이다."

이 기록이 보관되는 이유

AgentCorruption이 주목할 만한 이유는 메타데이터 엔드포인트가 새로운 아이디어이기 때문이 아니다. Sharbat은 SecTor 청중에게 2019년 Capital One 침해 사고를 언급하며, SSRF가 IMDS에 도달해 자격 증명이 탈취된 사례를 가리켰고, 이를 같은 종류의 최소 권한 실패라고 설명했다. 새로운 것은 가져오기를 수행한 행위자다. AWS 아이덴티티를 생성한 요청은 AI 에이전트가 유용하게 쓰일 수 있도록 부여받은 도구를 통해 평범한 언어로 요청받은 일을 수행하면서 보낸 것이었고, 그 에이전트는 답변을 다시 전달했다. 그것을 계정 전체의 문제로 만든 두 가지 조건은 샌드박스가 차단하지 않은 메타데이터 엔드포인트와, 이를 보유한 에이전트보다 더 넓은 기본 역할이었다.

5부작 기술 시리즈와 데모 영상을 포함한 전체 연구는 Zenity의 2026년 10월 8일 보도자료에서 링크로 확인할 수 있다. 이 기록은 AI 사고 아카이브에 문서화된 에이전트 사고 사례 중 하나이며, 각 항목에는 자체 출처, 심각도, 신뢰도 등급, 이의 제기 플래그가 함께 제공된다. 바로 이 필드들 덕분에 여기에서처럼 프레이밍을 둘러싼 공급업체 측 이견과 피해에 관한 다툼이 있는 조사 결과를 구분할 수 있다.

이것은 하나의 기록으로, 다른 이들이 조사하고 보고했으며 여기서는 그들에게 출처를 밝혀 인용한 것이다. 각기 자체 출처, 심각도, 신뢰도 등급, 이견 표시를 갖춘 다른 문서화된 에이전트 사건들은 여기에 수록되어 있다: AI 사건 아카이브 — 따라서 하나의 프롬프트를 계정 전체의 거점으로 바꾸는 플랫폼 기본값을 다른 곳에서 실제로 일어난 일과 나란히 읽을 수 있다.