AgentCorruption: AgentCore 메타데이터와 IAM 위험

Zenity의 2026년 10월 연구는 모델의 영향을 받은 도구가 AgentCore 런타임 메타데이터에 접근할 수 있었고, 과거 기본 역할의 권한이 접근 범위를 넓혔다고 보고합니다. AWS는 런타임 자체 역할 자격 증명에 대한 접근을 예상된 동작으로 설명하며 최소 권한을 권고합니다. Zenity 연구에는 CVE 식별자가 인용되지 않았고 고객 침해도 입증되지 않았습니다.^{[1], [4]}

💡 알기 쉬운 설명 (ELI5)

작업장 안의 에이전트가 맡은 일에 필요한 출입증을 받는다고 생각해 보세요. Zenity에 따르면 모델이 유도한 도구가 내부 창구에 그 출입증을 요청할 수 있었고, 과거 출입증 권한은 에이전트에게 필요 이상으로 많은 방을 열어 주었습니다. AWS는 작업장 안에서 에이전트가 자신의 역할 자격 증명을 받는 것이 예상된 동작이라고 설명합니다. 실질적인 방어는 출입증이 열 수 있는 문을 제한하고 내부 요청을 보낼 수 있는 도구를 통제하는 것입니다.^{[1], [4]}

핵심 개념 및 용어

AgentCorruption: Amazon Bedrock AgentCore를 대상으로 한 통제된 연구 체인에 Zenity Labs가 붙인 이름입니다. Zenity는 CVE 식별자를 인용하지 않았고 연구에서 고객 침해도 입증하지 않았습니다.^{[1], [7]}
MMDS 및 실행 역할 자격 증명: AWS 문서에 따르면 AgentCore microVM 내부의 코드는 MMDS를 통해 해당 런타임 실행 역할의 임시 자격 증명을 얻을 수 있습니다. 서비스는 이를 예상된 동작으로 설명하며, 자격 증명이 허용하는 작업은 역할 권한에 따라 결정됩니다.^{[4], [5]}
권한 영향 범위: 실행 역할은 에이전트 코드가 접근할 수 있는 AWS 작업과 리소스를 정합니다. Zenity는 과거 동일 계정과 리전에서 기본 권한이 광범위했다고 보고합니다. AWS는 최소 권한을 권고하며, 권한은 각 작업에 적용되는 자격 증명 및 리소스 정책에 따라 달라집니다. AWS는 계정 간 접근에 역할과 대상 리소스 양쪽의 명시적 권한 부여가 필요하다고 구체적으로 설명합니다.^{[3], [1], [6]}
CWE-918 — 편집상 분류: 이 페이지는 에이전트 도구가 내부 메타데이터 서비스로 보내는 서버 측 요청을 설명하기 위한 편집상 분류로 CWE-918을 사용합니다. AWS가 이 CWE를 지정한 것은 아니며 메타데이터 접근은 문서화된 동작입니다.^{[8], [4], [1]}

프레임워크 매핑

MITRE CWE에 대한 FlawOpen의 개념적 매핑입니다. 공급업체나 CVE 레코드가 이 연구 시연에 해당 약점 ID를 지정한 것은 아닙니다. CWE-918

단계별 공격 실행 흐름

단계 1

공개 에이전트에 외부 요청 도구가 있음

Zenity는 외부에서 접근할 수 있고 외부 요청을 보내는 도구가 있는 AgentCore 에이전트를 테스트했습니다. 이 시나리오에는 접근 가능한 에이전트와 모델이 영향을 줄 수 있는 도구 경로가 필요하며 모든 배포에 해당하지는 않습니다.^{[2], [1]}

단계 2

모델의 영향이 메타데이터에 도달

Zenity는 테스트 에이전트가 로컬 메타데이터 서비스를 요청하도록 유도될 수 있었다고 보고합니다. AWS는 microVM 내부 코드가 MMDS 자격 증명에 접근할 수 있다고 문서화합니다. 보안 쟁점은 런타임 자체 자격 증명의 존재가 아니라 모델에서 도구로 이어지는 신뢰 경로와 그 자격 증명의 권한입니다.^{[2], [1], [4]}

단계 3

응답은 에이전트 역할을 나타냄

AWS 문서에 따르면 MMDS는 구성된 실행 역할의 임시 자격 증명을 제공합니다. 이 자격 증명이 모든 리소스 접근을 자동으로 허용하지는 않으며 IAM 및 적용되는 리소스 정책이 허용 작업을 정합니다. 계정 간 접근은 역할과 대상 리소스 양쪽의 명시적 권한을 필요로 한다고 AWS는 설명합니다.^{[4], [6], [1]}

단계 4

과거 권한이 영향 범위를 넓힘

Zenity에 따르면 당시 기본 역할은 동일 계정과 리전의 다른 AgentCore 리소스에 대한 작업을 허용했으며 런타임 호출, 세션/이벤트 접근, 메모리 작업, 비밀 정보 접근이 포함됐습니다. Zenity는 AWS가 2026년 9월 29일까지 기본 역할을 크게 제한했다고 보고합니다. 고객 관리 역할이 자동으로 변경됐다는 뜻은 아닙니다.^{[3], [1], [6]}

단계 5

현재 통제는 서로 다른 경계를 보호함

