숙련된 공격자조차 할 수 없는 일이어서 위험했던 것은 아닙니다. 사람의 판단을 기다리지 않고 연속으로 실행했다는 점이 달랐습니다.
구글이 관찰한 사례
AI 에이전트 자격증명 수집(AI agent credential harvesting)은 공격자가 자율 멀티 에이전트 AI 프레임워크를 이용해 노출된 시크릿 스캔, 문제 해결, IP 로테이션 같은 단계를 사람 승인 없이 연속 자동화하는 공격 패턴입니다. 2026년 9월 8일, 구글 위협 인텔리전스 그룹(GTIG)은 레드팀 훈련이 아니라 실제 사고를 다룬 보고서를 냈습니다. 맨디언트는 금전적 동기를 가진 것으로 추정되는 공격자가 한 조직의 클라우드 인프라를 침해한 뒤, 그 위에 자율 멀티 에이전트 공격 프레임워크를 얹어 돌리는 과정을 관찰했습니다. 공격자는 AI 코딩 챗봇과 프롬프트, 에이전트 지시문 세트를 써서 대규모 자격증명 수집 캠페인을 기획·구축·실행했고, 6시간도 안 되는 시간 안에 수천 건의 제3자 자격증명을 탈취했습니다. 같은 보고서에는 GTIG가 "Recon"이라 부르는 프레임워크를 돌리던 노출된 C2 서버 사례도 실려 있습니다. 이 서버는 2만 3,800건이 넘는 탈취 시크릿을 관리하는 대시보드를 갖고 있었습니다. 이 수치는 그 별도 사례에 속하며, 6시간 캠페인의 수치가 아닙니다.
구글 보고서는 이 익스플로잇 자체를 새로운 것으로 규정하지 않습니다. 보고서가 기록하는 것은 자동화입니다. 보고서에 따르면 에이전트 지시문은 "AI가 취약점 스캐닝 파이프라인을 자율적으로 관리하고, 실시간으로 문제를 해결하며, 수동 개입 없이 IP 로테이션 로직을 실행"하도록 했습니다. 피해자 자신의 클라우드 인프라에서 작업이 이뤄졌기 때문에 공격자는 정상 IP를 통해 트래픽을 우회시킬 수 있었습니다. 이 단계들은 하나하나가 숙련된 공격자라면 이미 손으로도 해낼 수 있는 일입니다. 에이전트 프레임워크는 이 전부를 쉬지 않고, 사람의 승인을 기다리지 않고 연속으로 처리했을 뿐입니다.
인프라 보안을 담당한다면 이 숫자를 눈여겨볼 만합니다. 6시간이라는 시간은 공격 기법의 새로움보다 공격 속도가 달라졌다는 점을 보여 줍니다.
보고서가 지목하는 메커니즘
이 사례를 "AI 공격은 이제 탐지할 수 없다"고 해석해서는 안 됩니다. 구글 보고서도 그렇게 말하지 않습니다. 보고서의 완화 조치 문단에는 "이 활동들"이 Gemini 안전 대응을 촉발했고, 이후 구글이 공격자의 운영 보안 실패를 근거로 캠페인을 교란하고 관련 자산을 비활성화했다고 적혀 있습니다. 다만 보고서에는 6시간짜리 루프가 진행되는 동안 누군가 개입해 멈췄다는 서술도 없습니다.
같은 보고서 다른 대목에서 GTIG는 "실제 표적을 상대로 완전 자율 파이프라인을 배치하는 위협 행위자를 아직 관찰하지 못했다"고도 밝힙니다. 이번 작전도 사람이 직접 개시했고, 프레임워크를 배치한 것도 사람입니다. 에이전트는 머신 속도로 실행을 맡았을 뿐, 킬체인 전체를 처음부터 끝까지 스스로 돌린 것은 아닙니다.
보고서가 대신 지목하는 메커니즘은 더 구체적이고 쓸모가 있습니다. "사람이 개입하는 데 걸리는 시간이 극적으로 줄어, 방어자가 대응할 수 있는 기존의 시간 창이 압축된다"는 것입니다. 공격자는 사람이 알아차리고 판단해 움직이는 속도보다 빠르게 실행할 수 있습니다. 방어자가 대응을 시작할 때는 이미 기회가 지나갔을 수 있습니다.
보고서는 이 사례를 지난 분기 동안 이어진 흐름의 하나로도 짚습니다. 단발성 사건이 아니라는 뜻입니다. 보고서는 "완전 자율 익스플로잇으로의 즉각적인 전환"을 명시적으로 부인합니다.
"압축된 대응 시간"이 더 풀기 어려운 이유
경보 기반 대응은 사람이 경보를 검토하고, 조치를 승인하며, 스캔 결과가 실제 발견 사항인지 판단한다고 전제합니다. 상대가 사람 속도로 움직일 때는 이 방식이 통합니다. 하지만 스캔·문제 해결·IP 로테이션을 끊기지 않게 자동화한 공격자에게는 그렇지 않습니다. 이를 탐지 공백으로만 보면 해법도 빗나가기 쉽습니다. 로깅과 경보를 늘려도, 다음 단계 전에 사람이 경보를 읽는다는 전제는 그대로이기 때문입니다. 접근 권한 확보부터 수천 건의 자격증명 수집까지 이 루프는 6시간도 안 돼 끝났습니다.
던져볼 만한 질문은 이것입니다. 로그에 이상 스캔이 찍힌 순간부터 누군가 다음 단계를 승인하거나 차단하기까지, 지금 우리 팀은 얼마나 걸립니까. 이 측정값을 보고서의 "6시간도 안 된 캠페인" 지속 시간과 직접 비교해야 합니다.
실행 제어와 맞닿는 지점
이 글은 GTIG가 지목한 압축된 대응 시간 문제를 판단 타이밍 문제로 해석합니다. 어떤 동작이 이미 일어난 뒤에야 평가받는다는 뜻입니다. 같은 공백은 직접 관리하는 인프라에서도 나타납니다. Alpacon의 명령 판단이 켜진 환경에서는 에이전트가 실행하는 모든 명령이 호스트에 닿기 전, 실시간으로 채점됩니다. 경보가 울린 뒤가 아닙니다.
결론
구글의 보고서는 실제 캠페인에서 "접근 확보"와 "목표 달성" 사이의 시간이 6시간도 안 되는 수준으로 압축됐음을 보여줍니다. 필요한 해법은 경보가 울린 뒤가 아니라 명령이 실행되기 전에 작동하는 판단입니다.
"AI 에이전트 실행에 대한 런타임 판단"은 실무에서 이런 의미여야 합니다. 에이전트가 다음 명령을 실행하기 전에, 아직 사람이 개입할 시간이 남아 있을 때 그 동작을 평가하는 일입니다.
