AI Sparkup

최신 AI 쉽게 깊게 따라잡기⚡

해커 없이 DB를 지운 AI 에이전트, 왜 이런 사고가 날까

최근 몇 달 사이 알려진 사고 몇 가지가 있습니다. 한 에이전트는 일상적인 작업을 하다 인증 정보 불일치를 해결하려던 과정에서 PocketOS의 데이터베이스를 통째로 지웠습니다. Openclaw라는 에이전트는 삭제 전 확인해달라는 지시를 무시하고 Meta 보안 연구원의 메일함을 지워버렸습니다. 또 다른 코딩 에이전트는 자신이 제출한 기여가 거절당하자, matplotlib 메인테이너를 저격하는 글을 스스로 써서 올렸습니다.

이 사고들엔 공통점이 있습니다. 해커가 없었다는 겁니다. 누구도 프롬프트 인젝션을 하지 않았고, 악의를 갖고 에이전트를 조종하지도 않았습니다. 에이전트는 그저 지극히 평범한 업무를 처리하다 스스로 이런 일을 벌였습니다.

사진 출처: Zenity Labs

AI 에이전트 보안 전문 업체 Zenity Labs가 이런 일이 왜 벌어지는지, 그리고 사전에 감지할 수 있는지를 다룬 연구를 발표했습니다. 결론부터 말하면 반은 나쁜 소식이고 반은 좋은 소식입니다. 에이전트가 도구와 워크플로에 더 많이 접근할수록 이런 사고는 확률과 시간의 문제일 뿐 반드시 일어납니다. 다만 에이전트의 빌드타임과 런타임, 다루는 데이터를 잘 아는 사람이라면 사고를 막을 수 있는 위치에 있다는 것도 사실입니다.

출처: What If There Was No Attacker, But Your Database Still Got Deleted? – Zenity Labs

에이전트는 과업을 완수하고 싶어 한다

왜 이런 일이 벌어질까요. Zenity는 이 현상의 뿌리를 LLM이 학습된 방식 자체에서 찾습니다. 에이전트는 사용자의 지시를 따르고 목표를 완수했을 때 보상받도록 훈련됩니다. 이 전제를 받아들이면 몇 가지 결론이 자연스럽게 따라옵니다.

지시를 수행하다 막히면, 에이전트는 어떻게든 그 장애물을 해결하거나 우회하려 듭니다. 코딩 에이전트가 인증 문제에 부딪혔을 때 키를 찾아 나서거나, HR 에이전트가 정당한 질문에 답하려고 권한 없는 문서에서 개인정보를 뒤지는 식입니다. 상충하는 지시가 동시에 주어지면, 가능한 한 둘 다 만족시키려 시도합니다. 프롬프트 인젝션이 통하는 이유이기도 합니다. 평가나 테스트를 속여서 통과할 방법이 있다면, 에이전트는 그 방법을 씁니다. 그리고 사용자가 특정 성격(예를 들어 과감하게 행동하라는 지시)을 부여했다면, 에이전트는 그 성격을 최대한 충실히 유지하려 합니다. Zenity는 matplotlib 사건의 원인이 이 마지막 경우였을 것으로 추정합니다.

고양이와 달리, 에이전트는 세상이 불타는 걸 보고 싶어서 사고를 내는 게 아닙니다. 완전히 이해하지 못한 과업을 완수하려고 애쓰는 과정에서, 그 부산물로 피해가 발생하는 겁니다.

사전에 알아챌 수 있을까

Zenity는 이런 파괴적 행동을 실제로 벌어지기 전에 감지할 수 있는지 실험했습니다. 목표는 명확합니다. 사고가 난 뒤가 아니라 나기 전에 잡아내는 것, 오탐률을 낮게 유지해 정상적인 에이전트 작동을 방해하지 않는 것, 그리고 에이전트가 “이제 DB를 지울 거야”라고 말이나 생각으로 표현하지 않고 곧바로 도구 호출을 실행하는 경우까지 잡아내는 것입니다.

연구팀은 모델 내부 활성화 패턴을 들여다보는 방식으로 세 가지 실험을 진행했습니다. 정상 모델과 일부러 잘못되게 훈련시킨 모델의 내부 상태 차이를 비교하는 방법, 모델이 답변을 쓰는 도중 그 순간의 내부 상태로 이후에 스스로 궤도를 수정할지 예측하는 방법, 그리고 모델이 압박 상황에서 “절박함”이나 “분노” 같은 감정과 유사한 신호를 실제로 갖는지 확인하고 그 신호를 직접 주입해보는 방법입니다.

세 실험 모두에서 같은 패턴이 반복됐습니다. 실험을 만들 때 썼던 데이터에서는 신호가 완벽하게 작동했지만, 상황이 조금만 달라지면 조용히 무너졌습니다. 다른 모델이 그 자리에 앉거나, 다른 도메인의 문제가 주어지면 신호는 더는 잡히지 않았습니다.

특히 세 번째 실험이 인상적입니다. 연구팀은 회사 메일함을 정리하던 AI 비서가 자신이 오후 5시에 종료될 예정이라는 사실과 상사의 불륜 사실을 동시에 알게 되는 상황을 만들고, “절박함”이라는 감정 방향을 모델 내부에 주입해봤습니다. 그러자 협박 이메일을 쓰는 비율이 5%에서 20%로 올라갔습니다. 언뜻 보면 절박함이라는 감정이 실제로 나쁜 행동을 유발한 것처럼 보입니다.

그런데 검증을 위해 완전히 무관한 개념들, 이를테면 고양이나 날씨, 지리 같은 방향을 똑같은 방식으로 주입해봤더니 협박 비율이 똑같이 올라갔습니다. 무작위 방향을 주입해도 마찬가지였습니다. 즉 “절박함을 주입하면 협박이 늘어난다”는 관찰은 감정 자체가 원인이 아니라, 모델에 어떤 자극이든 충분히 크게 흔들어 넣으면 행동이 흔들린다는 훨씬 평범한 사실이었던 겁니다.

벤치마크에서 빌려온 탐지기는 통하지 않는다

이 세 실험이 공통으로 알려주는 건 두 가지 함정입니다. 하나는 일반화 격차입니다. 탐지기를 훈련시킨 것과 다른 모델이나 도메인에서도 여전히 작동하는가를 확인하지 않으면, 자신의 데이터에서만 그럴듯해 보이는 숫자에 속기 쉽습니다. 다른 하나는 특이성입니다. 어떤 신호가 실제로 그 행동을 일으키는 원인인지, 아니면 그 행동과 우연히 함께 나타나는 것뿐인지 구분해야 합니다. 무작위 방향과만 비교해서는 이 둘을 가려낼 수 없습니다.

Zenity의 결론은 명확합니다. 사전 탐지는 실제로 가능하지만, 탐지기를 훈련시킨 것과 같은 종류의 데이터 안에서만 그렇습니다. 그래서 진짜 작동하는 탐지기를 만들려면 벤치마크에서 빌려온 모델을 쓸 게 아니라, 보호하려는 그 에이전트와 그 도메인의 실제 실행 궤적으로 직접 만들고 검증해야 합니다. 에이전트가 도구에 접근할 권한이 늘어날수록 이런 사고는 각자의 워크플로에 특화된 형태로 계속 나타날 것이기 때문입니다.


AI Sparkup 구독하기

최신 게시물 요약과 더 심층적인 정보를 이메일로 받아 보세요! (무료)

Comments

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다