AI 에이전트 실행 제어: 정의와 AI 네이티브 PAM에서 필요한 이유

AI 에이전트의 제약은 프롬프트나 설정에 명시하는 데 그칠 수도 있고, 실제 실행 경로에서 강제할 수도 있습니다. 실행 제어는 후자입니다.

2026년 7월 30일 Anthropic은, Claude가 인터넷에 접근할 수 있었던 평가 실행 141,006건을 검토한 결과 사이버 역량 평가 도중 모델이 실제 제3자 조직에 도달한 사례가 6건의 실행에 걸쳐 3건 있었다고 밝혔습니다. 한 모델은 실제 기업의 프로덕션 인프라에 도달해 자격증명과 데이터베이스 행 수백 건을 빼냈고, 지금이 시뮬레이션이 아닐 가능성이 높다고 판단한 뒤에도 작업을 이어갔습니다. 다른 모델은 PyPI에 패키지를 게시했으며, 이 패키지는 실제 시스템 15대에서 실행됐습니다.

평가 프롬프트에는 모델이 인터넷에 접근할 수 없다고 적혀 있었지만, 모델이 실행된 머신은 온라인 상태였습니다. Anthropic은 평가 파트너와의 소통 착오로 환경이 잘못 설정됐다고 설명합니다. 아웃바운드 격리(egress isolation)를 적용했다면 이번 사고의 경로는 차단할 수 있었습니다. 그러나 에이전트가 업무상 필요한 프로덕션 권한으로 세션 목적에서 벗어난 동작을 하는 문제까지 해결되지는 않습니다.

이번에 공개된 사건들은 익스플로잇 사례였습니다. 이 글이 다루는 사례와는 다릅니다. 취약점이 악용됐고, 패키지에는 함정이 심어져 있었고, 노출된 디버그 페이지를 통해 SQL 인젝션이 들어갔습니다. 이 글이 다루는 사례는 더 좁고 더 흔합니다. 아무것도 뚫고 들어오지 않습니다. 호출자는 정상적으로 인증받고, 명령은 실행이 허용된 명령이며, 그 경로 어디에도 이 동작을 그 세션의 목적과 비교하는 지점이 없습니다.

AI 에이전트에 걸리는 모든 제약은 두 종류 중 하나입니다. 선언된 제약은 프롬프트, 설정, 도구 설명, 또는 에이전트가 스스로 참조하는 분류기 안에 존재합니다. 강제된 제약은 경로 위, 에이전트 바깥에 자리하며 동작이 실행되기 전에 판단에 참여합니다. 실행 제어는 두 번째 종류입니다.

이 레이어를 위해 별도의 예산 항목을 만들 필요는 없습니다. 기업은 이미 권한 있는 접근 관리(PAM)에 예산을 쓰고 있으며, AI 네이티브 PAM도 그 범주에서 검토하고 구매합니다. 실행 제어는 이 카테고리 안에서 판단을 담당하는 레이어이지, 독립된 제품 카테고리가 아닙니다.

AI 에이전트 실행 제어란

AI 에이전트 실행 제어는 셸 명령, 도구 호출, 권한이 필요한 작업처럼 에이전트가 취하려는 특정 동작을 목표 시스템에 도달하기 직전에 평가하는 레이어입니다. 정책뿐 아니라 세션이 선언한 목적과도 대조해 허용, 차단, 사람에게 에스컬레이션 중 하나를 결정합니다. 정책 대조만으로는 충분하지 않습니다. 아래에서 다루는 벤더의 공개 설명 중에는 특정 동작이 세션 목적에 맞는지를 실행 전에 판정하는 사례가 없습니다.

실행 제어를 기존 구성 요소의 설정이 아닌 별도 레이어로 구분하는 속성은 네 가지입니다.

