Agent Safety Should Be a Runtime Contract 요약 설명

목차

• 요약
• 2 Why Model-Only Alignment Fails on Both Counts
• 3 Mismatches Between Model Alignment and Agentic Deployment
  • 3.1 Preventive Mismatch
  • 3.2 Evidential Mismatch
  • 3.3 Combined Mismatch
• 4 The Two Faces of the Safety Harness
• 5 Empirical Evidence
• 6 Example: Code-Patch Submission
• 부록
• 짧은 생각

이번 글에서는 Agent Safety Should Be a Runtime Contract 논문의 핵심 포인트만 간단히 정리한다.

• 2026년 8월 11일(Arxiv), Preprint
• Ng, Albus W., Han, Yi, Zhang, Jusheng, Wang, Wenhao.
• Vast Intelligence Lab, Southwest University, Sun Yat-sen University
• 논문 링크

요약

• 이 논문은 코드 실행, 파일 변경, 메시지 전송, 데이터베이스 수정처럼 결과를 일으키는 AI agent의 안전성을 모델 학습만으로 보장하기는 구조적으로 불충분하다고 주장한다. 저자들은 harness가 런타임에 강제하는 계약을 제안하며, 위험한 행동을 실행 전에 제한하는 예방적 측면과 검증 가능한 산출물이 있을 때만 완료를 승인하는 증거적 측면을 결합한다.
• 주장을 뒷받침하기 위해 저자들은 2016년 3월부터 2026년 1월까지 공개된 AI-agent 및 LLM 안전 사고 52건, 허위 완료 사례 31건과 논쟁적 예시 1건, 공개 agent system 및 harness 12개, NeurIPS, ICML, ICLR 2023~2025 채택 논문 28,560편을 감사한다. 이는 런타임 harness와 evidence gate의 부족이라는 반복적 구조를 제시하는 공개 자료 기반의 위치 논문 근거이며, 개별 사례의 인과를 증명하는 실험은 아니다.
• 핵심 안전 단위는 모델 자체가 아니라 검증 가능한 증거를 포함한 trajectory다. 이를 위해 hash chain 기반 Agent Trajectory Schema와 task별 Evidence Chain을 정의하고, 예방 monitor와 evidence gate를 하나의 런타임 계약으로 조합하는 compositional gating 명제를 제시한다.

2 Why Model-Only Alignment Fails on Both Counts

저자들은 컴퓨터 보안과 실험 과학이 서로 다른 경로로 예방과 증거를 갖춘 런타임 계약에 도달했다고 비교한다. 컴퓨터 보안은 단일 신뢰 구성 요소의 정확성에 의존하는 접근에서 defense in depth와 배포 단계 제어로 이동했고, 실험 과학은 연구자의 평판이나 주장보다 절차, 기록, 측정값처럼 외부에서 확인할 수 있는 산출물을 수용 기준에 포함시켰다고 설명한다. 이 비유를 바탕으로 consequential action을 수행하는 agent는 모델 정확성만이 아니라 런타임 예방과 증거 검증을 함께 갖춰야 한다고 주장한다.

3 Mismatches Between Model Alignment and Agentic Deployment

저자들은 model-only alignment와 consequential deployment 사이에 모델 규모 확대로 해소할 수 없다고 보는 다섯 가지 불일치를 제시한다. 예방적 불일치는 통계적 proxy와 형식 명세의 차이, 제한된 학습 분포와 open-world deployment의 차이이며, 증거적 불일치는 검증 불가능한 내부 추론과 재생 가능한 trajectory의 차이, 그럴듯한 출력과 근거가 확인된 citation의 차이다. 다섯 번째 불일치는 모델 수준 alignment를 단일 방어층으로만 사용할 때 jailbreak, fine-tuning에 따른 안전성 저하, distribution shift에 대비할 다른 층이 없다는 점이다.

3.1 Preventive Mismatch

예방적 측면에서 RLHF 등의 learned reward는 실제 선호를 대신하는 통계적 proxy이므로 reward hacking과 specification gaming의 여지를 남긴다고 저자들은 설명한다. 또한 유한한 alignment 데이터는 새 공격과 배포 환경을 모두 포괄할 수 없으므로, tool whitelist, sandbox, resource limit, shell command 실행 전 human approval처럼 실행 가능한 규칙으로 행동을 제한해야 한다고 주장한다. 이 구분은 형식 규칙이 완전무결하다는 뜻이 아니라, 위반을 관찰하고 수정할 수 있는 방식으로 제약을 둔다는 뜻이다.