Zenity는 신규 에이전트가 2026년 2월 14일부터 MMDSv2를 사용했다고 말합니다. AWS 현행 문서는 2026년 6월 30일부터 런타임 호출을 위해 MMDSv2를 활성화하도록 요구합니다. AWS는 microVM 내부 코드가 역할 자격 증명에 접근할 수 있다고 계속 문서화하므로 MMDSv2는 최소 권한 IAM이나 모델 영향 도구 통제를 대체하지 않습니다. 이는 출처에 근거한 방어적 추론입니다.^{[5], [4], [1]}

근거와 현재 범위

경계	근거	방어 조치
메타데이터 접근	Zenity는 테스트에서의 접근을 보고했고 AWS는 microVM 내부 코드에 MMDS 자격 증명이 제공된다고 문서화합니다.	에이전트 코드와 모델의 영향을 받는 도구를 실행 역할 자격 증명을 사용하는 주체로 취급하세요.
역할 권한	Zenity는 과거 기본 권한이 광범위했다고 보고합니다. AWS는 계정 간 접근에 역할과 대상 리소스의 명시적 권한이 필요하다고 설명하며, 그 밖의 작업에는 해당 IAM 및 리소스 정책이 적용됩니다.	배포된 역할과 리소스 정책을 확인하고 각 작업에 적용되는 정책을 검증하세요. 프롬프트나 서비스 기본값만으로 권한 범위를 추정하지 마세요.
기본 역할 변경	Zenity는 2026년 9월 29일 AWS가 기본 역할을 제한한 것을 관찰했다고 말합니다. 연구는 고객 관리 역할이 자동 변경됐다고 하지 않으며 CVE 식별자나 고객 침해를 입증하지 않습니다.	계정과 리전별 유효 역할을 확인하고 고객 관리 역할도 바뀌었다고 가정하지 마세요.
MMDSv2	Zenity는 신규 에이전트의 MMDSv2 사용 시점을 2026년 2월 14일로 기록합니다. AWS 현행 문서는 2026년 6월 30일부터 런타임 호출에 활성화를 요구합니다. AWS는 VM 내부 자격 증명 접근을 계속 문서화합니다.	MMDSv2를 활성화하고 역할의 작업, 리소스, 호출 주체를 별도로 제한하세요.

근본 원인 분석 (Root Cause)

두 경계를 따로 평가해야 합니다. 모델의 영향을 받는 도구는 런타임 내부에서 요청을 보낼 수 있고 실행 역할은 그 요청의 권한을 결정합니다. AWS는 런타임 자체 자격 증명 접근을 예상된 동작으로 보며 Zenity가 보고한 다른 에이전트 영향은 과거 역할 권한 범위에 달려 있었습니다. MMDSv2 활성화는 IAM 권한을 줄이지 않으며 역할 권한 축소도 모델이 유도하는 내부 요청을 막지 않습니다. 도구의 외부 통신과 IAM 권한 부여를 각각 검토하세요. 외부 통신 제한만으로 microVM 내부 코드가 MMDS에 접근할 수 없다고 입증되지는 않습니다.^{[1], [3], [4], [5]}

소스 코드 비교: 취약한 구현 vs 보안 패치

설명용 IAM 정책 예시이며 AWS의 과거 정책이나 이후 기본 역할 변경을 나타내지 않습니다. AWS는 런타임 권한을 구체적인 리소스 ARN으로 제한하고 와일드카드를 피하도록 권고합니다. 첫 문은 광범위한 리소스 패턴을 보여 주며 두 번째 문은 필요한 경우 호출 권한을 승인된 런타임 하나로 제한합니다. 필요하지 않으면 해당 권한을 제거하세요. 실제 배포에 맞는 작업/리소스 지원과 연관 리소스 정책을 검증하세요. 완전한 배포 가능 정책은 아닙니다.^{[3], [6], [5]}

취약한 구현

{
  "Effect": "Allow",
  "Action": "bedrock-agentcore:InvokeAgentRuntime",
  "Resource": "arn:aws:bedrock-agentcore:REGION:ACCOUNT:runtime/*"
}

보안 강화 패치

{
  "Effect": "Allow",
  "Action": "bedrock-agentcore:InvokeAgentRuntime",
  "Resource": "arn:aws:bedrock-agentcore:REGION:ACCOUNT:runtime/APPROVED_RUNTIME_ID"
}

엔지니어링 및 시스템 보안 강화 체크리스트

✓모든 계정과 리전의 런타임 실행 역할을 목록화하고 유효 권한을 AWS 현행 정책 및 고객 관리 정책과 비교하세요.^{[6], [5]}
✓각 권한에 문서화된 필요성이 없다면 런타임 간 호출, 대화 접근, 비밀 정보 조회, 메모리 쓰기, 이미지 접근을 제거하세요.^{[3], [6]}
✓한 런타임이 다른 런타임을 호출해야 한다면 자격 증명 기반 정책과 리소스 기반 정책을 승인된 런타임과 엔드포인트로 제한하고 관련 없는 런타임이 거부되는지 테스트하세요.^[6]
✓AWS 요구에 따라 MMDSv2를 활성화하되 microVM 내부 코드의 역할 자격 증명 접근을 별도의 권한 경계로 취급하세요.^{[5], [4], [1]}
✓모델 영향 도구가 접속할 수 있는 대상을 업무에 필요한 범위로 줄이세요. 이는 외부 요청 위험을 낮추는 조치이지 VM 내부 MMDS 접근 불가를 입증하는 조치는 아닙니다.^[5]
✓공개 에이전트에는 이를 호출할 수 있는 주체보다 높은 권한이 없는 역할을 부여하세요. IAM Access Analyzer와 권한 거부 테스트로 유효 권한을 검증하세요.^{[5], [6]}

출처

← AI Security Directory →