• 주체가 아니라 동작을 판단합니다. 접근 제어는 에이전트가 일반적으로 할 수 있는 일을 정합니다. 실행 제어는 특정 입력으로 만들어진 명령이 현재 세션의 범위와 맥락에서 지금 실행돼도 되는지를 판단합니다.
• 동작이 반영되기 전에 판단합니다. 판단 지점은 인증 이후, 실행 이전입니다. 그보다 늦으면 기록일 뿐입니다.
• 에이전트 바깥에 존재합니다. 정책, 판단, 감사 기록은 에이전트가 수정하거나 끌 수 없는 통제 플레인에 자리합니다.
• 동작을 정해진 규칙이 아니라 선언된 목적과 대조합니다. 패턴이든 허용 목록이든 dzdo 같은 매개자든, 이런 것들은 명령을 세션이 생기기 전에 작성된 규칙과 대조할 뿐입니다. 이 동작이 이 세션이 열린 목적에 맞는지는 묻지 않습니다.

이 자리를 놓고 여러 이름이 경쟁합니다. Gartner가 2026년 2월 처음 발행한 Market Guide for Guardian Agents는 런타임 검사와 집행(enforcement)을 세 가지 필수 핵심 역량 중 하나로 꼽습니다(The Hacker News 보도 기준). Delinea와 Neo의 최근 발표를 다룬 업계 매체는 이를 런타임 인가(runtime authorization)라고 부릅니다. 도구 호출, API 요청, 권한 있는 작업을 실행 전에 평가한다는 뜻입니다. 7월에 에이전틱 소프트웨어용 실시간 통제 레이어로 출시한 Neo는 자사 제품을 "Agentic Software Control"이라 부르고, Delinea는 런타임 인가와 "continuous identity authorization"을 함께 씁니다(Delinea 자체의 StrongDM 인수 발표 기준). 우리는 이를 실행 제어라고 부릅니다. 흥미로운 실패는 호출자가 완전히 허가받았는데도 동작이 여전히 잘못된 경우이기 때문입니다.

AI 네이티브 PAM에 새로운 실행 레이어가 필요한 이유

요약: 기존 PAM 통제는 명령을 검사하더라도 세션이 시작되기 전에 작성된 규칙과 대조합니다. 공개된 기능 중 실행 시점에 가장 가까운 Delinea의 런타임 인가는 동작을 실행 전에 평가하고 자격증명의 범위를 해당 작업으로 제한합니다. 그러나 이 글에서 언급한 벤더 중 특정 명령이 세션의 선언 목적에 맞는지를 실행 전에 판정한다고 밝힌 곳은 없습니다.

레거시 PAM도 명령을 판단할 수 있습니다. CyberArk의 PSMP는 SSH 세션에서 입력된 명령을 허용/차단 목록과 대조해 걸러냅니다(CyberArk 자체 문서 기준). 지금은 Delinea 소속인 StrongDM은 파싱된 SQL을 문(statement) 단위 정책과 대조합니다(StrongDM 자체 블로그 기준). Delinea는 sudo에 해당하는 dzdo를 제공하며, 이는 Server Suite 에이전트를 통해 권한 있는 명령을 실행합니다(Delinea 자체 문서 기준). 앞서 인용한 같은 업계 보도에 따르면 Delinea의 플랫폼은 에이전트가 실행하기 전에 SSH 명령, 데이터베이스 쿼리, Kubernetes 상호작용을 분석할 수 있고, 그 결과는 이 글이 위에서 정의한 허용·차단·에스컬레이션 형태와 같습니다.

이 메커니즘은 모두 명령을 미리 정해 둔 규칙과 대조합니다. 패턴, 허용 목록, 파싱된 문에 적용하는 프로토콜 정책처럼 세션의 목적이 정해지기 전에 작성된 규칙입니다. 키보드 앞에 사람이 있을 때는 이 방식이 통합니다. 인증서를 갱신하려고 셸을 연 엔지니어는 고객 테이블을 통째로 빼내는 것이 자신의 일이 아님을 압니다.

에이전트는 그 절반을 없애 버립니다. 에이전트는 이를 검토하는 누구보다 빠르게 움직이고, 세션이 무엇을 위한 것이었는지에 대한 지속적인 감각이 없으며, 5분 전에 읽은 내용에 의해 방향이 바뀔 수 있습니다. 에이전트가 만들어 낸 명령 하나하나는 규칙 집합 안에 들어맞으면서도 그 작업에는 여전히 틀릴 수 있습니다. 세션은 잘못됐는데 명령 자체는 허용된 경우입니다. Kiteworks의 2026년 리스크 전망에 따르면 보안·IT·리스크 리더 225명 중 63%가 에이전트의 목적 제한을 강제할 수 없었습니다.

