기술 요약: 소버린 실행 브로커 (Sovereign Execution Brokers)

문제 정의

대규모 언어 모델(LLM) 기반의 자율 에이전트가 수동적인 분석 도구에서 능동적인 운영 플래너(예: 오토 스케일링, 컨테이너 배포, 보안 그룹 관리 등 생산 인프라 워크플로 통합)로 전환됨에 따라, 이들에게 직접적인 상시 접근 권한(standing access credentials)을 부여하는 것은 심각한 보안 리스크를 초را합니다. 단 한 번의 환각(hallucination)이나 적대적 프롬프트 주입(adversarial prompt injection)만으로도 승인되지 않은 파괴적인 인프라 변형이 발생할 수 있기 때문입니다.

기존 아키텍처는 제안된 동작을 검증하고 암호화된 서명 인증서($\Omega$)를 발행하는 주권 보증 경계(Sovereign Assurance Boundary, SAB)와 같은 승인 게이트를 도입하여 이를 완화하려고 시도합니다. 그러나 승인 인증서만으로는 강제 집행에 불면 충분합니다. 실행을 위한 런타임 메커니즘이 인증서를 반드시 요구하도록 설계되지 않는다면, 에이전트나 탈취된 래퍼(wrapper)는 상시 권한을 사용하여 승인 게이트를 완전히 우회할 수 있습니다. 또한, 승인 프로세스를 준수하더라도 제안의 승인 시점과 실제 실행 시점 사이의 시간 간극은 시스템 상태가 변하거나 보안 정책이 변경되는 취약점(Time-of-Check to Time-of-Use, TOCTOU)을 생성합니다.

방법론: 소버린 실행 브로커 (Sovereign Execution Broker, SEB)

본 논문은 인증된 자율 제안과 실제 인프라 변형 사이의 간극을 메우기 위해 설계된 런타임 강제 집행 경계인 **소버린 실행 브로커(SEB)**를 소개합니다. 핵심 아키텍처 원칙은 제안(proposal), 승인(admission), 그리고 **실행(execution)**의 분리입니다.

핵심 아키텍처

1. 제로 상시 권한 (Zero Standing Privileges): 의도된 배포 환경에서 어떤 에이전트 런타임이나 래퍼도 생산 환경 변형을 위한 상시 권한을 보유하지 않습니다. 모든 자율 변형 요청은 반드시 SEB를 통과해야 합니다.
2. 인증서 검증 파이프라인: SEB는 SAB 인증서($\Omega$)와 실행 요청($req$)을 소비하는 게이트키퍼 역할을 수행합니다. 실행 전, SEB는 다음 사항을 확인하는 정식 검증 파이프라인을 실행합니다:
   • 서명 ($\Phi_{sig}$): SAB 서명의 유효성.
   • 계약 일치 ($\Phi_{match}$): 요청 파라미터, 대상, 동작이 인증된 계약 $C$와 정확히 일치하는지 확인.
   • 유효 기간 ($\Phi_{time}$): 요청이 인증서의 유효 기간 내에 있는지 확인.
   • 정책 및 폐기 ($\Phi_{policy}, \Phi_{rev}$): 인증서가 활성 정책 버전과 일치하는지, 그리고 글로벌 에포크 카운터를 통해 폐기되지 않았는지 확인.
   • 드리프트 탐지 ($\Phi_{drift}$): 승인 시 캡처된 증거 상태($E_{admit}$)와 실시간 대상 상태($St$)를 비교하여 TOCTOU 변화를 탐지.
   • 재생 방지 ($\Phi_{replay}$): 인증서 논스(nonce)가 이전에 사용된 적이 없는지 확인.
3. 범위 제한 실행 ID (Scoped Execution Identity): 검증에 성공하면, SEB는 자신의 마스터 권한으로 실행하는 대신, 인증된 계약, 대상 리소스 및 유효 기간에 엄격하게 결합된 단기 범위 제한 실행 ID($ID_{exec}$)를 발행하는 토큰 브로커 역할을 합니다.
4. 강제 집행 패턴: 우회를 방지하기 위해, 대상 인프라(예: AWS, Kubernetes)는 브로커 또는 브로커가 발행한 세션에서 기원하지 않은 모든 변형 요청을 거부하도록 구성되어야 합니다. 이는 서비스 제어 정책(SCP), IAM 권한 경계(permission boundaries), 그리고 검증된 admission webhook을 통해 달성됩니다.
5. 감사 가능성: 모든 검증 결정(거절 또는 재승인)과 실행 결과는 서명된 추가 불가능한(append-only) 원장에 기록되어, 해당 동작을 원래의 인증서와 연결하는 암호학적 증거를 제공합니다.

주요 기여

본 논문은 네 가지 주요 기여를 합니다:

1. 브로커 강제 자율성 (Broker-Enforced Autonomy): 인증된 제안과 실제 변형 사이의 강제 집행 간극을 식별하고, 에이전트가 상시 권한을 보유하는 것을 방지하는 런타임 경계로서 SEB를 정의했습니다.
2. 인증서 검증 실행 모델: 서명, 계약 일치, 유효성, 정책, 폐기, 드리프트 및 재생 검사를 위한 술어(predicate)를 상세히 기술하며 브로커 인터페이스 $Execute(\Omega, req, St, Platform) \rightarrow D | O$를 정형화했습니다.
3. 범위 제한 ID 및 실행 전 폐기: 권한을 실행 시점에만 발행하고, 계약에 국한시키며, 실행 직전에 폐기 검사를 수행하는 최소 권한 모델을 도입했습니다.
4. 프로토타입 구현 및 평가: AWS STS 및 Kubernetes TokenRequest용 어댑터를 갖춘 Go 기반 프로토타입(약 4,200행의 코드)을 구현하여 필수 변형 경로로 배치하고 실제 워크로드 하에서 평가했습니다.

실험 결과

프로토타입은 지연 시간, 처리량 및 결함 주입 하에서의 보안성을 측정하기 위해 AWS 및 Kubernetes 클러스터(Amazon EKS)에서 평가되었습니다.

• 지연 시간 오버헤드:
  • Kubernetes: 브로커는 변형 작업에 약 28.2 ms(p50)의 오버헤드를 추가합니다. 주요 병목 구간은 실시간 드리프트 체크(42.9%)와 자격 증명 발행(42.9%)입니다.
  • AWS: 오버헤드가 더 높으며, 약 136.9 ms(p50)입니다. 이는 AWS STS 자격 증명 발행과 드리프트 체크(DescribeSecurityGroups API 호출)에 의해 지배됩니다.
  • 비교: Direct IAM 및 감사 전용(Audit-Only) 로깅은 오버헤드가 거의 없지만, SEB의 보안 보장을 제공하지 못합니다. SEB의 오버헤드는 고위험/저빈도 변형(예: 방화벽 변경, 오토 스케일링)에는 관리 가능한 수준이지만, 마이크로초 단위의 제어 루프에는 부적합한 것으로 나타났습니다.
• 폐기 전파 (Revocation Propagation): 폐기 에포크에 대한 5초 폴링 간격을 사용할 때, 시스템은 에포크 진전부터 100% 요청 거부에 이르기까지 최대 5.2초의 전파 지연을 달성합니다.
• 보안 및 결함 허용:
  • 브로커 우회, 오래된 인증서 재생, 요청-인증서 불일치, 네트워크 파티션 등의 위협을 포함한 1,000개의 주입된 테스트 케이스에서, SEB는 승인되지 않거나 유효하지 않은 요청에 대해 100% 거절률을 달s성했습니다.
  • Fail-Closed 의미론: 네트워크 파티션이나 서비스 장애 발생 시, 브로커는 안전하지 않은 실행을 방지하기 위해 요청을 거부하는 기본 동작을 취합니다.
  • 크래시 복구: 시스템은 멱등성 토큰을 사용하여 브로커 크래시를 성공적으로 처리함으로써 중복 변형을 방지하고 상태 일관성을 보장했습니다.

의의 및 주장

본 논문은 SEB가 전통적인 IAM 및 정책 엔진이 제공할 수 없는 데 필요한 런타임 강제 집행 계층을 제공한다고 주장합니다.

• ID에서 동작으로의 전환: '누가 무엇을 할 수 있는가'를 승인하는 IAM과 달리, SEB는 '현재 시스템 증거 하에서 이 특정, 인증된 동작'을 승인합니다.
• TOCTOU 완화: 실행 직전에 실시간 상태 드리프트와 폐기 에포크를 확인함으로써, SEB는 승인과 변형 사이의 취약 시간 창을 닫습니다.
• 강제 집행 정리 (Enforcement Theorem): 본 논문은 특정 배포 가정(에이전트에 대한 상시 권한이 없고, 대상 API가 브로커 이외의 ID를 거부함) 하에서, 신뢰할 수 없는 에이전트는 유효하고, 만료되지 않았으며, 폐기되지 않고, 재생되지 않은 인증서와 실행 가능한 범위를 갖추지 않는 한 생산 상태 변형을 일으킬 수 없다는 것을 명시하는 정식 증명(정리 1)을 제시합니다.

저자들은 SEB가 지연 시간 오버헤드를 발생시키지만, 인증된 권한을 단기적이고 철회 가능하며 감사 가능한 런타임 역량으로 변환함으로써, 보안 사고의 비용이 지연 비용보다 큰 생산 환경에서 자율 에이전트를 위한 실행 가능한 솔루션이 된다고 결론짓습니다.