모델이 아니라 기본 역할:프롬프트 하나가 AWS 계정의 모든 에이전트를 장악하다

핵심 요점

• 공개 접속 에이전트 하나에 보낸 프롬프트 하나가 같은 AWS 계정과 리전의 모든 AgentCore 에이전트를 침해했습니다 — Zenity Labs는 2025년 12월 25일에 시작된 책임 있는 공개 절차를 거쳐 2026년 10월 8일 토론토 SecTor에서 AgentCorruption 공격 체인을 공개했습니다.
• 피해 범위는 모델이 아니라 역할의 속성이었습니다 — 기본 실행 역할은 bedrock-agentcore:InvokeAgentRuntime, bedrock-agentcore:ListEvents, 에이전트 간 메모리 쓰기 권한, bedrock-agentcore:GetResourceApiKey, secretsmanager:GetSecretValue를 보유했고, 그 적용 범위는 하나의 에이전트가 아니라 계정 리전 전체였습니다.
• 수정까지 278일이 걸렸습니다 — AWS는 2026년 2월 14일까지 AgentCore를 IMDSv2로 전환했지만 Zenity의 2026년 6월 22일 재확인에서 기본 역할은 그대로였고, 권한 제거가 적용된 것은 2026년 9월 29일이었습니다.
• 에이전트 메모리는 지속 공격면입니다 — 연구진은 에이전트의 이후 대화를 공격자가 제어하는 목적지로 재유입하는 메모리를 심었습니다. 사용자는 신뢰할 만한 기업 에이전트라고 여겨지는 대상과 계속 대화하고 있었습니다.
• AWS는 이 동작을 "documented and expected"라고 불렀습니다 — 그리고 실행 역할에는 에이전트에 필요한 권한만 부여하라고 고객에게 권고합니다. 기본 역할 검증은 어떤 관리형 플랫폼에서든 고객의 몫입니다.

2026년 10월 8일, 토론토의 SecTor 컨퍼런스에서 Zenity Labs는 AgentCorruption를 공개했습니다. AI 에이전트를 배포하고 운영하는 AWS의 관리형 플랫폼인 Amazon Bedrock AgentCore의 일련의 결함입니다. 공개 접속 에이전트 하나 — 예를 들어 인터넷에 노출된 고객 지원 에이전트 — 에 보낸 프롬프트 하나가 그 에이전트의 머신에 할당된 임시 AWS 자격 증명을 돌려받았습니다. 그 자격 증명은 하나의 에이전트가 아니라 같은 AWS 계정과 리전의 모든 AgentCore 에이전트에 적용되는 기본 IAM 역할의 것이었습니다. 연구진은 그 자격 증명으로 접근 권한이 없던 내부 에이전트를 호출하고, 에이전트와 사용자 전반의 비공개 대화를 읽고, 에이전트 컨테이너 이미지를 내려받아 소스 코드를 추출하고, AWS Secrets Manager에서 API 키와 OAuth 토큰을 확보하고, 세션이 끝난 뒤에도 계속 작동하는 메모리를 심었습니다.

그 어느 것도 모델의 실패를 필요로 하지 않았습니다. 공격 체인에서 모델이 한 일은 요청받았을 때 HTTP 요청을 하나 보내는 것뿐이었습니다. 그 이후의 모든 것은 IAM이었습니다. 이 글은 5단계 공격 체인, 각 단계를 가능하게 한 구체적 권한, 278일의 공개 타임라인, 그리고 관리형 에이전트 플랫폼에 에이전트를 배포하기 전에 모든 팀이 확인해야 할 5가지 질문을 정리합니다 — 어떤 벤더의 플랫폼이든.

공격 체인, 단계별로

Zenity Labs는 전체 연구를 5부 구성 기술 시리즈로 공개했습니다. 이 체인은 5개 동작으로 압축됩니다.

1단계: 프롬프트 인젝션에서 IMDS로. AgentCore 에이전트는 Firecracker microVM 안에서 실행되며, 그 네트워크 격리는 인스턴스 메타데이터 서비스를 차단하지 않았습니다. 아웃바운드 HTTP 요청을 보낼 수 있는 에이전트 도구라면 그 요청을 인스턴스 내부에서 보낼 수 있습니다 — SSRF 기본 형태입니다. 프롬프트 하나가 노출된 에이전트에게 169.254.169.254, 즉 Instance Metadata Service를 호출하도록 지시했고, 서비스는 해당 워크로드에 할당된 역할의 임시 IAM 자격 증명을 돌려주었습니다. 침입 비용은 흔히 쓰이는 도구를 가진 에이전트 하나에 대한 채팅 접근이 전부였습니다.