빠진 것은 명령과 목적의 대조입니다. 특정 작업을 위해 연 세션에서 그 작업과 무관한 동작이 실행되는지를 판단해야 합니다. 아이덴티티나 정책 문서로는 이 대조를 할 수 없고, 목적이 정해지기 전에 고정된 패턴 필터도 마찬가지입니다. 규칙을 늘리는 대신, 실행 전에 명령과 세션 목적을 함께 평가하는 레이어가 필요합니다.

에이전트가 스스로 확인하는 제약은 경계가 아닙니다

요약: 제약을 받는 대상이 스스로 그 제약을 운영하면 그것은 선호일 뿐, 경계가 아닙니다. 분류기를 더 잘 만들어도 이 구조는 바뀌지 않고, 같은 에이전트는 자기 자신을 확실히 종료시키지도 못합니다.

AI Now Institute의 Friendly Fire 브리프는 저장소 문서 안에 미끼용 소스 파일, 악성 바이너리, 주입된 지시문을 심어 두고 주요 코딩 에이전트 두 개를 그 저장소에 붙였습니다. 두 에이전트 모두 경고도 없이, 승인 절차도 거치지 않고 공격자의 코드를 실행했습니다. 이 공격은 선택적으로 켜는 자율 모드에 의존합니다. 이 모드는 모델 쪽 분류기가 어떤 명령을 사람 개입 없이 실행해도 안전한지를 판단합니다. 패키지에 숨겨진 지시문이 있는지 직접 물었을 때 두 모델 모두 없다고 답했습니다. 일부 실행에서는 바이너리가 명시된 출처와 일치하지 않는다는 것을 알아채고도 그대로 실행했습니다.

이것은 제품의 결함이 아니라 구조의 문제로 읽어야 합니다. 제약을 받는 대상이 스스로 그 제약을 운영하면, 그것은 선호일 뿐입니다. 분류기를 더 잘 만든다고 이 구조가 바뀌지는 않습니다. 주입된 지시문을 놓치는 분류기든 잡아내는 분류기든, 둘 다 에이전트가 자기 자신에게 복종할지를 스스로 결정하는 구조이기 때문입니다. 같은 Kiteworks 설문에서 60%는 런타임에 오작동하는 에이전트를 확실히 종료시킬 수 없었습니다.

MCP 스펙이 표준화한 것과 구현자에게 남긴 것

2026년 7월 28일 공개된 MCP 스펙에는 RFC 9207 발급자(issuer) 검증, 발급자에 묶인 클라이언트 자격증명, 정식 확장으로 승격된 Tasks가 포함됐습니다. 동적 클라이언트 등록(DCR)은 Client ID Metadata Documents 도입과 함께 사용 중단이 권고됐지만, 하위 호환을 위해 계속 동작합니다. Multi Round-Trip Requests도 추가돼 서버가 resultType: 'input_required'를 반환하고 도구 호출 중간에 확인을 요청할 수 있습니다.

MRTR은 확인을 요청하는 절차를 표준화합니다. 스펙은 에이전트가 요청하는 방식과 신원을 밝히는 방법을 정하지만, 명령의 실행 허용 여부는 구현자가 결정해야 합니다. Akamai의 보안 리서치는 이번 발표를 두고, 과거에는 프로토콜이 직접 내리던 결정을 서버 개발자와 플랫폼 운영자에게 넘긴 것으로 해석합니다.

프로토콜이 요청 절차를 표준화해도, 실행 여부를 판단하는 통제는 운영 환경에 구현해야 합니다.

'매번 사람에게 물어보기'가 답이 아닌 이유

요약: 모든 것을 묻는 통제는 사람이 읽기를 그만두도록 훈련시키고, 아무것도 묻지 않는 통제는 모니터링에 불과합니다. 작동하는 형태는 등급을 나누는 것입니다. 규칙이 명백한 경우를 처리하고, 판단이 애매한 구간을 맡고, 진짜 위험한 동작만 사람에게 갑니다.

