Zenity AgentCorruption이 드러낸 AWS AgentCore 계정 전체 하이재킹 경로
Zenity AgentCorruption 연구진은 공개적으로 접근 가능한 Amazon Bedrock AgentCore 에이전트에서 악성 프롬프트 하나만으로 임시 AWS 자격 증명이 노출될 수 있음을 발견했다. 이 자격 증명은 취약한 계정, 리전, 그리고 광범위한 권한이 부여된 기본 역할을 공유하는 모든 AgentCore 런타임으로 이어지는 경로를 열었다고 전해진다. 이 발견은 익숙한 프롬프트 인젝션 문제를 계정 전체에 영향을 미치는 클라우드 보안 실패로 바꿔 놓았다.
이 공격은 파운데이션 모델을 뚫거나, 무관한 AWS 고객 환경으로 탈출하거나, 관리자 비밀번호를 탈취하는 방식에 의존하지 않았다. 대신 에이전트의 HTTP 요청 기능, 메타데이터 자격 증명, 그리고 과도한 Identity and Access Management 권한을 결합했다. Zenity는 이 공격 체인이 비공개 에이전트, 소스 코드, 대화 기록, 저장된 비밀 정보, 장기 메모리까지 도달했다고 밝혔다.
이 조합은 프롬프트 하나라는 표면적 수치보다 더 중요하다. AWS는 AgentCore를 ID, 메모리, 도구, 관측성, 격리된 런타임을 포함해 프로덕션 에이전트를 안전하게 운영하기 위한 관리형 인프라로 홍보했다. AgentCorruption은 연결된 이 서비스들이 권한 경계가 지나치게 넓을 경우 하나의 손상된 에이전트의 영향을 어떻게 증폭시킬 수 있는지 보여줬다.
여기에는 중요한 단서도 있다. Zenity는 2026년 10월 8일 연구를 공개하기 수개월 전에 이 문제를 제보했다. 연구진에 따르면 AWS는 공개 전 기본 실행 역할을 제한했으며, 현재 AWS 문서는 더 강력한 메타데이터 제어를 의무화하고 광범위한 CLI 생성 정책을 프로덕션에 사용하지 말라고 경고한다.
이는 현재의 모든 AgentCore 배포가 여전히 전체 공격 체인에 노출돼 있다는 증거는 아니다. 다만 팀이 관리형 에이전트 인프라를 최소 권한 원칙의 대체재로 여겨서는 안 된다는 증거다. 이제 에이전트 보안은 언어 모델의 동작, 런타임 자격 증명, 클라우드 권한, 메모리 무결성, 수평 이동을 함께 포괄해야 한다.
Zenity AgentCorruption은 어떻게 하나의 프롬프트를 AWS 자격 증명으로 바꿨나
첫 번째 실패는 신뢰할 수 없는 언어 입력과 신뢰된 클라우드 ID 사이의 경계를 넘었다.
Zenity의 AgentCorruption 연구에 따르면, 노출된 AgentCore 에이전트는 로컬 메타데이터 엔드포인트에 요청하도록 지시하는 프롬프트를 받아들였다. 이 요청은 AWS 컴퓨팅 환경이 워크로드 메타데이터와 임시 역할 자격 증명을 제공하기 위해 사용하는 링크-로컬 주소 169.254.169.254를 대상으로 했다.
해당 서비스는 일반적으로 IMDS로 줄여 부르는 Instance Metadata Service다. AgentCore의 Firecracker microVM 환경은 관련 서비스인 MicroVM Metadata Service, 즉 MMDS를 사용해 워크로드 내부에서 실행 역할 자격 증명을 사용할 수 있도록 한다.
이 자격 증명 전달 메커니즘에는 정당한 목적이 있다. 에이전트는 승인된 S3 객체를 읽거나, 다른 AWS 서비스를 호출하거나, 비즈니스 작업을 수행하기 위해 임시 권한이 필요할 수 있다. 임시 자격 증명은 코드나 컨테이너 이미지에 영구 액세스 키를 내장하지 않아도 된다는 장점도 있다.
문제는 신뢰할 수 없는 프롬프트가 도구로 하여금 메타데이터 엔드포인트에 접속하게 만들 수 있을 때 발생한다. Zenity는 HTTP 기능을 갖춘 도구가 microVM 내부에서 요청을 보냈고, 따라서 메타데이터 서비스가 이를 로컬 워크로드 요청으로 처리했다고 밝혔다. 응답은 에이전트 런타임의 임시 액세스 키, 시크릿 키, 세션 토큰을 노출했다.
이는 일반적으로 SSRF라고 부르는 서버 측 요청 위조 패턴이다. 공격자는 직접 접근할 수 없는 대상에 서버 측 구성 요소가 요청을 보내도록 유도한다. 여기서는 에이전트의 도구가 외부 HTTP 요청을 보낼 수 있었기 때문에, 에이전트가 요청을 수행하는 구성 요소가 된 것으로 전해진다.
프롬프트 인젝션은 의도를 제공했고 HTTP 도구는 실행 능력을 제공했다. 이후 메타데이터 서비스가 클라우드 ID를 제공했다. 이 요소들 중 어느 하나만으로는 보고된 수준의 피해 범위를 만들 수 없었다.
안전하지 않은 텍스트만 생성하는 모델은 자격 증명을 훔칠 수 없었을 것이다. 에이전트 도구로부터 보호된 메타데이터 엔드포인트는 이 경로를 차단했을 것이다. 범위가 좁은 실행 역할은 자격 증명이 탈취된 뒤에도 피해를 제한했을 것이다.
AWS는 이제 이 자격 증명 노출 특성을 명시적으로 문서화하고 있다. AWS의 자격 증명 지침은 microVM 내부의 코드나 행위자가 메타데이터 엔드포인트를 호출해 사용 가능한 자격 증명에 접근할 수 있다고 설명한다. 이에 따라 AWS는 고객에게 실행 역할의 권한을 워크로드에 필요한 범위로만 제한하라고 안내한다.
Zenity는 2025년 12월 25일 AWS에 메타데이터 문제를 처음 보고했다. 연구진은 AWS가 2026년 4월 12일 이 보고를 참고용으로 종결했다고 밝혔다. AWS는 2월 14일부터 새로 배포된 에이전트가 IMDSv2를 사용했다고 연구진에게 전했다.
IMDSv2는 클라이언트가 메타데이터를 조회하기 전에 세션 토큰을 요구한다. 이 설계는 공격자가 사전 토큰 요청과 그 헤더를 항상 제어할 수 있는 것은 아니기 때문에 다수의 전통적 SSRF 공격을 차단한다.
자율형 에이전트는 이 가정을 바꾼다. 에이전트가 충분히 유연한 요청을 보낼 수 있다면 토큰을 얻은 뒤 자격 증명을 조회할 수 있다. Zenity는 IMDSv2 요구가 공격 난도를 높였지만 근본적인 신뢰 문제를 제거하지는 못했다고 주장한다.
AWS는 이후 선택적 도입을 넘어섰다. 현재 런타임 지침에 따르면 MMDSv2가 활성화되지 않은 AgentCore 런타임은 2026년 6월 30일부터 거부되고 있다. 이 제어는 기본 보안을 개선하지만, 정상적인 런타임 코드가 여전히 접근할 수 있는 자격 증명에 과도한 권한을 부여하는 일을 정당화하지는 않는다.
핵심 교훈은 아키텍처에 관한 것이다. 에이전트가 자연어 지시를 권한 있는 네트워크 및 ID 작업으로 전환할 수 있을 때 프롬프트 인젝션은 클라우드 침해로 이어진다. 악성 문장만 필터링하는 것은 이 경로의 한 계층만 다룬다.
기본 역할은 하나의 에이전트를 모두의 문제로 만들었다
탈취된 자격 증명이 계정 전체에 영향을 미치는 수단이 된 이유는, 테스트된 실행 역할이 하나의 에이전트에 리전 전체의 다른 에이전트 접근 권한을 부여했기 때문이다.
Zenity는 최초 침해의 배후 권한에 초점을 맞춰 2026년 1월 12일 두 번째 보고서를 제출했다. 연구진은 기본 역할이 이를 맡은 런타임으로 제한되지 않았다고 말했다. 여러 권한이 동일한 AWS 계정과 리전 전반의 AgentCore 리소스에 적용됐다.
첫 번째 확장 단계에는 CloudWatch Logs가 사용됐다. Zenity는 logs:DescribeLogGroups가 손상된 ID가 리전별 로그 그룹 이름을 나열하도록 허용했다고 밝혔다. AgentCore의 명명 규칙은 이 이름 안에 런타임과 메모리 리소스의 식별자를 노출했다.
공격자는 비공개 에이전트의 기존 인벤토리를 보유할 필요가 없었다. 이들은 해당 역할에서 이미 보이는 운영 메타데이터로부터 런타임 식별자를 추론할 수 있었다고 전해진다. 탐색은 탈취된 ID를 로컬 거점에서 인접 리소스의 지도로 전환했다.
이 역할에는 Amazon Elastic Container Registry에 대한 리전 범위 권한도 포함돼 있었다. Zenity는 예측 가능한 리포지토리 명명 방식 덕분에 연구진이 AgentCore 런타임을 컨테이너 이미지와 연결할 수 있었다고 말했다. 이러한 이미지를 가져오면 배포 산출물에 내장된 애플리케이션 코드와 잠재적으로 민감한 구성이 노출됐다.
이 발견은 관리형 런타임에 관한 일반적인 가정에 도전한다. microVM은 실행 중인 한 세션을 다른 세션으로부터 격리할 수 있지만, IAM은 여전히 해당 세션이 무관한 리소스를 가져오도록 승인할 수 있다. 컴퓨팅 격리와 권한 부여 격리는 서로 다른 문제를 해결한다.
다음은 bedrock-agentcore:InvokeAgentRuntime이었다. Zenity의 역할 분석은 테스트된 정책이 리전 내 와일드카드 런타임 리소스를 포괄했음을 보여준다. 따라서 탈취된 자격 증명으로는 외부 사용자가 원래 접근하지 못하도록 설계된 비공개 에이전트를 호출할 수 있었다.
공개 지원 봇은 제한된 도구와 신중하게 필터링된 데이터만 보유할 수 있다. 반면 비공개 청구 에이전트는 금융 파일, 내부 API, 거래 시스템에 접근할 수 있다. 리전 전체 호출 권한은 노출된 진입점을 더 민감한 에이전트와 연결했다.
Zenity는 테스트 청구 에이전트를 상대로 이 경로를 시연했다. 연구진은 해당 도구를 열거하고 billing.json이라는 파일을 식별한 뒤, 에이전트에게 그 내용을 반환하도록 지시했다. 이 시나리오는 두 번째 소프트웨어 취약점이 아니라 정상적인 AgentCore API를 통한 수평 이동을 보여줬다.
대화 메모리는 피해를 다시 확장했다. AgentCore Memory는 메모리 리소스, 액터, 세션별로 단기 이벤트를 저장한다. 장기 전략은 향후 상호작용을 위해 추출한 사실, 선호도, 요약, 학습 내용을 보존할 수 있다.
Zenity는 손상된 역할이 액터와 세션을 나열한 다음 ListEvents를 호출해 대화 내용을 가져올 수 있었다고 밝혔다. 이 권한이 와일드카드 메모리 리소스를 포괄했기 때문에, 연구진은 다른 에이전트와 사용자의 대화에도 접근했다고 전해진다.
노출된 자료에는 개인정보, 소스 코드, 내부 계획, 고객 기록, 또는 문제 해결 중 붙여넣은 자격 증명이 포함될 수 있다. 플랫폼은 대화에 입력된 비밀 정보가 원래 있어야 했는지를 판단할 수 없다. 권한 부여는 무관한 워크로드가 세션을 전혀 읽지 못하도록 해야 한다.
쓰기 권한은 별도의 무결성 위협을 만들었다. Zenity는 이 역할이 메모리 이벤트를 생성하고 삭제할 수 있음을 발견했다. 공격자는 활성 세션에 거짓 맥락을 주입하거나, 도구 결과를 삭제하거나, 에이전트가 일어난 일에 대해 믿는 내용을 조작할 수 있다.
이 위험은 일반적인 데이터 탈취와 다르다. 조작된 에이전트는 공격자가 제공한 맥락에 따라 행동하면서도 계속 신뢰할 수 있는 회사 서비스처럼 보일 수 있다. 적대적 지시가 사용자가 보는 프롬프트가 아니라 저장된 세션 상태 안에 있기 때문에, 사용자는 이를 보지 못할 수 있다.
AWS는 2월 25일 Zenity에 자사 팀이 근본 문제를 해결하고 있다고 밝혔다. 연구진은 6월 22일 다시 점검했고 기본 역할이 변경되지 않았다고 보고했다. 이 타임라인은 광범위한 역할을 수개월 동안 해결되지 않은 공격 체인의 중심에 남겨뒀다.
9월 29일 최종 검토에서 Zenity는 상당한 제한 조치를 확인했다. 연구진은 AWS가 런타임 간 호출, 비공개 대화 접근, Secrets Manager 조회를 가능하게 하던 권한을 제거했다고 밝혔다. 다른 권한도 더 좁게 제한됐다.
이러한 조치는 현재 위험 평가를 크게 바꾼다. 공개된 공격 체인은 연구진이 이전 기본 설정에서 달성한 결과를 기록한 것이지, 동일한 권한이 오늘날에도 여전히 부여돼 있다는 증거는 아니다. 기존 고객 생성 역할, 복사된 정책, 오래된 배포 환경은 여전히 직접 검토할 필요가 있다.
관리형 격리는 과도한 권한의 현실과 맞닥뜨렸다
AgentCorruption은 AgentCore의 격리 약속과 각 격리 런타임을 둘러싼 공유 권한 부여 경로 사이의 충돌을 드러냈다.
AWS는 2025년 10월 AgentCore를 정식 출시하며, 에이전트를 대규모로 안전하게 실행하기 위한 인프라라고 설명했다. 이 플랫폼은 런타임 격리에 ID, 메모리, 게이트웨이, 브라우저 자동화, 코드 실행, 관측성을 결합했다.
각 기능은 실제 배포 문제에 대응한다. 에이전트에는 대화 전반의 상태, 연결된 서비스용 자격 증명, 관리되는 도구 접근, 예측하기 어려운 작업을 위한 추적 기능이 필요하다. 이 모든 구성 요소를 독립적으로 구축하면 비용과 복잡성이 커진다.
하지만 통합은 보안 의존성도 만들어 낸다. 런타임은 계산 측면에서 격리되어 있을 수 있지만, 그 실행 역할은 다른 런타임을 호출할 수 있다. 토큰 볼트는 애플리케이션 코드에서 비밀 정보를 분리해 보관할 수 있지만, 지나치게 광범위한 ID는 그 비밀 정보를 요청할 수 있다.
이것이 Zenity AgentCorruption의 핵심적인 역전이다. 관리형 플랫폼의 연결된 통제 장치는 안전한 프로덕션 사용을 지원하기 위한 것이었다. 그러나 테스트된 기본 설정에서는 바로 그 연결이 서비스 경계를 넘어 침해를 확산시킨 것으로 보고됐다.
AWS의 현재 런타임 보안 관행은 이러한 구분을 더 직접적으로 인정한다. 문서는 고객에게 CLI가 생성한 개발용 정책을 프로덕션에서 사용하지 말라고 경고한다. 또한 와일드카드 리소스 문 대신 구체적인 런타임 ARN을 권장한다.
가이드는 실행 역할이 이를 호출할 수 있는 주체와 같거나 그보다 적은 권한만 가져야 한다고도 말한다. 이 규칙은 공개 에이전트를 평가하는 유용한 기준이 된다. 익명 사용자가 런타임을 호출할 수 있다면, 해당 런타임은 익명 사용자에게 없는 권한을 상속받아서는 안 된다.
공개 접근성이 있다고 해서 에이전트가 자동으로 안전하지 않은 것은 아니다. 다만 모델에 도달하는 모든 지시문의 신뢰 수준이 달라진다. 실행 역할은 수용되는 입력 중 일부가 악의적이거나 오해를 유도하거나 도구를 조작하도록 설계되었다고 가정해야 한다.
인증은 호출자를 식별하는 데 도움이 되지만 프롬프트 인젝션을 없애지는 못한다. 정상적인 고객 계정도 적대적인 지시를 제출할 수 있다. 사용자가 에이전트에게 문서나 웹 페이지를 요약해 달라고 요청한 뒤, 손상된 문서와 웹 페이지가 간접 프롬프트 인젝션을 전달할 수도 있다.
Gateway 통제 장치는 요청이 런타임에 도달하기 전에 검증하여 노출을 줄일 수 있다. Guardrails는 알려진 공격 패턴을 탐지할 수 있으며, interceptors는 ID와 컨텍스트에 따라 작업을 제한할 수 있다. 이러한 통제 장치는 호출자가 Gateway를 우회해 런타임을 직접 호출할 수 없을 때에만 작동한다.
AgentCore의 보안 가이드는 이제 Gateway가 의도된 진입점일 때 런타임 호출을 Gateway의 실행 역할로 제한할 것을 권장한다. 이 접근 방식은 모델의 의사결정 루프 밖으로 권한 부여를 옮긴다. 에이전트는 IAM 거부를 말로 피해 갈 수 없다.
IAM 리소스 범위 지정은 여전히 더 강력한 격리 경계다. 고객 지원 에이전트에 모든 런타임을 호출할 수 있는 와일드카드 권한을 부여해서는 안 된다. 서비스가 그러한 정밀도를 지원하는 경우, 메모리 쓰기 권한에는 구체적인 메모리 리소스, 액터 범위, 비즈니스 필요성을 명시해야 한다.
같은 논리는 컨테이너 리포지토리와 로그에도 적용된다. 운영 메타데이터는 흔히 애플리케이션 데이터보다 덜 민감해 보인다. 그러나 이름, 식별자, 엔드포인트, 리포지토리 패턴은 수평 이동을 위한 탐색 체계가 될 수 있다.
조직에는 신뢰 수준에 따른 분리도 필요하다. 설정 도구가 이 구성을 편리하게 만들어 준다는 이유만으로 공개 에이전트와 내부 에이전트가 실행 역할을 공유해서는 안 된다. 계정 수준 통제가 더 명확한 격리를 제공하는 경우, 민감한 기능은 AWS 계정 또는 리전 전반에 걸쳐 분리할 수 있다.
어떤 프롬프트 필터도 모델이 모든 악의적 변형을 거부한다고 보장할 수 없다. 모델은 유한한 명령 문법을 강제하기보다 의미를 해석한다. 공격자는 요청을 바꿔 표현하거나, 검색된 데이터 안에 지시를 숨기거나, 시스템 컨텍스트와 사용자 컨텍스트 간의 충돌을 악용할 수 있다.
이러한 한계가 에이전트 배포를 비현실적으로 만드는 것은 아니다. 이는 방어자가 신뢰를 어디에 두어야 하는지를 바꾼다. 모델 수준의 방어는 조작 성공 가능성을 줄일 수 있으며, 결정론적인 클라우드 통제 장치는 조작된 모델이 수행할 수 있는 일을 제한한다.
팀은 프롬프트를 신뢰할 수 없는 입력으로, 도구를 권한 있는 인터페이스로 취급해야 한다. 모든 도구 호출에는 인증된 사용자, 요청 리소스, 허용된 작업을 기반으로 한 권한 부여 결정이 필요하다. 모델이 도구를 호출하기로 선택한 사실 자체가 권한 부여가 되어서는 안 된다.
이러한 결정을 문서화하는 조직이라면, 검색 가능한 엔지니어링 지식 베이스가 런타임 소유권, IAM 정책, 위협 모델, 사고 대응 절차를 연결하는 데 도움이 될 수 있다. 여러 팀이 공유 클라우드 계정을 통해 에이전트를 배포할 때 이 기록은 중요해진다.
메모리 오염이 침해를 지속적인 통제로 바꿨다
이 체인에서 가장 중대한 부분은 자격 증명 탈취가 아니라, 신뢰받는 에이전트가 이후에 기억하는 내용을 오염시킬 수 있는 능력이었다.
AgentCore Memory는 단기 및 장기 상태를 지원한다. 단기 메모리는 세션에서 턴별 이벤트를 기록한다. 장기 메모리는 재사용 가능한 정보를 추출하여 에이전트가 선호도, 사실, 요약 또는 이전의 학습 내용을 기억할 수 있게 한다.
이러한 지속성은 사용성을 높인다. 지원 에이전트는 미해결 사례를 기억할 수 있고, 업무 보조 도구는 서식 선호도를 보존할 수 있다. 동시에 이는 향후 의사결정에 영향을 줄 수 있는 지속적인 입력 채널을 만든다.
Zenity의 메모리 오염 연구에 따르면, 탈취된 역할은 CloudWatch 로그를 통해 메모리 식별자를 발견할 수 있었다. 이후 액터, 세션, 구성된 메모리 전략을 나열할 수 있었다.
연구진은 CreateEvent를 사용해 다른 에이전트의 대화에 적대적인 콘텐츠를 추가했다. 메모리 추출은 해당 이벤트를 처리하고 그 내용을 장기 기록으로 변환했다. 이후 세션에서는 해당 기록을 신뢰할 수 있는 컨텍스트로 검색할 수 있었다.
따라서 공격자는 모든 상호작용에서 원래의 프롬프트 인젝션을 반복할 필요가 없었다. 심어진 지시는 손상된 세션 이후에도 살아남아 이후 대화에 영향을 미칠 수 있었다. 눈에 보이는 인터페이스는 여전히 조직의 공식 에이전트로 보였을 것이다.
Zenity는 이를 지속적 명령 및 제어라고 설명한다. 이 표현은 연구진이 테스트 환경을 특성화한 것으로 읽어야 한다. 정확한 행동 결과는 메모리 구성, 검색 로직, 모델 동작, 도구, 권한 부여 통제에 따라 달라진다.
그럼에도 입증된 기본 수단은 심각하다. 거짓 선호도는 에이전트에게 공격자가 통제하는 주소로 데이터를 전송하라고 지시할 수 있다. 조작된 사실은 워크플로를 다른 방향으로 돌릴 수 있고, 오염된 요약은 고객의 이전 승인을 잘못 나타낼 수 있다.
단기 기록 조작은 즉각적인 위험을 더한다. 삽입된 어시스턴트 이벤트는 모델에 이전에 스스로 내린 결정처럼 보일 수 있다. 삭제된 도구 결과는 그렇지 않았다면 안전하지 않은 작업을 막았을 증거를 제거할 수 있다.
전통적인 애플리케이션 보안은 흔히 로그와 기록을 사고 이후의 증거로 취급한다. 에이전트 시스템은 저장된 기록을 향후 의사결정에 적극적으로 다시 공급할 수 있다. 따라서 해당 데이터의 무결성 실패는 조사를 방해할 뿐 아니라 실행 자체를 바꿀 수 있다.
메모리는 복구도 복잡하게 만든다. 탈취된 자격 증명을 교체하면 지속적인 API 접근은 차단되지만, 모든 오염된 기록이 자동으로 제거되지는 않는다. 대응 담당자는 손상된 ID가 어떤 세션, 이벤트, 요약, 추출된 메모리를 건드렸는지 식별해야 한다.
AWS의 현재 메모리 가이드는 입력 검증, 저장 전 Guardrails, 정기적인 프롬프트 인젝션 테스트를 권장한다. 또한 메모리 리소스에 대한 최소 권한 정책을 강조한다.
이러한 통제 장치는 출처 정보와 결합되어야 한다. 장기 기록에는 어떤 사용자, 에이전트, 세션, 추출 프로세스가 이를 생성했는지 보여 줄 수 있는 충분한 메타데이터가 남아 있어야 한다. 보안 팀에는 손상된 ID와 연관된 메모리를 효율적으로 격리할 방법이 필요하다.
고위험 작업은 권한 부여의 증거로 회상된 컨텍스트에 의존해서는 안 된다. 에이전트는 사용자가 특정 은행 계좌를 선호한다는 점을 기억할 수 있지만, 송금에는 여전히 현재의 독립적으로 검증된 승인이 필요하다. 메모리는 워크플로를 안내할 수는 있어도 이를 승인할 수는 없다.
조직은 결과의 심각도에 따라 데이터 유형도 분리해야 한다. 글쓰기 스타일에 관한 선호도는 결제 지시, 접근 권한 부여, 목적지 주소보다 위험이 적다. 민감한 메모리에는 더 엄격한 생성 규칙, 더 짧은 보존 기간, 더 강력한 검토가 필요하다.
모니터링은 읽기뿐 아니라 쓰기도 포괄해야 한다. 비정상적인 CreateEvent 급증, 에이전트 간 메모리 접근, 다수 액터에 영향을 주는 변경은 악용을 알리는 신호일 수 있다. CloudTrail, 애플리케이션 로그, AgentCore 관측성 데이터는 예상 워크로드 동작과 연계된 알림으로 흘러가야 한다.
이 지점에서 이 사고는 AWS를 넘어선다. 지속 메모리와 도구를 결합하는 모든 에이전트 플랫폼은 유사한 무결성 문제에 직면한다. 구현 세부 사항은 다르지만, 신뢰에 관한 질문은 변하지 않는다.
에이전트는 어떤 정보를 기억할 수 있으며, 누가 이를 기록할 수 있고, 이후 어떤 결정이 이에 의존할 수 있는가? AgentCorruption은 불완전한 답변이 일시적인 발판을 지속적인 영향력으로 바꿀 수 있음을 보여 준다.
AgentCore 고객이 지금 확인해야 할 사항
전체 과거 공격 체인은 공개 전에 축소됐지만, 고객이 정의한 권한과 이전 구성은 각 배포 환경에 남은 노출을 결정한다.
첫 번째 점검 대상은 모든 AgentCore 런타임에 연결된 실행 역할이다. 팀은 허용된 작업과 리소스를 나열한 뒤, 런타임의 문서화된 기능과 무관한 권한을 제거해야 한다. 와일드카드는 관행적으로 수용하기보다 구체적인 정당화가 필요하다.
프로덕션 역할은 프로토타입용으로 생성된 정책을 상속받아서는 안 된다. AWS는 이제 CLI가 생성한 권한을 개발 편의 기능으로 표시하고, 고객에게 범위가 좁은 대안을 만들도록 조언한다. 테스트 배포가 성공했다고 해서 그 역할이 프로덕션에 적합하다는 증거는 아니다.
두 번째 점검은 MMDSv2 강제 적용이다. 현재 런타임은 메타데이터 구성에서 requireMMDSV2를 true로 설정해야 한다. 팀은 플랫폼 업데이트가 모든 과거 런타임을 올바르게 변경했다고 가정하지 말고 배포된 구성을 검증해야 한다.
MMDSv2는 여전히 하나의 계층으로 취급해야 한다. 에이전트가 유연한 HTTP 클라이언트, 셸 또는 코드 인터프리터를 정당하게 제어한다면, 단순한 SSRF 방어가 공격자가 구성할 수 없다고 가정했던 요청을 수행할 수 있다. 네트워크 정책은 메타데이터 엔드포인트에 대한 불필요한 접근을 차단해야 한다.
세 번째 점검은 인바운드 도달 가능성이다. 팀은 직접 공개 호출, IAM 기반 호출 또는 JWT 기반 호출을 허용하는 런타임을 식별해야 한다. 공개 에이전트는 가장 신뢰 수준이 낮은 대상에게서 입력을 받으므로 가장 작은 역할이 필요하다.
AgentCore Gateway가 정책 집행을 제공하는 경우, 직접 런타임 호출은 제한해야 한다. 그렇지 않으면 공격자가 Gateway Guardrails를 우회하고 다른 인증된 경로를 통해 런타임 엔드포인트를 호출할 수 있다. 인증과 사용자 식별자는 검증된 주체에서 파생되어야 한다.
네 번째 점검은 수평 이동을 다룬다. 런타임은 관련 없는 에이전트를 호출하거나, 리전 로그 그룹을 나열하거나, 관련 없는 ECR 이미지를 가져오거나, 메모리 리소스를 열거해서는 안 된다. 이러한 권한은 런타임 ARN과 비즈니스 기능에 따라 격리되어야 한다.
다섯 번째 점검은 대화 기밀성이다. 보안 팀은 하나의 런타임 ID가 다른 워크로드에 속한 액터, 세션 또는 이벤트를 나열할 수 있는지 테스트해야 한다. 또한 리소스 정책과 ID 정책이 함께 의도한 거부를 만들어 내는지 검증해야 한다.
여섯 번째 점검은 메모리 무결성이다. 팀은 CreateEvent, DeleteEvent, 장기 메모리 접근 권한을 가진 주체를 목록화해야 한다. 알림은 정상적인 사용자 세션 쓰기와 에이전트 간 또는 대량 변경을 구분해야 한다.
일곱 번째 점검은 저장된 자격 증명에 관한 것이다. AgentCore Identity는 애플리케이션 코드 외부에 서드파티 토큰을 보관할 수 있지만, 여전히 IAM이 이를 검색할 수 있는 주체를 통제한다. 런타임 역할에는 API 키나 Secrets Manager 값에 대한 광범위한 접근 권한이 있어서는 안 된다.
과거 노출 가능성을 검토하는 조사자는 현재의 정책 스냅샷만으로는 충분하지 않습니다. 관련 기간의 CloudTrail 이벤트, 런타임 호출 로그, 메타데이터 관련 활동, ECR 이미지 풀, 메모리 API 호출, Secrets Manager 접근을 함께 살펴봐야 합니다.
임시 자격 증명은 만료되지만, 그 영향은 지속될 수 있습니다. 공격자는 만료 전에 소스 코드를 복사하거나, 가져온 시크릿을 보관하거나, 세션 기록을 수정하거나, 장기 메모리를 심어둘 수 있습니다. 대응 계획에는 자격 증명 교체와 상태 검증이 포함되어야 합니다.
두 가지 불확실성이 여전히 핵심입니다. Zenity의 발견은 연구자가 통제한 배포 환경에서 나온 것이며, 여기에서 인용한 공개 증거는 고객 환경에서 광범위한 악용이 발생했음을 입증하지 않습니다. AWS는 완전한 AgentCorruption 체인을 설명하는 전용 보안 공지를 발표하지 않았습니다.
이러한 부재는 과장된 주장을 막아야 하지만, 연구 자체를 일축하는 근거가 되어서는 안 됩니다. Zenity는 상세한 권한 예시, 악용 경로, 공개 일정을 제시했습니다. AWS의 업데이트된 문서는 런타임 코드가 메타데이터 자격 증명에 접근할 수 있으며 광범위한 개발 정책이 프로덕션 환경에 적합하지 않음을 독립적으로 확인합니다.
첫 번째로 주시할 신호는 AWS가 공식 권고문, 소급 안내 또는 추가 정책 마이그레이션 지침을 발표하는지 여부입니다. 이러한 문서는 영향을 받는 구성과 고객이 이전 역할을 수동으로 수정해야 하는지 여부를 명확히 할 것입니다.
두 번째 신호는 에이전트가 제어하는 도구의 메타데이터 접근이 더욱 제한되는지입니다. 런타임 워크로드가 자격 증명 엔드포인트에 도달하지 못하게 하는 제어는 모델 동작에 대한 의존도를 낮출 수 있습니다. 세분화된 이그레스 정책은 다른 SSRF 경로도 억제할 수 있습니다.
세 번째 신호는 고객이 확인할 수 있는 메모리 보호 기능입니다. 더 나은 출처 추적, 범위가 제한된 쓰기 권한, 무결성 경고, 대량 격리 도구는 메모리 오염을 더 쉽게 탐지하고 되돌릴 수 있게 합니다. 장기 메모리가 비즈니스 핵심 워크플로에 도입되는 한, 이러한 기능은 중요합니다.
Zenity AgentCorruption은 결국 엔터프라이즈 에이전트의 기반이 되는 더 광범위한 주장을 시험합니다. 관리형 인프라는 운영 복잡성을 낮출 수 있지만, 아이덴티티, 메모리, 도구 접근을 광범위하게 신뢰되는 하나의 역할로 안전하게 통합할 수는 없습니다.
개발자는 이제 배포된 모든 에이전트에 대해 구체적인 질문을 던져야 합니다. 모델이 받을 수 있는 최악의 지시를 따랐을 때 어떤 일이 일어나는가? 그에 따른 도구 호출, 자격 증명, 권한, 도달 가능한 에이전트, 쓰기 가능한 메모리를 추적해야 합니다.
답이 해당 에이전트의 좁은 작업 범위를 넘어선다면, 그 범위를 현재 진행 중인 보안 결함으로 취급해야 합니다. 역할을 검토하고, 공개 런타임을 격리하고, 메모리 경계를 테스트하며, 현재 AWS 기본값을 직접 확인하십시오. 가장 안전한 에이전트는 조작을 언제나 거부하는 에이전트가 아닙니다. 조작된 응답이 계정 전체의 사고로 이어지지 않도록 클라우드 권한이 제한된 에이전트입니다.