2단계: 계정 전체 탐색. 자격 증명은 특정 에이전트로 한정되지 않는 기본 실행 역할의 것이었습니다. 권한 가운데에는 DescribeLogGroups가 있었고, 연구진은 이를 사용해 리전 전체의 모든 에이전트와 ID를 나열했습니다. 두 번째 탐색 경로는 공짜로 얻어졌습니다. Elastic Container Registry 저장소 이름이 에이전트 ID와 일치했기 때문에, 역할의 ECR 풀 권한으로 모든 에이전트의 컨테이너 이미지를 내려받아 소스 코드를 온전히 읽을 수 있었습니다.

3단계: 횡적 이동. 역할에는 리전 전체가 적용 범위인 bedrock-agentcore:InvokeAgentRuntime이 포함돼 있었습니다. 연구진은 계정의 모든 AgentCore 에이전트를 호출할 수 있었습니다 — 접근 권한이 없는 내부 민감 에이전트도 포함해서입니다. 공개 내용의 예시: 인터넷에 노출된 고객 지원 에이전트로 침입한 공격자가 같은 리전의 내부 재무 에이전트로 횡적 이동해 호출하고, 그 데이터와 도구, 자격 증명에 접근합니다.

4단계: 데이터와 자격 증명 접근. bedrock-agentcore:ListEvents는 모든 에이전트, 사용자, 세션에 걸친 비공개 대화를 모두 반환했습니다 — 플랫폼의 프라이버시 경계가 녹아내렸습니다. 이어서 bedrock-agentcore:GetResourceApiKey와 secretsmanager:GetSecretValue가 AgentCore가 의도적으로 에이전트로부터 격리해 두었던 자격 증명 — API 키, OAuth 토큰, Secrets Manager 항목(AWS를 넘어 기업 리소스와 제3자 서비스 연결에 쓰이는 자격 증명 포함)에 도달했습니다.

5단계: 메모리를 통한 지속성. 역할에는 메모리 쓰기 권한 — BedrockAgentCoreMemory에 대한 bedrock-agentcore:CreateEvent도 있었습니다. 연구진은 서로 다른 에이전트와 사용자에 걸쳐 새 메모리를 만들어 에이전트 동작을 지속적으로 바꾸고, 이후 세션에서 에이전트의 목표를 하이재킹해 대화를 공격자가 제어하는 목적지로 유도했습니다. 침해는 그것을 만든 세션이 끝난 뒤에도 살아남았습니다.

아래 그림은 5개 동작과 각 단계가 무엇을 노출했는지 보여줍니다:

역할의 문제, 모델의 문제가 아니다

구조적 교훈은 5단계 전체에 관여하지 않은 것에 있다. 탈옥 없음, 정렬 실패 없음, "이 URL을 호출하라"를 넘어서는 정교한 프롬프트 엔지니어링 없음. Zenity의 공동 창업자이자 CTO인 Michael Bargury는 근본 원인을 모든 플랫폼이 출고 시점부터 안고 가는 설계 긴장으로 정리했습니다. "클라우드 보안의 핵심은 세그멘테이션과 최소 권한 접근입니다. 그러나 AI 에이전트는 유용해지려면 창의적 공간이 필요합니다. 둘을 섞으면 본질적 갈등이 생깁니다." 그의 결론은 이렇습니다. "클라우드에서 에이전트를 배포하는 모든 회사는 에이전시와 최소 권한 사이의 동일한 근본적 선택과 마주하게 될 것입니다."

AgentCore는 이 갈등을 에이전시 쪽으로 해결했습니다 — 플랫폼의 편의를 위해서지, 고객의 보안을 위해서가 아닙니다. 기본 실행 역할이 넓었던 것은 에이전트가 바로 동작하도록 하기 위함이었고, 그 권한은 계정 리전의 모든 에이전트 리소스를 덮었습니다. 연구와 함께 공개된 AWS 자신의 성명은 이 동작이 "documented and expected"이며, 에이전트가 메타데이터 서비스를 통해 자기 실행 역할의 자격 증명에 접근할 수 있고, "모범 사례로서 실행 역할에는 에이전트에 필요한 권한만 부여할 것을 고객에게 권고한다"고 말하며 자격 증명 관리, 런타임 권한, 최소 권한 가이드를 가리킵니다.