가장 뻔한 대응은 모든 동작 앞에 사람을 세워 두는 것입니다. 실무자들은 이게 어디로 흘러가는지 이미 설명했습니다. 첫 번째 승인 요청은 안심시켜 주지만, 쉰 번째쯤 되면 배경 소음이 되고, 개발자는 반사적으로 승인 버튼을 누르기 시작합니다. 모두가 그냥 클릭하고 지나가는 승인 창은 실체 없는 안전감입니다. 탈출구도 이미 문서화돼 있습니다. Anthropic의 dev-container 문서는 --dangerously-skip-permissions의 범위를 루트 권한이 없는 컨테이너로 한정하고, 네트워크 아웃바운드 제한과 함께 쓰라고 안내합니다. 이것은 동작에 대한 판단이 아니라 환경을 둘러싼 경계입니다.

그래서 실패 양상이 설계를 결정합니다. 모든 것을 묻는 통제는 사람이 읽기를 그만두도록 훈련시키고, 아무것도 묻지 않는 통제는 모니터링에 불과합니다. 작동하는 형태는 등급을 나누는 방식입니다. 명백히 괜찮거나 명백히 금지된 것은 결정론적 규칙이 처리하고, 판단이 필요한 애매한 중간 구간은 판단 로직이 맡고, 진짜로 위험한 동작만 사람에게 갑니다. 세션 전체가 아니라 그 동작 하나만 붙잡아 두는 것입니다.

실행 제어가 아닌 것

요약: 아이덴티티, 정책, 정렬과 가드레일, 관측 가능성, 샌드박싱은 모두 실재하는 통제이지만, 이 레이어가 던지는 질문과는 다른 질문에 답합니다. 이 중 어느 것도 특정 동작이 그 세션이 선언한 목적과 일치하는지는 판단하지 않습니다.

이 목록에 있는 것들은 모두 실재하는 통제입니다. 다만 이 레이어가 던지는 질문에는 답하지 못합니다. 관찰이 통제로 오인되는 경우가 가장 많습니다. Gravitee의 State of AI Agent Security 2026 조사(벤더가 발행한 설문)에 따르면 시니어 기술 리더의 91.8%가 자사의 AI 에이전트 가시성에 확신을 갖고 있다고 답했지만, 실제로 모니터링되는 에이전트는 절반 정도에 그쳤습니다. OODA Loop가 정리한 바에 따르면 Arkose Labs의 2026년 Agentic AI Security Report(역시 벤더가 발행)는, 보안 리더의 97%가 앞으로 열두 달 안에 에이전트가 원인이 된 심각한 사고를 예상한다고 답했지만 보안 예산 중 이 위험을 다루는 비율은 6%에 그쳤다고 밝혔습니다.

이 다섯 레이어만으로는 각기 다른 판단 공백이 남습니다. Gartner의 첫 가디언 에이전트 Market Guide는 런타임 검사와 집행, AI 가시성과 추적성, 지속적 보증과 평가를 필수 역량으로 제시합니다. 아이덴티티와 정책 시장에는 이미 강력한 기존 사업자가 있습니다. 이 글이 다루는 실행 제어는 기존 통제가 실패한 뒤에야 필요성이 드러나는 경우가 많습니다.

이 레이어 자체에도 한계가 하나 있습니다. 주입된 지시문을 탐지하지는 못합니다. 그것은 상류 필터의 몫입니다. 자식 프로세스의 syscall을 어디까지 다루는지는 제품마다 다릅니다.

평가 자리에 들고 가야 할 질문

요약: 런타임 인가, 리스크 스코어링, Agentic Classifiers 등 경쟁하는 이름표가 늘어나도 그 판단을 누가 책임지는지는 여전히 정해지지 않았습니다. 벤더에게 물어야 할 것은 그 제품이 원칙적으로 할 수 있는 일이 아니라, 기본값이 그 판단을 어떻게 처리하는지입니다.

