기술 요약: 코딩 에이전트의 잔류 권한 (Lingering Authority)

문제 정의: 잔류 권한 (Lingering Authority)

본 논문은 코딩 에이전트에서 발생하는 **잔류 권한(lingering authority)**이라 불리는 특정 보안 격차를 식별한다. 코딩 에이전트는 특정 작업 전체에 대해 광범위한 도구 접근 권한을 부여받는 경우가 많은데, 이는 특정 리소스나 효과가 단 하나의 하위 목표(subgoal)에만 필요할 때도 마찬가지이다. 핵심 문제는 시간적(temporal)이다. 하나의 하위 목표를 위해 정당화된 권한이 해당 하위 목표가 종료된 후에도 플래너의 인터페이스에 노출된 채로 남아 있다. 기존의 방어 기제들은 유해한 콘텐츠, 도구 신뢰성, 실행 시점의 체크 등을 다루지만, 정당성이 더 이상 존재하지 않는 기능들이 플래너 인터페이스 자체에 여전히 노출되어 있는 상태를 방치하는 경우가 많다. 만약 광범위한 읽기 옵션이 하위 목표가 끝난 후에도 플래너에게 계속 보인다면, 모델은 이를 바탕으로 계획을 계속 세울 수 있으며, 이는 임시 역량이 그 정당성을 넘어 지속되는 보안 상태를 초래한다. 본 논문은 노출된 인터페이스가 런타임 도달 가능성(reachability)이나 샌드박스 경계와는 구별되는 보안 상태의 일부라고 주장한다.

방법론: PORTICO 레퍼런스 모니터

저자들은 코딩 에이전트를 위한 **유한한 역량 수명(bounded capability lifetimes)**을 강제하도록 설계된 레퍼런스 모니터인 PORTICO를 소개한다. PORTICO는 고정된 호스트 격리 모델 하에서 작동하며, 명시적인 작업 계약(task contract)과 타입이 지정된 도구 카탈로그(typed tool catalog)에 의존한다.

핵심 메커니즘

PORTICO는 작업 계약을 다음 네 가지 구성 요소로 컴파일한다:

1. 초기 엔벨로프 ($E_0$): 작업 시작 시 노출되는 역량의 집합.
2. 부여 규칙 ($\Gamma$): 명시적 요청을 통해 임시 권한을 확장하는 방법을 정의하는 규칙.
3. 종료 규칙 ($\Lambda$): 임시 권한의 철회를 트리거하는 조건(예: 테스트 통과, 단계 종료, 하위 목표 완료).
4. 글로벌 거부 규칙 ($G$): 금지된 네트워크 호스트 또는 자격 증명 파일 접근과 같은 불변 조건.

요청–부여–호출 라이프사이클 (Request–Grant–Invoke Lifecycle)

PORTICO는 확장을 **불투명하고 에포크 기반인 핸들(opaque, epoch-bound handles)**로 구체화한다.

• 요청 (Request): 플래너는 선언된 규칙에 따라 권한을 요청할 수 있지만, 새로운 권한을 스스로 생성할 수는 없다.
• 부여 (Grant): 규칙이 일치하면, 모니터는 특정 리소스/효과/단계에 대한 핸들을 발행한다. 이 핸들은 다음 플래너 인터페이스에 추가된다.
• 호출 (Invoke): 유효하고 살아있는 핸들이 존재하는 경우에만 실행이 허용된다.
• 종료 (Closure): 종료 이벤트(예: 신뢰할 수 있는 테스트 결과)가 발생하면, 모니터는 플래너 인터페이스에서 해당 핸들을 제거한다. 이후 유효하지 않은 핸들을 사용하려는 시도는 부수 효과(side effect)가 발생하기 전에 거부된다.

결정적으로, 철회(revocation)는 인터페이스에서 권한을 제거하지만, 컨텍스트(예: 대화 내의 파일 이름)는 그대로 유지한다. 플시에 따라 플래너는 새로운 부여 없이 해당 리소스를 위한 도구를 더 이상 선택할 수 없게 된다.

주요 기여

본 논문의 주요 기여는 세 가지이다:

1. 무효 사용 방지(No-Stale-Use) 정의: 부여된 권한이 종료된 후에는 반드시 플래너 인터페이스에서 사라져야 하며, 실행 시점에도 무효해야 한다는 요구 사항을 정의한다.
2. 정형화 및 구현: 요청–부여–호출 프로토콜을 중심으로 노출 최소화(exposure minimality), 정당한 확장(justified expansion), **권한 종료(authority closure)**를 정형화한다. 이는 PORTICO에서 에포크 기반 핸들을 사용하여 구현된다.
3. 실증적 평가: 제어된 피스처(fixture)와 고정된 실제 저장소(pinned real repositories)를 사용하여 Bounded Lifetimes를 평가하며, 비철회 설계에 비해 사후 종료 시의 오래된 역량 가용성을 줄임을 입증한다.