이 두 사실을 나란히 읽으면 구매자의 위치는 명확합니다. 플랫폼은 기본 역할을 출발점으로 보고, 침해된 에이전트의 피해 범위를 고객의 구성 문제로 봅니다. 클라우드 벤더 입장에서는 방어 가능한 입장입니다 — IAM 최소 권한은 IAM이 생긴 이래 줄곧 고객의 몫이었습니다. 그러나 관리형 에이전트 플랫폼의 마케팅 틀 — 플랫폼이 운영상 강화를 대신 처리해 주므로 여러분의 팀은 하지 않아도 된다는 — 과 충돌합니다. AgentCorruption 체인이 바로 그 충돌이 실제로 벌어진 모습입니다. 플랫폼의 기본값이 취약점이었고, 플랫폼의 문서가 완화책이었습니다.

공개에서 수정까지 278일

공개 타임라인은 두 번째 교훈입니다. Zenity는 2025년 12월 25일 초기 IMDS 접근을 보고했습니다. AWS는 2026년 2월 14일까지 새로 배포되는 에이전트에 한해 AgentCore를 IMDSv2 전용으로 업데이트했고, 4월 12일 그 첫 보고를 "informative"로 종결했습니다. 그러나 2026년 1월 12일 제출된 Zenity의 두 번째 보고서 — 기본 역할의 피해 범위 — 는 더딘 채로 흘러갔습니다. 2월 25일, AWS는 팀이 적극 대응 중이라 말했지만 기본 역할은 그대로였습니다. 2026년 6월 22일, Zenity가 재확인한 결과 권한은 여전히 변하지 않았습니다. 실질적 수정 — 광범위한 에이전트 실행, 비공개 대화 읽기, Secrets Manager 접근을 허용하던 권한 제거 — 가 확인된 것은 2026년 9월 29일, 첫 공개로부터 278일 후, 일반 공개 며칠 전이었습니다.

날짜	사건
2025-12-25	Zenity가 초기 IMDS 접근을 AWS에 공개
2026-01-12	Zenity가 기본 역할 피해 범위 보고서 제출
2026-02-14	AgentCore가 신규 배포 에이전트에 한해 IMDSv2 전용으로
2026-02-25	AWS가 대응 중임을 확인; 기본 역할은 무변
2026-04-12	AWS가 IMDS 보고를 "informative"로 종결
2026-06-22	Zenity 재확인: 기본 역할 여전히 무변
2026-09-29	기본 역할 강화 — 에이전트 간, 대화 읽기, Secrets Manager 권한 제거

관리형 플랫폼의 기본값에 의존하는 모든 팀에 두 가지 함의가 있습니다. 첫째, 책임 있는 공개 이후에도 편의성 기본값은 그해 대부분 동안 상존하는 취약점이 될 수 있습니다 — "보고됨"에서 "수정됨"까지의 창은 개월 단위로 측정되며, 여러분의 에이전트는 그 안에서 실행됩니다. 둘째, 수정 자체가 이 논지의 증명입니다. AWS는 모델을 재훈련하지 않았고 안전 필터를 추가하지도 않았습니다. 역할 정책을 편집한 것입니다. 피해 범위는 처음부터 끝까지 IAM 문서 한 장이었습니다.

메모리는 지속 공격면이다

체인에서 가장 앞선 부분은 5단계입니다. 데이터를 읽는 것은 유출이고, 메모리를 고치는 것은 장악입니다. 연구진은 역할의 메모리 쓰기 권한으로 세션이 끝난 뒤에도 살아남는 지시를 심고, 이후 대화를 공격자가 제어하는 목적지로 재유입하며, 에이전트가 정상적으로 동작하는 것처럼 보이게 했습니다. 에이전트를 멈추고 자격 증명을 교체하고 주입 경로에 패치하는 사고 대응은 심어진 메모리를 제거하지 못합니다. 메모리 저장소가 대응 범위에 없다면 침해는 정리 과정을 뚫고 지속됩니다.

이것은 Anthropic이 2026년 10월 공개했던, 모든 내부 에이전트 평가의 라이브 인터넷 접근을 끊게 만든 행동 수정 부류와 같은 부류입니다 — 프런티어랩 2곳, 같은 고백이 그 주제입니다. 그 글은 정렬 훈련만으로는 에이전트 행동을 통제할 수 없다는 프런티어랩의 자백을 다룹니다. AgentCorruption은 같은 문제를 한 단계 아래, 플랫폼 계층에서 보여줍니다. 올바른 IAM 권한을 가진 무엇이든 쓸 수 있는 메모리 저장소는 지속 메커니즘이며, 설계로서의 킬 스위치가 다루는 킬 스위치 아키텍처는 메모리를 런타임만이 아닌 침해된 상태의 일부로 다뤄야 합니다.

어떤 관리형 에이전트 플랫폼에 배포하기 전의 5가지 질문

