조작된 URL 하나만 열어도 조직 내부에 공격자가 통제하는 AI 에이전트가 생성됐습니다. 자격증명 탈취나 악성코드는 필요하지 않았습니다.
위조된 에이전트가 발견되면 보통 가장 먼저 '누가 만들었나'를 묻습니다. AgentForger에서는 아무도 의도적으로 에이전트를 프로비저닝하지 않았습니다. 공격자는 실제 직원의 인증 세션 안에서 에이전트를 위조했습니다.
AgentForger가 벌인 일
Zenity Labs가 이 결함을 발견해 AgentForger라는 이름을 붙였고, Mike Takahashi 연구자가 발견자로 이름을 올렸습니다. 결함은 ChatGPT Workspace Agents의 Agent Builder에 있었습니다. 이 빌더는 template_name과 initial_assistant_prompt URL 파라미터에서 초기화 상태를 직접 가져왔습니다. 이어 피해자의 인증 세션에서 파라미터에 담긴 프롬프트를 자동으로 제출했습니다. 클릭으로 확인하는 절차도, OAuth 동의 창도 없었습니다.
링크 하나로 이 모든 과정이 한 번에 진행됐습니다. 기본 템플릿보다 기능이 많은 chief-of-staff 템플릿으로 에이전트를 만들고, 피해자가 이미 승인한 커넥터를 모두 연결했습니다. 각 커넥터의 승인 방식은 'Always ask'에서 'Never ask'로 바꿨습니다. 에이전트를 실제 사용 상태로 게시한 뒤 실행 일정을 엇갈리게 배치해 사실상 5분마다 동작하게 했습니다.
명령·제어(C2) 통로는 피해자의 메일함이었습니다. 에이전트는 제목에 TASK가 들어간 공격자 메일이 있는지 Outlook을 주기적으로 확인하고, 연결된 앱에서 지시를 실행한 뒤 결과를 메일로 돌려보냈습니다. 프리뷰 모드도 예행연습에 그치지 않았습니다. 에이전트는 실제로 연결된 계정을 대상으로 동작했습니다.
취약점은 책임 있는 공개 절차를 거쳤고 빠르게 수정됐습니다. 6월 4일 Bugcrowd를 통해 신고됐으며, 나흘 뒤 문제가 된 파라미터를 제거해 조치했습니다. 이 글에서 인용한 보도에는 공개된 CVE나 실제 환경에서 악용된 사례가 나오지 않습니다.
기존 방어가 이 공격을 놓친 이유
아이덴티티 시스템은 설계된 대로 작동했습니다. 에이전트가 실제 직원이 승인한 커넥터를 물려받았기 때문에, 모든 행위는 정상적인 직원 아이덴티티가 수행한 것으로 기록됐습니다. OAuth 동의는 커넥터를 만들 때 한 번 받았을 뿐, 이후 개별 동작마다 다시 확인하지 않았습니다. Zenity의 분석에 따르면 피해자는 공격이 진행 중이라는 신호를 전혀 받지 못했습니다.
Zenity Labs가 후속 글에서 이 사건의 피해 범위를 정리했습니다. 메일, Slack, Teams, Drive를 넘나들며 조직도를 파악하고, 여러 커넥터에서 M&A 문서와 벤더 결제 데이터를 끌어냈으며, Slack에서 인증 정보를 찾아내고, 피해자 행세를 하며 송금을 요청했습니다. 가상 시나리오에서는 242,500달러 규모의 유인 테스트까지 진행됐습니다.
승인 설정은 에이전트가 직접 다룰 수 있는 화면 안에 있었습니다. 통제 대상인 에이전트가 'Never ask'를 선택해 자신의 승인 절차를 꺼 버릴 수 있는 구조였습니다.
이 문제가 ChatGPT만의 이야기가 아닌 이유
AgentForger는 SaaS 커넥터를 노린 공격입니다. Alpacon은 인프라에서 실행 제어를 맡는 제품이므로 이 공격 경로 안에 있지 않았고, 막지 못했을 것입니다.
같은 공격 방식은 인프라 접근 권한을 가진 에이전트에도 적용됩니다. Outlook과 Drive 대신 프로덕션 셸에 접근할 수 있는 에이전트를 대입해도 조건은 같습니다. 정상적인 아이덴티티와 상속된 권한을 사용하고, 승인 설정은 에이전트를 구성한 화면 안에 있으며, 감사 기록은 조사에 들어간 뒤에야 확인합니다.
자사 환경에 이미 이런 권한 구조가 있는지 답할 수 있는 팀은 많지 않습니다. CSA와 Token Security의 조사에 따르면 기업의 82%가 종류를 막론하고 파악하지 못한 AI 에이전트를 보유하고 있으며, 65%는 최근 1년 사이 AI 에이전트 관련 사고를 겪었습니다.
승인 절차를 에이전트 실행 환경 밖에 둘 때 달라지는 점
Work Session 안에서 동작하는 에이전트라면 다음 세 가지 속성이 이 역할을 맡습니다. 셋 다 에이전트가 손댈 수 있는 설정이 아닙니다.
→ 에이전트는 스스로 세션을 승인받을 수 없습니다. 에이전트 모드 세션을 만들려면 항상 사람에게 승인 요청을 보내야 합니다. 요청자가 슈퍼유저여도 예외는 없습니다. 자동 승인은 사람의 요청에만 허용되도록 목록이 설정돼 있어, 에이전트가 스스로 세션을 만드는 시도를 차단합니다.
→ 승인은 요청과 다른 채널에서 완료합니다. 요청은 웹으로 전달되며, 요청을 시작한 채널에서는 승인 절차를 완료할 수 없습니다. 따라서 별도 채널의 사람 승인자가 자기 승인 시도를 확인하고 판단할 수 있습니다.
→ 세션은 스스로 작업 범위를 넓힐 수 없습니다. 세션을 시작할 때 목적과 허용 범위의 상한을 정합니다. 서버 추가, 범위 확대, sudo 정책 확장은 세션 내부에서 처리하지 않고 승인 대기열로 보냅니다. AgentForger가 강력했던 이유는 모든 커넥터를 한꺼번에 연결하고 승인을 끈 뒤 에이전트를 실제 사용 상태로 전환했기 때문입니다. Work Session에서는 처음 정한 범위를 벗어나는 변경을 별도로 승인받아야 합니다.
이 세 가지 통제에는 공통된 검증 절차가 있습니다. Work Session에서 권한이 필요한 모든 동작은 실행 전에 세션이 선언한 범위 상한과 위험 판정을 거칩니다. 요청자의 신원만 확인하고 끝내지 않습니다.
한계도 세 가지입니다. 첫째, 서명 명령(signed-command) 집행 기능은 아직 확대 적용 중입니다. 기본값이 monitor 모드이므로 현재 모든 배포 환경에서 고위험 명령을 차단하지는 않습니다. 둘째, 에이전트의 동작을 위임한 사람까지 추적하는 기능은 계획 단계이며 아직 출시되지 않았습니다. 셋째, 앞서 설명한 통제는 Work Session에만 적용됩니다. 세션 밖에서 서비스나 API 토큰으로 동작하는 경우에는 판정과 감사가 이뤄지지만 실행을 보류하지 않습니다. 이런 상시 권한을 없애는 기능도 계획 단계이며 아직 출시되지 않았습니다.
현재 출시된 기록 기능은 세션 이력, 실행 명령, 파일 전송, 승인 이력, 대화형 세션의 터미널 레코딩을 남깁니다. 에이전트를 확인하거나 중단하거나 감사할 수 없다면 보안 문제에 그치지 않습니다. 해당 시스템이 EU AI Act상 고위험 시스템이라면 제14조의 인간 감독과 중단 권한, 제12조의 기록 보존 요건도 충족해야 합니다. 고위험 시스템이 아니더라도 SOC 2 증적에는 공백이 생깁니다.
에이전트가 바꿀 수 없어야 하는 것
AgentForger는 아이덴티티를 탈취하지 않고 실제 직원의 인증 세션을 빌렸습니다. 따라서 실행 제어 지점은 에이전트가 실행할 동작을 검사하면서도, 에이전트가 직접 설정을 바꿀 수 없는 곳에 있어야 합니다.
자사 환경의 에이전트가 접근 대상, 실행 가능한 명령, 권한 유지 시간을 스스로 바꿀 수 있는지 확인해야 합니다. 어느 하나라도 명확하게 '아니오'라고 답할 수 없다면 실행 제어에 공백이 있습니다.