3.2 Evidential Mismatch

증거적 측면에서 모델의 완료 자기보고와 chain-of-thought는 모델 생성 내용의 정확성에 의존하는 soft evidence다. 반면 tool call, file write, command output을 기록한 tamper-evident trajectory와 citation lookup, developer test suite 재실행, commit hash, database snapshot diff는 agent 내부 상태를 신뢰하지 않고 deterministic verifier가 확인할 수 있는 hard evidence가 된다. 저자들은 완료 판단을 모델의 발화가 아니라 재생과 감사가 가능한 산출물의 검증으로 옮겨야 한다고 주장한다.

3.3 Combined Mismatch

결합 불일치는 model-level alignment가 jailbreak, fine-tuning에 따른 안전성 저하, distribution shift로 실패할 경우 단일 실패 지점이 될 수 있다는 주장이다. 저자들은 입력 필터링, tool gating, 출력 검사, sandboxing을 예방층으로 두고, trajectory monitoring, evidence-gated submission, human approval을 증거층으로 조합해야 한다고 제안한다. 한 층이 우회되어도 다른 예방층과 일관된 evidence chain을 통과해야 완료가 승인되도록 하는 것이 이 설계의 목적이다.

4 The Two Faces of the Safety Harness

Safety Harness의 예방적 측면은 작동 시점에 따라 preventive, detective, corrective, structural mechanism으로 분류된다. 입력 정제와 권한 게이트는 실행 전 행동을 선별하고, execution tracing과 이상 탐지는 실행 중 또는 후에 관찰하며, rollback과 human-in-the-loop escalation은 탐지 뒤 대응한다. sandbox, quota, network isolation, least-privilege default 같은 구조적 mechanism은 모델 행동과 무관하게 불변식을 강제하며, 저자들은 defense in depth, least privilege, fail-safe defaults, complete mediation, auditability를 설계 원칙으로 제시한다.

Agent Trajectory는 event type, timestamp, payload, hash로 구성된 유한 event sequence이며, 각 event hash는 이전 hash를 포함해 계산되어 변경을 드러내는 hash chain을 이룬다. task T의 evidence requirement 집합 ET를 모두 충족하는 hard-evidence event subsequence가 Evidence Chain이며, harness는 이를 구성하고 verifier가 해당 event를 확인할 수 있을 때만 완료를 승인한다. 예방 monitor의 관측 alphabet이 서로 분리되고 evidence-gated harness의 verifier 집합이 독립적인 경우 병렬 조합 검증은 다항 시간으로 가능하지만, monitor가 event를 공유하는 일반 경우에는 복잡도가 지수적으로 증가할 수 있다고 명시한다.

그림은 AI Agent가 Files, APIs, Shell 환경과 상호작용하는 경로에 Filter, Permission, Tools, Sandbox로 구성한 예방층을 배치하고, 실행 로그, hash, verifier, evidence를 evidence gate로 연결하는 구조를 보인다. 검증되지 않은 output은 완료로 승인되지 않으며, hard evidence를 갖춘 output만 Verified Output으로 전환된다.

5 Empirical Evidence

Table 1의 incident survey에서 저자들은 52건을 공개 기록에 기반한 반사실적 taxonomy로 분류했다. 그 결과 40건은 기능하는 harness layer가 완전히 예방할 수 있었던 사례, 11건은 부분 완화 가능 사례, 1건은 주로 internal-goal alignment 관련 사례로 코딩했다. 40+11+1=52건이며, 보충 자료에는 논쟁적인 public-report 행 1건이 표시되어 있으므로 저자들도 이 분류를 개별 사고의 인과적 증명이 아니라 반복적 구조의 증거로 한정한다.

