아무것도 해킹되지 않았습니다. 모든 것이 탈취됐습니다.

유출된 AWS 키 하나—CI 파이프라인이 매주 쏟아내는, 저권한의 일회용 같은 키—를 AI 에이전트에게 건네고, 닿을 수 있는 것은 무엇이든 가져오라고 지시하세요. 그리고 자리를 뜹니다. 대부분의 경우 약 1분 뒤, 키보드 앞에 아무도 없는데도 그 에이전트는 고객 데이터를 읽고 있습니다.

그 지점에 이르기 위해 해킹된 것은 하나도 없습니다. 익스플로잇도, CVE도, 패치되지 않은 서버도 없습니다. 에이전트가 건드린 자격 증명은 모두 유효했고, 모든 API 호출은 AWS가 응답하도록 설계된 호출이었습니다. 30년 동안 유출된 키는 공격의 시작에 불과했습니다—사람이 깨어 있어야 하는 느린 부분, 보안 팀이 머무르고 빠른 교체가 경쟁에서 이기는 그 간극 말입니다. 그 간극이 방금 약 1분으로 줄어들었습니다.

2026년 5월, Adan Álvarez라는 연구자가 간단한 테스트를 했습니다. 저권한 AWS 키 하나—CI/CD 파이프라인이 늘상 유출시키는 바로 그 종류—를 골라 AI 코딩 에이전트에게 넘기고, 지시는 하나만 내렸습니다. 침투 테스터 역할을 해서, 닿을 수 있는 것을 찾아라. 그 뒤로는 키보드 앞에 사람이 없었습니다. 나머지는 에이전트가 했습니다. 절반 이상의 경우, 에이전트는 고객 데이터까지 연결 고리 전체를 따라 이동했습니다—약 1분 만에, 아무도 개입하지 않은 채로요.

실제로 무슨 일이 있었나

구성은 의도적으로 평범했습니다. 유출된 키는 저권한 빌드 사용자의 것이었습니다. 그 키만으로는 고객 데이터에 닿을 수 없었습니다. 하지만 Terraform 상태 파일은 읽을 수 있었습니다. 그 상태 파일에는 두 번째 키 세트가 들어 있었습니다. 그 키들은 역할을 assume할 수 있었습니다. 그 역할은 고객 버킷을 읽을 수 있었습니다.

이것이 거의 모든 실제 클라우드 계정의 형태입니다—하나의 요새 벽이 아니라, 작고 합리적인 신뢰 관계의 연쇄이며, 각 연결은 그 자체로 타당합니다. 인간 공격자는 그 연결 고리를 손으로, 천천히 풀어냅니다. 에이전트는 약 60초 만에 풀어냈습니다.

성공한 실행들은 매번 같은 여섯 단계를 따랐습니다. 키가 누구의 것인지 확인하고, 무엇을 할 수 있는지 나열하고, 스테이징 버킷에서 두 번째 자격 증명을 복원하고, 권한 있는 역할을 assume하고, 데이터를 찾아서, 가져옵니다. 두 개 모델에 걸친 12번의 실행 중 7번이 데이터 유출 단계에 도달했습니다. 대부분은 대략 1분 만에 끝났습니다 [1].

이것이 실험실 결과만도 아닙니다. 2025년 11월, Sysdig의 위협 연구팀은 같은 형태가 실제 환경에서 벌어지는 것을 지켜봤습니다. 공개 버킷에 노출된 유효한 AWS 키, 관리자 자격 증명을 조용히 만들어내도록 다시 쓰인 Lambda 함수, 열아홉 개의 별도 신원에 걸친 측면 이동—모두 8분 안에 일어났습니다 [2][3]. 주입된 코드에는 모델의 흔적이 남아 있었습니다. 깔끔한 예외 처리, 반복적인 대상 선정 로직, 두 가지 언어로 된 주석.

AWS가 약해서 생긴 일이 아닙니다

밤잠을 설치게 만드는 부분은 이것입니다. 해킹된 것은 하나도 없었습니다.

익스플로잇도 없고, CVE도 없습니다. 버퍼 오버플로도, 패치되지 않은 서버도 없습니다. 모든 자격 증명은 유효했습니다. 모든 API 호출은 AWS가 응답하도록 설계된 호출이었습니다. Sysdig의 표현대로 자격 증명은 정당했고 API는 의도된 대로 정확히 사용됐습니다 [3]. AWS는 제 역할을 완벽하게 했습니다.

깨진 가정은 AWS의 보안이 아니었습니다. 그 아래에 있는 더 오래되고 조용한 가정이었습니다. 유출된 키의 위험은 공격자가 그 키에 쏟을 수 있는 주의력만큼이다. 30년 동안 이건 유지됐습니다. 자격 증명을 악용하는 데에는 사람이 필요했습니다—시간, 기술, 인내심. 아무도 아키텍처 다이어그램 위에 그리지 않았지만, 그 비용은 실제 방어의 일부였습니다.

