배경 및 맥락
agent가 실제 운영 환경에서 가치를 내기 시작하면 결국 로그 조회, 설정 확인, 파일 읽기, 서비스 재시작 같은 시스템 작업으로 내려가게 된다. 문제는 기존 스크립트 실행 환경이 보통 실행 주체의 권한을 그대로 상속한다는 점이다. 사람이 짠 스크립트도 위험한데, 실행 시점에 생성되는 agent 스크립트는 hallucination과 prompt injection 때문에 더 위험하다.
그래서 최근 agent 보안의 핵심 질문은 '모델을 얼마나 잘 막는가'보다 '모델이 무슨 코드를 쓰더라도 host가 어디까지 허용할 것인가'로 바뀌고 있다. Rex는 이 질문에 대해 runtime authorization을 별도 정책 계층으로 분리하는 답을 제시한다.
핵심 내용
AWS Open Source Blog에 따르면 Rex는 Rhai 기반 스크립트 런타임이며, 엔진 자체는 host에 대한 내장 접근 권한을 갖지 않는다. 시스템에 닿을 수 있는 경로는 Rex가 제공하는 purpose-built SDK operation뿐이고, 각 operation은 실행 전에 Cedar policy 평가를 거친다.
예를 들어 파일 생성과 쓰기 권한이 policy에 없으면 동일한 스크립트라도 ACCESS_DENIED_EXCEPTION에 해당하는 에러를 받고 종료된다. 중요한 점은 스크립트를 수정하지 않아도 policy만 바꾸면 허용 범위를 조정할 수 있다는 것이다. AWS는 이를 통해 agent가 로그 읽기, 구성 점검, 서비스 재시작 같은 운영 작업을 수행하되, host owner가 허용한 action만 실행하도록 설계했다.
경쟁 구도 / 비교
일반적인 sandbox는 agent의 실행 환경을 좁히는 데 집중하지만, 그 자체로는 '어떤 host action이 비즈니스상 허용되는가'를 명시하지 못하는 경우가 많다. 반면 Rex는 권한을 코드가 아니라 정책에 두기 때문에, agent가 더 자율적으로 움직여도 안전경계는 host owner가 유지할 수 있다.
이는 agent runtime이 단순 컨테이너 격리에서 policy-governed operations layer로 진화하고 있음을 보여준다. 앞으로 agent platform 경쟁에서도 모델 품질만큼 execution policy, auditability, denial semantics가 중요한 차별점이 될 가능성이 크다.
의미
기술적으로는 agent 보안 아키텍처가 prompt filtering 중심에서 runtime authorization 중심으로 이동하는 신호다. 운영 환경에서 진짜 중요한 것은 agent가 좋은 의도를 가졌는지가 아니라, 잘못된 스크립트를 써도 시스템이 안전하게 거부할 수 있는가다.
실무적으로는 SRE와 플랫폼팀이 agent 도입 시 OS 명령 allowlist만으로 안심하면 안 된다. 어떤 principal이 어떤 action을 어떤 resource에 대해 수행할 수 있는지 정책으로 분리하고, 실패 시 agent가 그 신호를 이해해 재시도하거나 다른 경로를 찾게 만드는 실행 계약이 필요하다.