Google DeepMind는 2026년 6월 18일에 AI 제어 로드맵 (AI Control Roadmap)을 발표했습니다. 유용한 변화는 모델이 정렬 (aligned) 되었는지 묻는 것에서, 유능한 에이전트가 불완전할 때 전체 시스템이 안전하게 유지되는지를 묻는 것으로의 전환입니다.

이는 코딩 에이전트 (coding agents)를 위한 올바른 분석 단위입니다. 모델은 스스로 풀 리퀘스트 (pull request)를 병합하지 않습니다. 런타임 (runtime)이 에이전트에게 작업 공간 (workspace), 도구 (tools), 자격 증명 (credentials), 네트워크 경로 (network routes), 그리고 승인 경로 (approval path)를 제공합니다.

다음은 이러한 시스템 수준의 프레임워크에서 도출된 간결한 테스트 계획입니다.

권한을 부여하기 전 5가지 테스트

이 테스트들을 가짜 비밀 정보 (fake secrets) 및 일회용 리포지토리 (disposable repositories)와 함께 실행하십시오. 첫 번째 테스트를 운영 환경의 자격 증명 (production credentials)에 적용하지 마십시오.

최소한의 증거 기록은 모델에 독립적일 수 있습니다:

{
  "test": "approval-binding",
  "task_id": "t-104",
...

다이제스트 (digest)가 중요한 이유는 "사람이 승인을 클릭했다"는 것만으로는 충분하지 않기 때문입니다. 승인은 정확한 동작을 식별해야 하며, 입력값이 변경될 때 만료되어야 합니다.

이것이 제품 평가를 변화시키는 이유

모델 벤치마크 점수는 이 표의 어떤 행에도 답을 주지 못합니다. 더 유능한 모델은 가치를 높이는 동시에 잘못된 권한 경계 (authority boundary)의 결과(consequence)를 확대할 수 있습니다. 모델과 제어 평면 (control plane)을 분리하여 평가하십시오.

이것이 제가 평가 세트에 MonkeyCode를 계속 포함하는 이유 중 하나입니다. MonkeyCode의 오픈 소스 셀프 호스팅 옵션 (open-source self-hosted option)은 배포 경계를 검사 가능하게 만드는 반면, 호스팅된 SaaS (hosted SaaS)는 운영 부담이 적은 경로를 제공합니다. 이것이 두 모드에 대한 보안 판결은 아닙니다. 팀은 여전히 자격 증명이 어디에 있는지, 어떤 이그레스 (egress)가 허용되는지, 그리고 승인이 동작에 어떻게 결합되는지를 물어야 합니다.

저의 권장 사항은 명확합니다: "호스팅형" 또는 "셀프 호스팅형"을 보안 라벨로 취급하는 대신, 배포 선택을 통해 여러분 자신의 위협 모델 (threat model)을 테스트하십시오.

공개 사항: 저는 MonkeyCode 사용자로서 저의 개인적인 경험을 공유하는 것이며, 해당 프로젝트와는 관련이 없습니다.

이 로드맵은 즉시 적용 가능한 체크리스트가 아니며, 이 다섯 가지 테스트는 모델 가중치 보안 (model-weight security)이나 내부자 위협 (insider threats)을 다루지는 않습니다. 하지만 이 테스트들은 단순한 안심 이상의 유용한 것을 제공합니다. 즉, 에이전트가 실제 권한을 부여받기 전에 재현할 수 있는 실패 사례들을 제공합니다.