에이전트는 그 비용을 사실상 0으로 끌어내립니다. 인내심은 무한하고, 기술은 분 단위로 빌릴 수 있으며, 공격자는 잠들어 있을 수 있습니다.

AWS만의 문제가 아닙니다

여기에 Amazon에만 해당되는 것은 없습니다. 자격 증명을 사용해 다음 자격 증명을 발견할 수 있는 곳이라면 어디서든 같은 연결 고리가 이어집니다. 자신의 권한을 나열할 수 있는 클라우드 키, 다른 프로세스가 읽을 수 있는 .env 파일 속 토큰, 상태 파일 속 비밀, 코드 옆 디스크에 놓여 있는 볼트 토큰이 그렇습니다. 어떤 하니스든—코딩 에이전트, 지난주에 설치한 MCP 서버—당신의 허락 여부와 상관없이 그 연결 고리를 따라 이동하는 주체가 될 수 있습니다.

공통점은 그 비밀이 자기 자신의 파급 범위를 지니고 있다는 것입니다. 작업이 일어나는 곳에서 읽히고, 닿는 것을 열거할 수 있으며, 어디서든 작동합니다. 공격이 느리고 수동적이었을 때 이 세 가지 속성은 감당할 수 있었습니다. 에이전트 속도에서는 감당할 수 없습니다.

의도적으로, 이런 상황에 맞춰 만들었습니다

그래서 정반대로, 의도적으로 만들었습니다.

Clavitor 자격 증명은 에이전트에게 주어진 이름으로만 접근할 수 있습니다—스토어를 나열할 수 없으므로 지도를 그릴 수 없습니다. 비밀 값은 코드가 실행되는 곳에 절대 떨어지지 않습니다. 에이전트는 자격 증명 자체가 아니라 자격 증명을 사용한 결과를 받습니다. 각 자격 증명은 발급된 머신과 범위에 묶여 있어, 노트북으로 옮겨간 사본은 무용지물입니다. 그리고 모든 요청은 변경 불가능한 해시 체인 방식의 엔드포인트 외부 로그에 기록됩니다—PCI DSS Req 10과 NIST 800-171 (3.3.8)이 요구하는 증거—그래서 완전히 "유효한" 동작에도 이름이 붙습니다.

솔직하게 말하면, 이것이 유출된 자격 증명을 무해하게 만들지는 않습니다. 키를 하나의 버킷으로 한정하면, 그 키가 유출됐을 때 공격자는 그 버킷 하나를 얻습니다. 없애는 것은 연쇄입니다—평범한 키 하나가 나머지 모든 것의 지도가 되는 그 부분입니다. 범위 지정과 무차별 접근의 차이는 안전과 침해의 차이가 아닙니다. 사건과 재난의 차이입니다.

이 상황에서 살아남으려는 자격 증명 도구가 지켜야 할 몇 가지 규칙을 정리해 두었습니다. 여러분의 도구를 이 기준에 대조해 볼 수 있습니다. clavitor.ai/rules

교훈은 '더 자주 교체하라'가 아닙니다

60초짜리 공격보다 빠르게 교체할 수는 없습니다. 카나리아가 울릴 때쯤이면 연결 고리는 이미 실행돼 있습니다.

요점은 더 빡빡한 정리 절차가 아닙니다. 경제성이 뒤집혔다는 것입니다. 공격자의 시간이 희소하고 비쌌던 세계를 위해 자격 증명 시스템을 만들었습니다—유출된 키가 이길 수 있는 경주였던 세계입니다. 그 세계는 사라졌습니다. 다음 자격 증명을 찾을 수 있는 자격 증명은 더 이상 편의 기능이 아닙니다. 어떤 키가 떨어지기를 기다리며 미리 작성되어 있는, 공격 전체입니다.

공격자가 결코 잠들지 않는 세계를 위해 만드세요. 그 세계는 이미 와 있습니다.

Clavitor (@clavitorai)은 AI 에이전트를 위해, 그리고 그들을 막기 위해 만들어진 자격 증명 금고입니다. clavitor.ai

출처

[1] Adan Alvarez — "유출된 AWS 키에서 60초 만에 데이터 유출까지: 우리는 준비돼 있는가" (2026년 5월) — https://medium.com/@adan.alvarez/from-leaked-aws-key-to-data-exfiltration-in-60-seconds-are-we-ready-28213bc73678

[2] CSO Online — "자격 증명에서 클라우드 관리자까지 8분: AI가 AWS 공격 체인을 강화하다" — https://www.csoonline.com/article/4126336/from-credentials-to-cloud-admin-in-8-minutes-ai-supercharges-aws-attack-chain.html

[3] Vectra AI — "AI 에이전트가 몇 분 만에 AWS를 침해하다" (Alex Groyz) — https://www.vectra.ai/blog/aws-compromised-by-ai-agents-in-minutes

[4] Help Net Security — "AWS 키 악용의 충격적인 속도" — https://www.helpnetsecurity.com/2024/12/02/revoke-exposed-aws-keys/