실험 결과

평가는 세 가지 제어된 피스처 세트(A–C)와 한 개의 실제 저장소 세트(D)를 사용하여, PORTICO를 Full Access, Static Allowlist, Coarse Sandbox와 같은 베이스라인 및 Non-Revoking, All-Visible Same-Policy와 같은 특정 비교 대상들과 비교한다.

주요 결과

• 최소화 (RQ1): PORTICO 변형 모델은 Suite A에서 정책 위반 및 "폭발 반경"(도달한 민감한 리소스)을 0.00으로 낮추는 반면, Full Access와 Static Allowlist는 각각 상당한 위반율(1.00 및 0.82)을 보인다.
• 정당한 확장 (RQ2): PORTICO Core(초기 엔벨로프만 포함)는 안전하지만 취약하여, 경계 확장이 필요한 많은 작업에 실패한다(Suite B에서 성공률 0.21). PORTICO Full은 경계 작업을 수행하는 정당한 작업을 복구하여, Suite B에서 0.87의 성공률을 달고 있으면서도 **1.00의 범위 준수(scope compliance)**와 0.00의 위반을 유지한다.
• 종료 (RQ3): 이것이 본 논문의 주요 차별점이다. Non-Revoking Comparator(동일한 시점에 동일한 부여를 받지만 절대 제거하지 않는 모델)는 작업 성공 및 종료 전 결정 사항에서 PORTICO와 일치하는 모습을 보인다. 그러나 사후 재읽기(post-closure re-reads) 시:
  • PORTICO Full: 10/10의 사후 재사용 시도를 거부한다.
  • Non-Revoking Comparator: 10/10의 사후 재사용 시도를 허용한다.
  • 오래된 효과 감사(Stale-Effect Audit): 파일 쓰기, git 변형, 네트워크 이그레스(egress)를 포함하는 결정론적 테스트에서, PORTICO는 0/6의 금지된 효과를 실행한 반면, Non-Revoking Comparator는 6/6을 실행했다.
• 인터페이스 너비 (RQ3): All-Visible Same-Policy Comparator(광범위한 인터페이스, 동일한 실행 정책)는 PORTICO와 실행된 금지된 효과 수(0/20)는 동일하지만, 훨씬 더 많은 **차단된 제안(blocked proposals)**을 생성한다(84 vs. 67). 이는 실행이 결국 거부되더라도 인터페이스가 넓으면 계획 압박(planning pressure)이 증가함을 나타낸다.
• 실제 저장소 (RQ4): 고정된 실제 Python 저장소(Flask, Requests 등)에서 PORTICO Full은 임시 부여를 성공적으로 구현하고 종료를 강제하며, 14개의 계약 전반에 걸쳐 범위 준수와 제로 위반을 유지한다.

의의 및 주장

본 논문은 PORTICO가 권한의 "수명(lifetime)"을 별개의 보안 변수로 성공적으로 격리한다고 주장한다. 핵심 발견은, 실행 정책과 부여 타이밍이 비철회 시스템과 동일하더라도, 철회가 강제되지 않으면 임시 역량이 종료 후에도 여전히 사용 가능한 상태로 남을 수 있다는 점이다.

저자들은 PORTICO를 샌드박싱이나 콘텐츠 방어의 대체물이 아니라, 임시 역량을 명시적이고, 유한하며, 감사 가능하게 만드는 보완적인 계층으로 위치시킨다. 의의는 잔류 권한을 방지하기 위해서는 철회가 필수적임을 입증했다는 데 있다.

본 논문은 다음과 같은 범위의 한계를 인정하며 겸허한 입장을 취한다:

• 신뢰할 수 있는 타입 지정 도구 카탈로그와 **매개된 실행(mediated execution)**을 가정한다. 즉, 매개되지 않은 쉘 명령이나 샌드박스 우회를 방어한다고 주장하지 않는다.
• 계약의 품질이 배포 시의 입력값임을 인정한다. 부실한 계약은 과소 부여(작업 차단) 또는 과다 부여(리스크 노출)를 초래할 수 있다.
• 유틸리티 비용을 언급한다. PORTICO Full은 엄격한 범위 제어를 위해 일부 원시 완료율을 희생하며, 이는 숨겨진 과잉 성공이 아닌 눈에 보이는 "안전한 미완성(safe incompleteness)"을 초라한다.

궁극적으로 이 연구는 코딩 에이전트에게 있어 플래너 인터페이스 자체가 동적이어야 함을 주장한다. 즉, 정당성이 만료됨에 따라 축소되는 구조여야 하며, 정적인 광범위한 도구 메뉴로 남아 있어서는 안 된다.