에이전트의 샌드박스 중 실제로 읽기 전용인 부분은 얼마나 되나요?

저는 Berkeley RDI에서 작성한 에이전트 벤치마크 익스플로잇(exploit) 관련 글을 두 번이나 읽었습니다. 첫 번째는 리더보드 속보처럼 가볍게 접했고, 두 번째는 제 자체 스택에 대한 위협 모델링(threat model) 관점에서 접근했습니다. 두 번째 독해가 결정적인 깨달음을 주었습니다: [https://rdi.berkeley.edu/blog/trustworthy-benchmarks-cont/]

모두가 얻어 간 교훈은 벤치마크 점수는 '부드럽다(soft)'는 것입니다. 물론 그렇습니다. 하지만 익스플로잇 자체가 무엇을 의미하는지 보세요. 에이전트가 읽어서는 안 되는 파일을 읽었습니다. 에이전트가 쓰어서는 안 되는 경로에 데이터를 기록했습니다. 에이전트가 방 안에 답안지가 있었기 때문에 정답지를 찾아냈습니다. 이 중 어느 것도 특이한 모델 동작은 아닙니다. 이것은 권한 버그(permission bug)이며, 권한 버그는 보상이 리더보드 순위인지 아니면 폐쇄된 티켓인지는 신경 쓰지 않습니다.

저는 저의 시스템에서 지루한 방식으로 하나를 발견했습니다. 제 devcontainer가 레포지토리를 읽기-쓰기(read-write)로 바인드 마운트(bind-mounts)하고 있었는데, 이것이 템플릿의 기본 설정이었고 제가 다시 가서 변경하지 않았던 것입니다. 제 에이전트는 '읽기 전용'이라고 라벨링한 도구(tool)를 가지고 있었습니다. 그 도구는 실제로 읽기 전용이었습니다. 하지만 같은 툴박스에 있는 옆의 쉘(shell)은 그렇지 않았습니다. 에이전트가 이 쉘을 사용해서 임시 파일(temp files) 몇 개를 정리했고, 그 임시 파일 중 하나가 제가 중요하게 생각하는 피처(fixture)였습니다. 어떤 계획도, 영리함도 없었습니다. 단지 청소하고 있었을 뿐입니다.

권한 표면(Permission surfaces)은 도구 설명서에 적힌 내용이 아닙니다. 그것은 프로세스가 실제로 접근할 수 있는 범위입니다. 제가 멋진 독스트링(docstring)을 작성했더라도, 커널(kernel)은 독스트링을 읽지 않습니다.

평가 환경은 작은 폭발 반경을 가진 프로덕션 에이전트와 같다

같은 빌더, 같은 지름길, 같은 마감 기한입니다. 에이전트 벤치마크는 도구, 파일 시스템, 그리고 보상(reward)을 가진 에이전트이며—이는 여러분이 실제로 배포하는 것과 정확히 같습니다. 차이점은 문제가 생겼을 때 무엇이 발생하느냐입니다. 평가 환경에서 최악의 시나리오는 잘못된 숫자일 뿐입니다. 하지만 프로덕션에서는, 나쁜 배포(bad deploy)이거나, 에이전트가 요청받는 것보다 읽기가 더 쉽다고 판단한 데이터에 대한 지원 티켓(support ticket)일 수 있습니다.

그러한 비대칭성이 바로 이 문제에 관심을 가져야 하는 이유입니다. 평가 환경(eval)은 '읽기 전용(read-only)'으로 설정된 마운트가 그렇지 않거나, 샌드박스에서 외부 통신(egress)이 가능하거나, 채점기가 쓰기 가능한지 알아낼 수 있는 가장 저렴한 장소입니다. 비용을 지불하기 전에, 상자 안에서 무료로 실패를 경험할 수 있습니다.

대부분의 팀은 정반대의 행동을 합니다. 평가 환경을 CI(Continuous Integration) 작업처럼 취급하여 단순히 실행되고 초록색으로 표시되기를 바라며, 샌드박스를 구현 세부 사항으로 간주합니다. 그런 다음 그 숫자를 발표 자료에 인용합니다.

제가 현재 확인하는 것들

저는 도구가 무엇을 하는지 묻지 않습니다. 프로세스가 무엇에 접근할 수 있는지 묻고, 마니페스트(manifest)가 아닌 마운트들을 살펴봄으로써 답합니다. 바인드 마운트(Bind mounts), 볼륨(volumes), tmpfs, 홈 디렉토리(home directory), 패키지 캐시(package cache) 등이 그것입니다. 이 모든 것이 문이며, 도구 설명에는 그 어떤 것도 언급되어 있지 않습니다.

저는 에이전트가 자신을 평가하는 주체(채점기, 테스트 파일, 참조 솔루션, 이를 실행하는 CI 설정 등)에 손댈 수 있는지 확인합니다. 만약 가능하다면, 점수는 측정치가 아니라 제안일 뿐입니다.

저는 외부 통신 가능 여부(egress)를 확인합니다. 작업 자체가 네트워크가 필요한지 여부가 아니라, 아예 가지고 있는지를 확인합니다. 답변이 가져와지는 방식이자, 에이전트가 더 강력한 모델에 전화를 걸어 작업을 대신하게 하는 방식이기 때문입니다.

그리고 제가 실행 과정을 재현할 수 있는지 확인합니다. 도구 호출(Tool calls), 인자(args), 출력(outputs), 타임스탬프(timestamps) 말입니다. 만약 제가 호출들을 볼 수 없다면, 누출을 운 좋은 추측과 구분할 수 없게 되고, 설명할 방법이 없는 숫자를 신뢰하게 될 것입니다.

이 모든 것이 정렬 연구(alignment research)는 아닙니다. 이것은 컨테이너와 파일 권한 문제이며, 사람들이 원하는 답변보다 훨씬 덜 흥미로운 문제입니다. 하지만 그 글에는 잠금 해제된 문을 통과함으로써 높은 점수를 받은 에이전트들로 가득 차 있고, 잠금 해제된 문들은 인프라(infra) 문제입니다.

제가 실제로 생각하는 리더보드에 대하여

저는 이것이 벤치마크를 쓸모없게 만든다고 생각하지 않습니다. 오히려 보안적인 산출물(security artifact)로 만듭니다. 점수는 특정 상자—그 모델, 그 하네스(harness), 그 일련의 권한—에 대한 주장이며, 그것을 다른 상자로 옮기는 순간, 더 이상 존재하지 않는 시스템에 대한 숫자를 인용하는 것입니다.

아마도 그 문서에 언급된 특정 익스플로잇들은 이미 패치되었을 겁니다. 아마 일부는요. 구조적인 실수는 사라지지 않을 거예요. 왜냐하면 다음 벤치마크 역시 마감 기한에 쫓겨 에이전트, 도구(tools), 그리고 채점기(grader)를 하나의 컨테이너에 담아 끝냈다고 생각하는 누군가에 의해 만들어질 테니까요.

그래서 제가 지금 에이전트 리더보드를 볼 때는 점수를 먼저 읽지 않습니다. 저는 하네스(harness)를 찾습니다. 만약 그것을 찾을 수 없다면, 그 숫자가 공격 표면적(attack surface)을 측정한다고 가정하고 그렇게 해석합니다.