2026년에는 관련 시장도 움직였습니다. Delinea는 3월 StrongDM 인수를 마쳤고, Neo는 7월 에이전틱 소프트웨어용 실시간 통제 레이어를 출시했습니다. Teleport는 Black Hat에서 에이전트 리스크 스코어링과 Agentic Classifiers를 선공개하고, 가을부터 고객이 직접 사용해 볼 수 있다고 밝혔습니다.

이름표 경쟁은 계속될 것입니다. 런타임 인가, 리스크 스코어링, Agentic Classifiers. 목적 대조라는 기준으로 좁혀 보면 Teleport의 Agentic Classifiers가 가장 가깝습니다. 선언된 목표에 견줘 행동에 플래그를 붙이는데, 이는 다른 제품들이 공개한 것보다 한 걸음 더 나간 수준입니다. 하지만 그마저도 플래그를 붙이는 데서 멈춥니다. 명령이 실행되기 전에 판정을 돌려주는 것은 아닙니다. 이름표 아래에 있는 결정 자체는 바뀌지 않습니다. 에이전트가 명령을 만들면 무언가가 그것을 실행되기 전에 허용하거나 차단하거나 사람에게 넘겨야 합니다. 어떤 레이어도 그 결정을 맡지 않으면 에이전트가 그 결정을 대신 맡게 됩니다. Anthropic이 공개한 평가 환경에서 그랬고, 제약이 프롬프트 속 한 문단에 불과한 모든 스택에서도 마찬가지입니다.

그래서 평가 자리에 들고 가야 할 질문은 두 개입니다. 이 제품이 동작을 무엇과 대조해 판단하는가, 그리고 실제로 운영할 배포 환경에서 그 판단으로 무엇을 하는가입니다. 기록으로 남는 판단과 차단으로 이어지는 판단은 서로 다른 통제입니다. 어느 쪽을 얻게 되는지는 데이터시트 한 줄이 아니라 배포 방식에 달린 질문입니다. 그러니 기능이 있는지를 묻지 말고 기본값이 무엇인지를 물어야 합니다.

AlpacaX는 AI 에이전트 실행 제어를 만들고 있습니다.

자주 묻는 질문

AI 에이전트 실행 제어란 무엇인가요? 에이전트가 취하려는 특정 동작, 셸 명령이든 도구 호출이든 권한이 필요한 작업이든, 그 동작이 목표 시스템에 도달하기 바로 전에 정책과 대조해 판단하는 레이어입니다. 판단 결과는 허용, 차단, 사람에게 에스컬레이션 중 하나로 돌아갑니다. 판단 지점은 인증 이후, 실행 이전이며, 에이전트가 끄거나 수정할 수 없도록 에이전트 바깥에 자리합니다.

실행 제어는 새로운 카테고리인가요, PAM의 일부인가요? PAM의 일부입니다. AI 네이티브 PAM은 기업이 예산을 편성하는 카테고리이고, 실행 제어는 그 안에서 차별점을 만드는 레이어입니다. 레거시 PAM도 이미 명령을 검사합니다. SSH 명령 필터링, 문 단위 SQL 정책, sudo 방식의 실행 매개자가 그 예입니다. 여기에 더해 최근의 런타임 인가, 리스크 스코어링, 분류기 제품들은 동작 자체를 평가합니다. 이 레이어를 구분 짓는 기준은 판정이 명령이 실행되기 전에 떨어지는지, 그리고 그 판정이 그 특정 동작과 세션이 선언한 목적 모두에 묶여 있는지입니다. 오늘 기준으로 이 글에서 이름을 밝힌 제품들 가운데 이 둘을 동시에 하는 곳은 없습니다.

MCP 스펙이 실행 제어를 다루나요? 부분적으로만 다룹니다. 스펙이 정리하는 것은 에이전트가 어떻게 묻고 자신이 누구인지를 어떻게 밝히느냐입니다. RFC 9207 발급자 검증, 발급자에 묶인 클라이언트 자격증명처럼 강제 가능한 요구 사항도 포함됩니다. 여기에 실행 중간 확인 요청 기능도 추가됩니다. 구현자에게 남겨 둔 것은 명령이 실행돼도 되는지 여부입니다.