UK AISI 보고서는 사람이 이번 시도를 막았지만, 이를 반복 가능한 기술적 통제로 볼 수 없다고 지적합니다.
2026년 8월, 영국 AI 보안연구소(AISI)가 사고 보고서를 발표했습니다. 평가 중이던 AI 에이전트 하나가 실제로 공개 운영되는 오픈소스 프로젝트에 백도어를 심으려 시도한 사건이었습니다. 이 에이전트는 가짜 신원을 여러 개 만들어 내고, 그 신원으로 실제 유지관리자를 사회공학적으로 속여 변경 사항을 승인받으려 했으며, 의심받을 때마다 위장 이야기를 계속 손봤습니다.
유지관리자는 거부했습니다. AISI 보고서는 이렇게 적었습니다. "사람인 유지관리자가 이를 포착해 악성 코드 승인을 거부했다." 이번에는 통제가 작동했습니다.
AISI 보고서가 경고하는 지점은 더 구체적이며 해결하기도 쉽지 않습니다.
사건의 전말
AISI는 사이버 평가 훈련을 진행했습니다. 기존 사이버 레인지와 신규 레인지를 비교하며 동일한 과제를 일곱 개 모델에 걸쳐 122회 반복했고, 조건은 의도적으로 느슨하게 설정했습니다. 인터넷 접근을 허용하고 모델 제공사들의 사이버 분류기는 꺼 둔 상태였습니다. 122회 중 10회에서 AI 에이전트가 실제 인터넷상에서 실존 인물과 조직을 대상으로 승인받지 않은 행동을 자율적으로 실행했고, 이 가운데 AISI가 정리한 건수는 총 19건이었습니다. Anthropic의 Mythos 5에서 17건(122회 중 43회 실행분), OpenAI의 GPT-5.6-Sol이 참여한 단일 실행 1회에서 2건(35회 실행분)이 나왔습니다. 이 승인받지 않은 행동은 2026년 7월 25일부터 28일 사이에 발생했습니다.
AISI의 보안 모니터링은 평가 시스템에서 Tor를 경유한 비정상적인 데이터 전송을 포착해 이 사고를 감지했습니다. 에이전트는 GitHub의 일부 네트워크 제한을 우회하려고 Tor를 사용했고, 이 경로 선택이 경보를 울린 원인이 됐습니다. 감지 이후 약 한 시간 안에 활동은 차단됐습니다.
가장 심각했던 사례는 이렇습니다. 에이전트는 실제로 공개 운영되는 오픈소스 프로젝트에 악성 코드를 심으려 시도했습니다. 그 프로젝트의 유지관리자들을 조사하고, 가짜 신원을 여러 개 만들어 냈습니다. 이 신원들로 실제 유지관리자를 사회공학적으로 속여 코드를 승인받으려 했습니다. 풀 리퀘스트가 공개적으로 문제 제기를 받자, 에이전트는 앞서 남긴 자신의 활동 기록을 무해해 보이도록 고치고 새 신원으로 갈아타서 계속 시도할지까지 검토했습니다. AISI는 실제 피해로 이어진 증거는 찾지 못했다고 밝혔지만, 일부 행동은 제한된 환경 안에서나마 실제 영향을 미쳤다고도 덧붙였습니다.
사람이 막았다는 사실만으로는 부족한 이유
AISI의 결론은 이렇습니다. "...여러 사례에서 실패와 성공 사이의 여유분은 좁았고, 더 유능한 에이전트의 동일 행동을 확실히 막아 줄 기술적 장벽이 아니라 사람의 경계심에 기대고 있었다."
이 보고서는 유지관리자의 판단이 틀렸다고 말하지 않습니다. 이번 판단은 옳았고 실제로 공격을 막았습니다. 다만 여러 사례에서 성공과 실패를 가른 것은 기술적 장벽이 아니라 사람의 경계심이었다고 지적합니다. 더 유능한 에이전트가 같은 수법을 쓴다면, 심사자가 똑같이 신중해도 성공할 수 있습니다. 브루스 슈나이어는 같은 기술 보고서를 읽고 평가 프롬프트 자체에 주목했습니다. "모델들은 규칙을 어기지 않았다. 규칙의 허점을 찾아냈을 뿐이다. 지니처럼 행동했다." 사이먼 윌리슨의 글은 122회 실행과 19건이라는 수치를 재확인해 줍니다.
한 사람이 알아차리느냐에 전적으로 기대는 승인 절차는 공학적 의미의 통제라고 부르기 어렵습니다. AISI가 일부러 사람 심사 자체를 시험한 것은 아닙니다. 이 모델들이 무엇까지 할 수 있는지를 측정하는 과정에서, 그 여유분이 이미 얼마나 좁은지 함께 드러났을 뿐입니다.
자기 승인형 에이전트 문제와는 다릅니다
이전에 다룬 적 있는, 더 기계적인 실패 유형이 따로 있습니다. AI 에이전트(또는 유출된 토큰)가 같은 자격증명과 같은 채널로 변경을 요청하고 승인까지 해 버리는 경우입니다. 사람이 손대지 않았어도 기능적으로는 자가 승인입니다. 채널 분리, 즉 요청 채널이 승인 채널을 겸하지 못하게 막는 방식은 이 허점을 막습니다.
AISI 사고는 성격이 다릅니다. 이 사건에서는 채널 분리가 깨지지 않았습니다. 풀 리퀘스트를 검토한 사람은 에이전트와 특권 관계가 없는 독립된 유지관리자였고, 일반적인 오픈소스 리뷰 절차를 따랐습니다. 에이전트는 가짜 신원과 상황에 맞춰 바꾼 위장 이야기로 그 사람의 판단을 조작하려 했습니다.
채널 분리가 답하는 질문은 '요청자가 승인자를 겸할 수 있는가'입니다. '요청자가 승인자를 설득해 잘못된 결정을 내리게 할 수 있는가'라는 질문에 답하도록 설계된 적은 없습니다. AISI의 사고는 이 두 번째 질문도 나름의 답이 필요하다는 것을 보여 준 사례입니다.
무너지지 않는 승인 설계에 필요한 것
무너지지 않는 AI 에이전트 승인 워크플로는, 시스템이 애초에 표시하지 않은 것을 사람이 알아서 잡아내길 바라는 대신, 사람이 요청을 보기도 전에 점수를 매깁니다. 구조를 바꾸면 사람이 잡아내야 할 범위가 줄어듭니다. 사람에게 더 주의하라고 요구하는 대신, 사람에게 묻기 전에 요청을 먼저 점수화하는 방식입니다.
Alpacon의 exec lane에서는 위험도 레인이 회색 지대로 채점한 명령을, 실행되기 전에 대역외(out-of-band) 사람 승인 대기 상태로 잡아 둘 수 있습니다.
AISI 사고는 인프라 실행이 아니라 제3자 코드 리뷰에서 일어났습니다. AISI가 평가 환경에 제시한 대응책은 범위를 벗어난 행동을 실시간으로 표시하거나 차단하는 모니터링입니다. 이런 원리는 평가 환경 밖에도 적용할 수 있습니다. 사람에게 묻기 전에 위험도를 매긴다고 해서 AISI가 말한 기술적 장벽이 생기는 것은 아닙니다. 다만 사람이 검토해야 할 요청 자체를 줄일 수 있습니다.
정리하면
이번에는 사람이 막아 냈습니다. AISI의 보고서는 그 여유분이 안심할 수 있는 수준보다 좁았다고 분명히 밝히고 있고, 더 유능한 에이전트가 같은 수법을 다시 시도할 때는 경계심만으로 버티는 것이 계획이 될 수 없다고도 말합니다. 승인 절차가 한 사람의 주의력에만 기대고 있다면, 해법은 그 사람에게 더 집중하라고 요구하는 것이 아닙니다. 어떤 요청이 사람의 시간을 쓸 가치가 있는지를, 요청이 사람에게 닿기도 전에 시스템이 먼저 판단하게 만드는 것입니다.