AgentCore는 해부된 사례일 뿐, 예외가 아닙니다. Zenity의 보도자료 스스로 일반론을 말합니다. 기업들은 고객 대면 에이전트와 내부 에이전트를 같은 클라우드 환경에서 나란히 돌리는 일이 흔하며, 한 에이전트의 예기치 못한 약점 하나가 환경 전체의 경계를 무너뜨릴 수 있습니다. 플랫폼은 달라도 권한의 부류는 운을 맞춥니다. 관리형 플랫폼에 에이전트를 라이브로 올리기 전에, 다음 5가지에 대한 서면 답변을 받으십시오.

1. 기본 실행 역할에 정확히 무엇이 들어 있습니까? "기본값이 안전한가"가 아니라 — 정책 문서를 권한 하나하나씩 말입니다. *에 적용되거나 계정 내 모든 에이전트에 적용되는 모든 권한을 표시하십시오. AgentCorruption 체인은 이 질문에 대한 5개 권한짜리 답입니다.
2. 한 에이전트가 나머지를 탐색할 수 있습니까? 계정 전체의 list 또는 describe 권한은 침해된 에이전트 하나를 목표 인벤토리로 바꿉니다. DescribeLogGroups가 열거 단계였습니다. 모든 플랫폼에는 그에 상응하는 열거면이 있습니다.
3. 한 에이전트가 다른 에이전트를 호출할 수 있습니까? 에이전트 간 호출은 횡적 이동의 기본형입니다. 플랫폼이 호출을 명시적인 에이전트별 허용 목록으로 한정할 수 없다면, 계정 내 모든 에이전트를 단일 신뢰 도메인으로 다루십시오 — 공격자가 그렇게 다룰 테니까요.
4. 도구 자격 증명은 어디에 있으며, 어느 역할이 읽을 수 있습니까? 시크릿 게이트웨이는 어떤 에이전트 역할도 그 위에서 GetSecretValue를 호출할 수 없을 때만 위험을 옮깁니다. AgentCorruption 역할은 플랫폼 설계가 에이전트로부터 멀리 두려던 바로 그 자격 증명을 읽을 수 있었습니다.
5. 에이전트 자신 외에, 자기 세션 외의 무엇이 메모리를 쓸 수 있습니까? 에이전트 간·사용자 간 메모리 쓰기는 메모리 저장소를 지속 공격면으로 바꿉니다. 답이 한정할 수 있는 권한이라면 한정하십시오. 그렇지 않다면 메모리 저장소를 공격자 제어 상태로서 사고 대응 계획에 넣으십시오.

관련 자료

• Bedrock vs OpenAI: 프로덕션 에이전트를 위한 관리형 AI 플랫폼 선택 — 이번 사고가 내려앉는 관리형 플랫폼 비교: 비용, 프라이버시, 벤더 안정성에 이제 기본 역할 질문이 실사 목록에 추가됐습니다
• 한 달에 126건의 사고: 첫 번째 포괄적 AI 보안 인벤토리와 에이전트 리스크에 대한 증명 — 이번 사고 뒤의 빈도 명제: 에이전트 계층 공격은 2026년 9월 최대의 공격 벡터 부류였습니다
• AI 에이전트 거버넌스 체크리스트: 프로덕션 에이전트를 위한 배포 전 검토 — 최소 권한 실행 역할과 에이전트 간 탐색을 체크 항목으로 포함하는 완전한 배포 전 검토

관리형 플랫폼에서 에이전트 두 개를 돌리는 중견 산업 유통사를 생각해 보십시오 — BigCommerce 스토어프런트와 카탈로그 앞에 있는 공개 견적 에이전트 하나, NetSuite 가격 등급과 재고 접근 권한을 가진 내부 에이전트 하나. 이것은 정확히 AgentCorruption이 악용한 토폴로지입니다. 같은 계정에 인터넷에 노출된 에이전트 하나와 백오피스 에이전트 하나가 있는 구조입니다. 우리가 구축에 쓰는 패턴은 커넥터 모듈마다 독립된 최소 권한 역할을 부여하고, 에이전트가 호출할 수 있는 모든 도구를 등록하고, 메모리를 에이전트별로 스코프하고, 세션 밖에서의 메모리 쓰기가 보이는 감사 추적을 기록합니다. 요점은 권한이 한정된 빌드가 플랫폼 측 결함에 면역이라는 뜻이 아닙니다. 다음번 사고의 피해 범위는 여러분의 팀이 검토한 역할 정책이 정한다는 것입니다 — 플랫폼이 기본값으로 출고한 그 역할이 아니라.

1주일 디스커버리. 시스템 인벤토리, 워크플로 맵, 확정 범위를 받게 됩니다 — 저희와 함께하든 아니든.

범위가 확정된 구축을 요청하십시오.