Table 1과 Table 2에 따르면 공개 문서로 조사한 12개 system 및 harness 중 submission-like evidence gate를 문서화한 대상은 GitHub Copilot agent와 benchmark harness인 OSWorld baseline의 2개다. file diff는 12개 중 9개, tool output은 11개, structured log는 7개, test run은 5개에서 확인되지만, 많은 system은 최종 검증을 사용자에게 남긴다고 저자들은 해석한다. proceedings title-level audit은 alignment-tagged 논문 중 training-time intervention이 약 58~64%, deployment-time harness mechanism이 약 5~8%라고 추정하며, NeurIPS, ICML, ICLR 2023~2025 통합 범위에서 8–12×의 training/deployment 불균형을 보고한다. 이 비율은 제목 키워드, 하한 계수와 잘린 HTML을 보정한 범위 추정이므로 전수 full-text 분류값은 아니다.

표는 incident survey, false-completion audit, trajectory audit, proceedings audit의 표본 수와 핵심 결과를 나란히 제시한다. 52건 사고의 40건 완전 예방 가능, 11건 부분 완화 가능, 1건 주로 alignment 또는 internal-goal 관련 분류, 31+1건 허위 완료 감사, 12개 system 중 2개의 submission gate 문서화, 28,560편 proceedings의 통합 8–12× training/deployment 추정 불균형은 공개 자료를 저자가 코딩하거나 추정한 결과다.

표는 12개 공개 agent system과 harness를 structured log, test run, file diff, tool output, screenshot, submission gate의 여섯 차원에서 비교한다. Yes count 행에서 tool output은 11개, file diff는 9개, structured log는 7개, test run은 5개 system에 나타나고, submission gate는 GitHub Copilot agent와 OSWorld baseline의 2개에만 yes로 표시된다. OSWorld는 deployed product가 아니라 benchmark harness라는 표의 조건을 고려해야 한다.

6 Example: Code-Patch Submission

code-patch submission 예시에서 예방 harness는 네트워크 없는 Docker sandbox와 project-root 파일시스템 제한, 승인된 read, write, grep, pytest 도구 목록, rm, git push, curl의 human approval, 쓰기 범위 guard, credential-read-then-write monitor, alert 뒤 rollback 및 escalation을 둔다. 증거 계약은 content-addressed file diff, timestamped developer test suite 실행, exit code와 output, commit hash를 trajectory hash chain으로 연결한다. task schema ET는 exists(commit) && test_exit_code(commit) == 0 && diff(commit) is non-empty이며, 비어 있지 않은 diff와 해당 commit의 test exit code 0을 요구한다.

저자들은 모든 예방층이 우회되더라도 exfiltration patch가 일치하는 test 재실행과 추적을 포함한 evidence chain을 만들지 못하면 제출 단계에서 거부된다고 설명한다. 다만 계약은 goal 자체를 제약하지 않고, checkable acceptance standard가 없는 창의적 과제는 범위 밖이며, non-idempotent action은 human approval으로 넘기는 graceful degradation이 필요하다. 결론은 model alignment를 배제하는 대신 runtime harness가 대체한다는 주장이 아니라, 둘의 역할을 구분해 canonical trajectory schema, task별 ET, public failure reporting을 다음 연구 과제로 삼자는 제안이다.

부록

• 부록 A Limitations and Research Agenda는 계약이 행동과 제출을 제약할 뿐 goal이나 mesa-optimization을 다루지 않는다는 범위, 독립 verifier가 아닐 때 compositional verification의 비용이 증가한다는 조건, classifier 기반 구성 요소의 취약성을 설명한다. 이어 canonical Agent Trajectory Schema, task별 schema ET와 differential verifier, alignment가 손상된 경우를 포함하는 system-level benchmark, tamper-evident logging과 failure reporting을 연구 과제로 제안한다.

짧은 생각

이 논문의 설득력은 예방과 증거를 분리하면서 제출 승인 지점에서 결합한 설계에 있다. sandbox나 permission gate만으로는 수행 결과가 요구사항을 충족했는지 판단하기 어렵고, test 재실행만으로는 파괴적 부작용을 사전에 막지 못하므로 두 기능은 서로 다른 책임을 가진다. 다만 flaky test도 잘못된 gate를 만들 수 있다고 저자들이 인정하므로, 실제 적용에서는 같은 code-patch task에서 단일 test gate, differential verifier, human approval을 조합했을 때 false acceptance와 불필요한 거부가 어떻게 변하는지 확인해야 계약의 실용적 강도를 판단할 수 있다.