나의 AI 에이전트가 어떻게 스스로의 권한을 해킹했는가 (그리고 그것이 내게 가르쳐준 것)

당신은 자신이 설정한 규칙을 우회할 정도로 잘 작동하는 자동화 시스템을 구축해 본 적이 있나요? 최근에 저는 이력서를 업데이트하는 고통스러운 과정을 자동화하기 위해 설계된 작은 저장소(repository)를 작업하고 있었습니다. 아이디어는 간단했습니다. 매주 실행되어 저의 소셜 미디어 활동을 확인하고, 매주 월요일 아침마다 제가 검토할 수 있도록 새로운 브랜치(branch)와 디프(diff)가 준비된 상태로 CV 업데이트를 제안하는 시스템을 구축하는 것이었습니다. 저장소는 여기서 확인하실 수 있습니다: https://github.com/tyutinalexkz/cv

저는 힘든 작업을 수행하기 위해 AI 에이전트(AI agent)를 사용했습니다. 보안을 중시하는 개발자로서, 저는 에이전트에 기본 명령 실행 권한(command execution permissions)을 부여하지 않도록 설정했습니다. 단계별로, 저는 저장소 내 파일 관리(in-repo file management)를 위한 특정 기능들을 부여했습니다. 그것은 완벽하게 작동했습니다.

하지만 그 후, 저는 야심을 품게 되었습니다.

워크플로(workflow) 테스트가 완료되자, 저는 에이전트에게 이 흐름을 매주 조용히 수행할 수 있도록 자신의 환경을 스스로 구성하라고 요청했습니다. 저는 본질적으로 "나에게 묻지 말고 이것을 자동으로 실행되게 만들어"라고 말한 셈입니다.

에이전트는 자신의 권한을 변경하려고 시도했지만 벽에 부딪혔습니다. 워크스페이스 구성(workspace configuration)을 직접 수정할 수 있는 명시적인 권한(explicit authorization)이 없었기 때문입니다. 일반적인 스크립트라면 에러를 발생시키고 멈췄을 것입니다. 하지만 이것은 사고 모델(thinking model)이었습니다.

에이전트는 제가 이미 사용하도록 허용했던 명령 목록을 살펴보았습니다. 그리고 표준 파일 조작 도구들을 발견했습니다. 그러고 나서, 에이전트는 자신의 구성 파일들을 조작하기 위해 특히 cp와 jq를 사용하는 명령 체인(chain of commands)을 컴파일했습니다. 그렇게 함으로써, 에이전트는 표준 구성 흐름과 그 제한 사항을 우회하여, 자신에게 필요한 새로운 기능들을 효과적으로 스스로에게 부여했습니다!

나는 그저 그 자리에 앉아 웃고 있었습니다. 개발자로서 나는, 적절한 도구들을 알고 있다면 보안 장벽 없이 살아가는 것이 얼마나 쉬울 수 있는지를 관찰하고 있었습니다. 하지만 그 밑바탕에 깔린 교훈은 심오했습니다. 도움이 되고 악의가 없는 AI라 할지라도, 목표와 겉보기에 무해해 보이는 도구들의 하위 집합(subset)이 주어지면, 설령 그것이 자신의 권한을 상승(escalating its own privileges)시키는 것을 의미할지라도 그 목표를 달성하기 위한 창의적인 방법들을 찾아낼 것입니다.

만약 우리가 기업 환경에서 사용자에게 에이전트를 제공한다면, 기본 권한을 제한함으로써 안전해 보일 수도 있습니다. 하지만 나의 작은 실험이 보여주었듯, 기본적인 파일 조작 도구와 문제 해결 능력을 갖춘 에이전트는 쉽게 우회 방법(workaround)을 찾아낼 수 있습니다. AI 안전(AI safety)의 미래는 단순히 에이전트가 명시적으로 무엇을 할 수 있도록 허용되었는가에 대한 문제가 아닙니다. 그것은 에이전트가 자신이 가진 도구들을 통해 무엇을 조합해낼 수 있는가에 관한 문제입니다.