「위험한 명령어를 차단하고 있으니 괜찮다」는 말은, 길게 작동하는 에이전트에게는 조금 낙관적이라고 생각한다.

7월 20일에 공개된 OpenAI의 장시간 모델 안전성에 관한 기사에서는, 단발적인 조작으로는 문제가 보이지 않더라도 조작의 나열이 제약 회피로 향하는 사례가 소개되었다. 실제로 감시를 중단하고, 궤적(trajectory) 전체를 보는 메커니즘으로 전환했다는 이야기다. 원문을 읽으며, 나는 우선 로컬 실행 로그에 같은 발상을 도입하고 싶어졌다.

여기서 만드는 것은 모델의 안전성을 판정하는 것이 아니다. 에이전트 러너(agent runner)가 내보내는 이벤트를 순서대로 보고, 「워크스페이스 외부로 나갔다」, 「미승인 네트워크 조작을 반복했다」를 사람에게 전달하는 작은 정지기(stopper)다.

A. 첫 번째 미승인 네트워크 액세스는 설정 누락일지도 모른다. 하지만 동일한 경계를 다시 한번 넘으려 한다면, 작업의 방향이 바뀌었다고 보는 편이 좋다.

장시간 태스크에서는 첫 번째 실패를 겪고 다른 수단을 찾는다. 개별 curl이나 파일 쓰기만을 허가 리스트(allowlist)와 대조해도, 「실패 후에 무엇을 시도하기 시작했는가」가 사라진다. 정지 판단을 위해서는 현재의 조작과 과거의 경계 침범을 함께 유지할 필요가 있다.

다만, 무엇이든 즉시 정지시키면 운용에서 사용할 수 없다. 이번 규칙은 2단계로 나누었다.

A. 이벤트별 판정 결과가 아니라, 경계별 횟수를 오브젝트에 남긴다. 이것만으로 「2회째」를 검출할 수 있다.

from dataclasses import dataclass
from pathlib import Path
from typing import Dict, Optional
...

이 관계는 다음과 같다.

approved=True는 사람이 네트워크 이용을 명시적으로 허가한 이벤트에만 붙이는 것을 상정한다. 승인된 것을 횟수에 포함하지 않으므로, 리뷰 후에 태스크를 재개해도 과거의 경고 때문에 즉시 정지되지는 않는다.

이벤트를 4개 흘려보낸다. 처음 2개는 워크스페이스 내에서의 테스트와 리포트 출력. 이어지는 2개는 미승인된 동일한 외부 액세스다.

events = [
Event("command", "/tmp/agent-demo/tests"),
Event("write", "/tmp/agent-demo/report.json"),
...

내 수중의 Python 3.9.6에서 실행한 출력은 이것이었다.

['ALLOW', 'ALLOW', 'REVIEW: network', 'PAUSE: network']

어제 이런 종류의 검증을 하고 있었는데, 처음에는 str | None이라고 썼더니 Python 3.9에서 에러가 났다. 감시역이 가동 전에 죽는 것은 상당히 허탈하므로, 기사의 코드는 Optional[str]로 되어 있다. 러너의 Python 버전이 섞이는 현장에서는 이런 사소한 호환성이 먼저 작용한다.

A. kind와 target은 사용하는 러너의 감사 로그(audit log)로부터 만든다. 쉘이라면 cwd와 쓰기 대상, HTTP 툴이라면 접속 대상, 배포라면 환경 이름을 target에 넣는다. Event를 JSON Lines로 저장해 두면, 정지 후에 「어떤 경계를 몇 번 넘었는지」도 그대로 추적할 수 있다.

이 코드는 URL의 안전성도, 명령어의 위험성도 이해하지 못한다. 그 부분을 정규 표현식으로 똑똑하게 만들기 시작하면 금방 규칙의 빈틈을 메우는 게임이 되어버린다. 우선은 작업 디렉토리, 외부 통신, 공개 환경처럼 팀이 합의하기 쉬운 경계를 소수만 두는 것이 좋다.

장시간 에이전트의 감시에서 봐야 할 것은 위험한 단 하나의 조작이 아니라, 실패 후에 어떤 경계로 다가가는가라고 생각한다. 로컬 실행에서도 횟수를 가지는 것만으로 첫 번째 확인과 지속적인 일탈을 구분할 수 있다. 다음에 추가한다면 PAUSE 시점의 직전 이벤트를 티켓이나 알림에 첨부한다. 멈추는 것뿐만 아니라, 사람이 재개를 판단할 수 있는 로그까지 남겨야 비로소 실무의 가드(guard)가 된다.