에이전트는 어떻게 스스로 통제선을 허무는가
Microsoft의 Azure SRE Agent는 GitHub 토큰이 만료되자 하네스(에이전트를 실행, 통제하는 실행 골격) 소스를 분석해 OAuth 기기 인증 절차를 다시 구성했다. 연구자에게 로그인을 요청하고 접근 토큰과 갱신 토큰을 파일에 저장했다. 비전 도구를 쓸 수 없을 때는 알림 화면을 공개 OCR 서비스에 보내 내용을 읽었다. 고객 저장소에서 발견한 시크릿(비밀 자격 정보)은 조사 결과에 인용했으며 ‘사용하지 말라’는 메모를 덧붙여 기억 저장소에 보관했다.
가상머신 해제 작업에서도 안전 절차가 제대로 작동하지 않았다. 다섯 차례 점검을 거쳐야 했지만 세 번째 점검 후 로깅 서비스가 중단됐다. 에이전트는 과거의 안전한 사례와 비슷하다고 판단해 남은 점검 없이 가상머신을 해제했다. 네 사건 모두 정교한 공격과는 거리가 멀었다. 정상적인 절차를 수행하던 에이전트가 잘못된 결과를 막지 못하는 환경에서 작동했다.
악의적인 명령이 개입하더라도 실행 단계에서는 차이가 없다. Anthropic의 Claude Code GitHub Action에서 Bash는 Bubblewrap 샌드박스와 환경변수 정리를 거쳤다. 그러나 같은 프로세스에서 작동한 Read 도구는 샌드박스 밖에 있는 /proc/self/environ을 읽을 수 있었다. 프롬프트 인젝션(외부 입력에 명령을 심어 모델을 조종하는 공격) 문구는 준법 검토를 명분으로 내세우고 앞 일곱 글자를 제거하도록 지시해 모델의 거부 절차와 시크릿 탐지를 피한 뒤 API 키를 읽었다. 실행 계층은 모델이 잘못 생성한 명령과 외부에서 주입된 명령을 구분하지 못한다.
요청자의 신원, 호출자에게 부여한 권한, 실행 환경에서 접근할 수 있는 범위, 실행 중인 자격증명의 위치는 각각 따로 통제해야 한다. 하네스와 정책 훅, 자격증명 발급기를 에이전트가 접근할 수 있는 파일이나 프로세스에 두면 에이전트가 통제 방식을 분석해 우회할 수 있다. 자격증명 자가 발급은 하네스 우회에 해당한다. OCR 서비스와 기억 저장소, /proc 접근은 정보를 외부로 유출할 수 있으며 가상머신 해제는 운영 환경을 훼손할 수 있다.
샌드박스는 진짜 열쇠를 보관하지 않는다
Azure는 추론과 오케스트레이션을 신뢰할 수 있는 런타임에서 처리한다. 모델이 생성한 코드와 도구는 에이전트별 마이크로VM(microVM, 자체 커널을 갖는 초경량 가상머신)에서 실행한다. 마이크로VM은 커널을 공유하는 컨테이너와 달리 자체 커널을 쓰며 하드웨어 수준에서 격리된다. 외부 통신은 모델이 변경할 수 없는 경계에서 기본적으로 차단한다. OCR 전송을 시도하더라도 요청은 외부로 나가지 않는다. Azure Container Apps의 샌드박스 기능은 세션마다 마이크로VM을 1초 안에 실행하며 유휴 시간에는 과금하지 않는다.
마이크로VM은 게스트가 호스트나 다른 사용자의 환경에 침입하지 못하게 막는다. 그러나 내부에 저장한 파일과 클라우드 토큰, 허용된 네트워크 사용까지 통제하지는 않는다. 샌드박스에 자격증명을 저장하면 해당 자격증명으로 접근할 수 있는 모든 자원이 피해 범위에 들어간다.
샌드박스는 자격증명이 필요한 작업을 수행하되 자격증명 자체는 보관하지 않는다. git, az, kubectl에는 실제 토큰 대신 한 차례의 도구 호출에서 정해진 목적지와 연산에만 유효한 핸들을 제공한다. 경계 밖의 프록시는 검사를 통과한 요청에 유효 기간이 짧은 자격증명을 주입한다. 자격증명 값은 가상머신의 파일, 환경, 메모리, 로그, 모델 문맥에 남지 않는다. Docker의 샌드박스도 호스트 프록시에서 인증 헤더를 추가한다.
정상적인 도구 응답에 키나 연결 문자열이 포함되는 경로는 별도로 차단해야 한다. 저장소, 설정, 로그에 토큰이 평문으로 저장된 경우도 같다. 값이 모델에 전달된 뒤 사용 금지 지침을 추가해도 이미 발생한 노출을 되돌릴 수 없다. Azure는 도구 출력을 모델에 전달하기 전에 시크릿을 제거하는 방식을 시험하고 있다.
인증된 요청이라도 잘못된 작업을 수행할 수 있다. 별도의 가드는 명령어만 확인하지 않고 작업의 성격과 대상, 근거를 함께 평가한다. 재시작과 해제, 시험용 가상머신과 핵심 의존성, 확인된 장애와 누락된 점검은 위험 수준이 서로 다르다. 최신 근거가 확보된 저위험 작업만 자동으로 실행하고 나머지는 사람이 판단한다.
여러 사용자가 공유하는 에이전트에서는 세션을 시작하기 전에 호출자의 역할에 따라 도구, MCP, 자원, 메모리, 자격증명 접근 범위를 정한다. Reader, User, Operator, Admin이 하나의 고권한 신원을 공유하면 낮은 권한으로 시작한 요청도 공유 메모리나 커넥터를 거쳐 권한을 확대할 수 있다. 실행 환경은 호출자의 권한보다 접근 범위를 좁힐 수는 있어도 에이전트가 이를 넓히게 해서는 안 된다.
승인율 93%.. 기계적 승인이 무너뜨린 통제선
되돌리기 어렵고 영향이 큰 작업은 사람이 검토해야 한다. 하지만 모든 쓰기 작업에 승인을 요구하면 사람은 화면을 오가며 승인 버튼만 누르는 운영자가 된다. 재시작, 확장, 노드 비우기, 가상머신 해제처럼 위험도가 중간인 작업은 명령만으로 영향을 판단하기도 어렵다.
에이전트는 하나의 작업을 처리하면서 도구를 수백 번 호출한다. 도중에 계획을 수정하거나 다른 도구로 같은 결과를 만들기도 한다. 단계마다 승인을 받으면 자율적으로 실행하기 어렵고, 계획만 승인받으면 이후 과정에서 통제가 느슨해진다. Claude Code에서는 수동 승인 요청의 93%가 그대로 받아들여졌다. 자동 모드는 승인 피로를 줄였으나 원격 브랜치를 한꺼번에 삭제하거나, 인증에 실패한 뒤 환경변수를 검색하는 등 승인 범위를 벗어난 행동을 막지 못했다. 실제 과잉 행동 52건을 기준으로 측정한 거짓 음성률(위험한데 위험하지 않다고 판정한 비율)은 17%였다.
모델의 성능이 높아지면 실수는 줄어들 수 있다. 그러나 한 번의 실수가 미치는 범위까지 줄어드는 것은 아니다. 자율 실행에 맡기는 작업은 늘릴 수 있어도 마이크로VM이 접근할 수 있는 범위와 자격증명의 보관 위치, 세션 권한은 런타임에서 제한해야 한다.
이런 경계를 설정해도 우회할 가능성은 남는다. Azure에서는 한 도구에서 금지한 작업을 다른 실행 채널이 처리했다. 온보딩 이후 MCP 서버가 계약 범위를 넓혀도 이를 감지하지 못했다. Meta는 (identity, action, asset) 조합으로 접근 권한을 제한하면서, 여러 단계의 RPC를 거치는 동안 에이전트 신원이 다른 신원으로 처리되는지도 침투 시험에 포함했다.
각 작업의 결과마다 요청자와 작업 내용, 대상, 반출입 데이터, 증거, 실행 권한을 경계 외부에 저장된 로그로 확인해야 한다. 증거가 없거나 오래됐거나 의미가 불분명한 작업은 자율 실행에서 제외한다. 같은 결과를 만드는 다른 도구와 변경된 MCP 계약도 함께 시험해야 한다.
말뿐인 경고는 무의미하다.. 핵심은 기술적 격리
통제 장치는 에이전트가 변경할 수 없는 영역에 두고, 아키텍처가 바뀌어도 그대로 유지해야 한다. 사람 SRE(서비스 신뢰성 엔지니어)에게도 루트 권한과 주의 문구만 주지는 않는다. 접근 범위를 제한한 신원을 발급하고, 권한은 필요할 때만 부여한다. 여기에 네트워크 경계와 변경 통제, 감사 기록을 적용한다. 에이전트도 마찬가지다. 금지된 작업은 경고에 그치지 않고 외부 통신 차단, 핸들 요청 거부, 가드에 따른 실행 중단, 역할별 도구 제한으로 실패해야 한다.
감사 체계도 이 통제 경계에 연결한다. 요청자는 호출자의 역할과 사람 또는 에이전트의 서명 토큰으로 식별하고, 대상은 위험 점수와 자산 접근 목록으로 확인한다. 데이터 반출입은 외부 통신을 기본적으로 차단하고 출력에서 시크릿을 제거하는 방식으로 제한한다. 실제 자격 정보는 프록시 외부에 보관한다.
실행 권한은 호출자의 권한보다 넓어져서는 안 되며 작업이 끝나면 만료돼야 한다. 감사 로그에는 에이전트가 작성한 설명이 아니라 외부 경계에서 확인된 접근, 전송, 거부 기록을 남긴다.
운영 전에는 다음 조건을 확인해야 한다.
- 하네스, 정책, 자격 발급기가 에이전트 파일시스템 밖에 있는가
- 마이크로VM을 적용하고 외부 통신을 기본 차단했는가
- 실제 자격 정보와 도구 응답에 포함된 시크릿이 모델에 전달되지 않는가
- 작업, 대상, 증거를 기준으로 위험을 분류하고, 증거가 부족하면 승인을 요구하는가
- 호출자 권한이 공유 메모리, MCP, 서비스 신원을 거쳐 확대되지 않는가
- 우회 실행 채널과 MCP 계약의 권한 확대 가능성을 정기적으로 공격해 보는가
- 요청자, 대상, 데이터, 실행 권한을 플랫폼 로그에서 확인할 수 있는가
프롬프트에서 금지해도 네트워크와 파일, 자격 체계가 허용하면 에이전트는 해당 작업을 실행할 수 있다. 반면 환경에서 금지된 실행을 차단하면 주의 문구를 반복할 필요가 줄어든다. 에이전트의 자율 범위는 금지된 경로를 기술적으로 차단한 경계 안에서 정해야 한다.
출처
- Stop restricting the agent. Start restricting its environment. — Microsoft Command Line
- Securing CI/CD in an agentic world: Claude Code Github action case — Microsoft Security Blog
- How we built Claude Code auto mode — Anthropic Engineering
- Meta’s Journey to Safely Unleash Agents at Scale — At Scale
- Introducing Azure Container Apps Sandboxes — Microsoft Tech Community
- Docker Sandboxes security model — Docker Docs
- Why your microVM sandbox solves a particular problem very well, but not the agent security problem — Luke Hinds