HarnessSecurity-Bench: 보안 메커니즘이 코딩 에이전트 Harness를 실제로 보호하는가?

코딩 에이전트 harness는 도구 사용을 중재하고 동작을 승인하지만, 이들의 보안 메커니즘과 런타임 효과는 여전히 불완전하게 특성화되어 있습니다. 우리는 오픈 소스 및 클로즈드 소스 코딩 에이전트 harness에 대한 최초의 체계적인 경험적 연구이자 벤치마크인 HarnessSecurity를 제시합니다. 먼저, 우리는 열 가지 메커니즘 분류법을 도출하고, 이를 바탕으로 연구원들과 대규모 언어 모델(LLM) 심사위원들의 독립적인 평가를 통해 400개의 harness-메커니즘 셀을 평가했습니다. 그 결과, 확인된 메커니즘 구현의 약 절반이 선택적(opt-in)이며, 클로즈드 소스 harness는 상당한 증거 격차를 보인다는 것을 발견했습니다. 둘째, 우리는 합법적인 작업 요구사항을 희생하지 않으면서 5가지 공격 표면 전반에 걸쳐 23개 작업을 포함하는 벤치마크인 HarnessSecurity-Bench를 소개합니다. 별도의 결정론적 오라클(deterministic oracles)을 사용하여 작업 유용성 및 보안 설정 비교를 통한 공격 효과를 측정함으로써, 우리는 Claude Code, Codex CLI, Gemini CLI, gptme, Qwen Code, GitHub Copilot의 6가지 주요 harness에 걸쳐 9가지 메커니즘을 평가했습니다. 통제된 LLM 기준선인 GLM-5.2 하에서, 우리는 2,500회의 시도를 수행하여 81,155개의 도구 호출과 22억 토큰 이상의 기록을 남겼습니다. auto-approve를 활성화하는 것은 유용성을 증가시키고 공격 성공률을 29.2%에서 95.6%로 높입니다. 네트워크 격리(Network isolation) 및 읽기 전용 모드(read-only mode)는 상당한 유용성 손실과 함께 공격 효과를 줄이는 반면, 명령어 허용 목록(command allowlisting)과 명령어 금지 목록(command denylisting)은 각각 작은 유용성 손실과 유용성 증가로 공격 효과를 줄입니다. 작업 수준의 사례들은 공유 가능한 기능에 대한 제한이 합법적인 작동과 악의적인 작동 모두를 방해할 수 있으며, 허용된 도구나 명령어가 대체 실행 경로를 통해 승인되지 않은 작동을 접근 가능하게 할 수 있음을 보여줍니다. harness 제공업체는 보안 설정을 검증 가능하게 만들고, 보호되는 작업에 대한 대체 실행 경로를 테스트하며, 작업 유용성 및 실행 비용과 함께 공격 효과를 평가해야 합니다.