Agent2026년 10월 8일

가드레일에서 실행 경계로 — 에이전트의 도구 호출을 통제하는 정책 집행 구조

#agent-execution-control#policy-enforcement-point#prompt-injection#tool-calling#agent-security

같은 프롬프트 인젝션(prompt injection)이라도 챗봇에서는 잘못된 문장 하나로 끝나지만 메일을 보내고 코드를 실행하고 송금을 요청할 수 있는 에이전트에서는 되돌릴 수 없는 부작용(side effect)으로 남는다. 그런데 가드레일이라는 이름으로 묶여 온 방어는 대개 모델의 입력과 출력을 검사한다. 에이전트가 실제로 무엇을 실행하는지는 모델이 내놓은 토큰이 아니라 그 토큰을 도구 호출로 바꾸어 실행하는 런타임이 결정하는데도 통제는 여전히 그 앞단에 머물러 있는 경우가 많다.

이 글은 에이전트의 통제 지점이 모델의 입출력에서 도구 호출이 실행으로 넘어가는 실행 경계로 옮겨 가는 흐름을 다룬다. 먼저 위험의 단위가 어떻게 바뀌었고 표준과 연구가 어디로 수렴하는지를 짚고, 그 흐름에서 설계자가 취해야 할 원칙을 정리한 뒤, 정책 집행 지점의 동작과 정책을 적는 대표 방식, 정책이 닿지 않는 영역을 보완하는 데이터 흐름 통제, 도입할 때 남는 과제를 차례로 설명한다.

응답에서 행동으로 옮겨 간 보안의 단위

에이전트 보안의 단위는 응답의 문장에서 도구 호출이 만드는 부작용으로 옮겨 갔다. 그 원인은 구조에 있다. 에이전트가 메일, 웹 페이지, 도구의 반환값을 읽으면 그 내용은 사용자의 지시와 같은 컨텍스트에 같은 토큰 열로 들어가고, 모델에게는 어느 토큰이 지시이고 어느 토큰이 데이터인지를 구분할 구조적 장치가 없다. OWASP Top 10 for Agentic Applications 2026이 목표 탈취(ASI01 Agent Goal Hijack)를 첫 항목에 둔 것도 같은 문제의식이다. 즉 프롬프트 인젝션은 특정 모델의 결함이라기보다 데이터와 지시가 하나의 채널을 공유하는 아키텍처에서 비롯되는 성질에 가깝다.

공격을 탐지해 차단하는 방어가 이 구조를 넘어서지 못한다는 근거도 축적되었다. 여러 연구 기관의 연구진이 함께 발표한 **The Attacker Moves Second(USENIX Security 2026)**는 프롬프트 기반, 공격 데이터 학습, 탐지 모델, 비밀 정보 기반의 네 계열에 걸친 방어 12종을 경사 하강, 강화학습, 무작위 탐색, 사람이 이끄는 탐색으로 공격했다. 대부분 원 논문에서 0에 가까운 공격 성공률을 보고했던 방어였지만 방어의 설계를 겨냥해 조정한 적응형 공격(adaptive attack) 앞에서 대다수가 90%가 넘는 공격 성공률을 허용했고, 500명 이상이 참가한 사람의 레드팀은 40개 과제 모두에서 공격에 성공했다. 저자들은 탐지 모델 역시 신경망이어서 공격자가 대상 모델과 탐지 모델을 동시에 기만할 수 있다고 지적한다. ETH 취리히 연구진이 2026년 6월에 공개한 자동화 공격 연구는 여러 과제에 두루 통하도록 최적화한(task-universal) 인젝션이 처음 보는 과제와 영역으로 전이되지만 그 효과가 모델에 따라 크게 달라진다고 정리했다. 모델과 공격자의 예산에 따라 강도가 달라지는 방어는 설계의 보장으로 삼을 수 없다는 점을 이 결과들이 함께 보여 준다.

통제 지점의 이동: 모델에서 실행 경계로

글로벌 표준과 연구는 통제 지점을 모델 밖, 행동이 일어나는 곳으로 옮기는 방향으로 수렴하고 있다. OWASP의 에이전트 위험 목록은 목표 탈취와 별도로 도구의 오용(ASI02 Tool Misuse and Exploitation)과 신원과 권한의 남용(ASI03 Identity and Privilege Abuse)을 독립 항목으로 둔다. 목표가 탈취되더라도 피해는 도구와 권한을 거쳐야 발생하므로 그 경로를 따로 통제할 수 있다고 보는 것이다. ETH 취리히, EPFL 등 여러 기관의 연구진이 정리한 **Design Patterns for Securing LLM Agents against Prompt Injections(2025)**는 이를 하나의 원칙으로 적는다. 신뢰할 수 없는 입력을 처리한 에이전트는 그 입력이 영향이 큰 행동을 유발할 수 없도록 제약해야 한다는 것이다. 규제도 같은 지점을 본다. EU AI Act 제14조는 고위험 AI 시스템의 감독자가 출력을 무시하거나 뒤집을 수 있어야 하고 정지 버튼이나 그에 준하는 절차로 시스템을 안전한 상태에서 멈출 수 있어야 한다고 규정한다.

통제 지점을 둘 수 있는 위치는 크게 셋이다. 아래 표는 각 위치가 볼 수 있는 정보, 판정의 성격, 우회 경로를 비교한다.

위치	볼 수 있는 정보	판정의 성격	우회 경로
모델(정렬, 입출력 분류기)	지시와 데이터가 섞인 토큰 열	확률적	적응형 공격, 분류기 자체의 오판
에이전트 루프(프레임워크 훅)	계획, 행동, 관찰, 대화 상태	규칙은 결정론적, LLM 검사는 확률적	훅을 거치지 않는 내장 도구와 직접 호출
실행 경계(도구 런타임, 게이트웨이)	호출 주체, 도구 이름, 인자, 자원, 환경 맥락	결정론적	경계 밖에 남은 실행 경로, 인가된 형식 안의 악용

표에서 드러나듯 실행 경계는 의미를 가장 적게 보지만 우회 경로가 가장 좁다. 모델과 에이전트 루프의 통제를 버리자는 것이 아니라 최종 판정의 책임을 우회할 수 없는 위치에 두어야 한다는 데 이 흐름의 핵심이 있다.

실행 경계 설계의 세 원칙

이 흐름에서 설계자가 취해야 할 원칙은 세 가지다. 첫째, 정책 집행 지점은 모든 부작용이 반드시 지나는 곳에 둔다. 셸 실행, 파일 쓰기, 네트워크 송신이 하나라도 그 지점을 거치지 않으면 나머지 통제는 우회로 하나에 무력해진다. 이는 보안 설계에서 오래된 완전한 중재(complete mediation)의 원칙을 에이전트의 도구 호출에 적용한 것이다. 둘째, 판정은 모델 밖에서 결정론적으로 내리고 근거를 기록한다. 같은 호출에 같은 정책이면 같은 결과가 나와야 정책을 테스트할 수 있고, 어떤 규칙이 판정을 결정했는지가 남아야 감사 로그가 사후 분석의 근거가 된다.

셋째, 판정이 틀렸을 때를 전제로 설계한다. 정책은 사람이 쓰고 사람은 모든 경우를 예상하지 못하므로 정책을 통과하는 잘못된 호출은 발생할 수밖에 없다. 그래서 피해 범위를 한정하는 격리와 최소 권한, 영향이 큰 호출에 대한 사람의 승인, 에이전트의 통제 밖에 있는 중단 경로가 다음 방어선으로 필요하다. 즉 가드레일이 확률적 필터라면 실행 경계는 결정론적 중재자이고, 승인과 격리와 킬스위치(kill switch)는 그 중재자가 놓친 호출에 대비하는 계층이라는 위계로 이해해야 한다.

실행 경계의 정책 집행 구조

정책 집행 지점(PEP, Policy Enforcement Point)과 정책 결정 지점(PDP, Policy Decision Point)은 RFC 2753이 정책 기반 수락 제어(policy-based admission control)의 구조를 설명하며 정의한 용어다. PEP는 판정이 실제로 집행되는 지점이고 PDP는 판정이 내려지는 지점이다. RFC 2753은 요청에 정책 정보가 없더라도 PEP가 반드시 PDP에 문의해야 한다고 규정하는데, 이는 정책 정보를 생략한 요청이 정책 통제를 우회하지 못하게 하기 위한 장치다. 에이전트에 옮기면 PEP는 모델이 낸 도구 호출을 실행 직전에 받는 도구 런타임이나 게이트웨이이고, PDP는 모델과 분리되어 정책을 평가하는 정책 엔진이다.

간단한 예로 동작 순서를 살펴본다. 받은편지함 요약을 맡은 에이전트가 메일 본문에 삽입된 지시를 읽고 외부 주소로 첨부 파일을 보내는 send_email 호출을 낸다. 먼저 PEP가 이 호출을 실행 전에 가로챈다. 다음으로 PEP는 호출 주체(이 사용자를 대신하는 에이전트 세션), 행위(send_email), 자원(수신 주소), 맥락(현재 과제, 첨부 파일의 분류)을 담은 요청을 PDP에 보내고, PDP는 "같은 조직 도메인으로의 송신은 허용", "기밀로 분류된 첨부의 외부 송신은 금지"라는 정책을 평가해 거부를 반환한다. 이어서 PEP는 실행을 막고 미리 정한 폴백 동작에 따라 에이전트에 거부 사유를 반환하거나 사용자에게 확인을 요청한다. 마지막으로 판정 결과와 판정을 결정한 정책의 식별자를 감사 로그에 남긴다.

정책을 적는 방식은 연구마다 다르다. 싱가포르 경영대학 연구진의 **AgentSpec(ICSE 2026)**은 실행 루프의 이벤트에 규칙을 연결하는 도메인 특화 언어(DSL)다. 규칙은 이벤트(trigger), 조건(check), 집행(enforce)으로 구성되고 이벤트에는 행동 실행 직전(before_action), 상태 변화(state_change), 종료(agent_finish)가 있다. 집행은 사용자 확인(user_inspection), LLM의 자기 점검(llm_self_examine), 미리 정한 행동 실행(invoke_action), 중단(stop) 가운데에서 고른다. 코드 에이전트에서 위험한 실행의 90% 이상을 막았고 조건 평가에 드는 시간은 수 밀리초로 수십 초 걸리는 에이전트 실행에 비해 무시할 만했다. 다만 저자들은 판정이 이산적인 검사 시점에서만 일어나 긴 궤적 전체의 안전성은 분석하지 못한다고 인정한다.

UC 버클리 등의 연구진이 발표한 **Progent(2025)**는 단위를 도구 호출 하나로 좁힌다. 정책은 순서가 있는 규칙의 목록이고 규칙마다 효과(허용 또는 금지), 대상 도구, 인자에 대한 조건(멤버십 검사, 정규표현식 매칭 등), 폴백 동작을 갖는다. 금지 규칙을 먼저 보고 허용 규칙을 다음에 보며 어느 규칙에도 맞지 않는 호출은 차단하고, 폴백 동작은 실행 종료, 사용자 확인, 에이전트에 오류 메시지 반환 가운데 하나다. 정책은 JSON Schema로 적어 LLM이 과제에 맞춰 생성할 수 있고, 실행 중의 정책 변경은 SMT 솔버가 허용 범위를 좁히는 변경이면 자동 적용하고 넓히는 변경이면 승인을 요구한다. 저자들은 이를 단조 제한(monotonic confinement)이라 부르며 사람이 작성한 규칙에서 한 벤치마크의 공격 성공률이 0%가 되었다고 보고한다. 같은 저자들은 과제의 최소 권한 안에서 일어나는 공격과 MCP 인터페이스를 거치지 않는 내장 도구를 보호 범위 밖으로 둔다.

범용 인가 언어로는 오픈소스 Cedar가 있다. Cedar의 요청은 주체(principal), 행위(action), 자원(resource), 맥락(context)의 네 요소로 이루어지고, forbid 정책 하나라도 참이면 거부, 그렇지 않고 permit이 참이면 허용, 둘 다 없으면 거부한다. 즉 기본 거부와 금지 우선이 판정 알고리즘에 고정되어 있고, 응답에는 판정을 결정한 정책 목록이 함께 담겨 감사 로그의 근거로 쓸 수 있다. 에이전트 전용 언어가 실행 루프와 도구의 의미를 알고 있다면 범용 인가 언어는 판정 규칙이 명확하고 기존 인가 체계와 같은 형식으로 관리할 수 있다는 데 장점이 있다.

정책이 닿지 않는 영역과 데이터 흐름 통제

정책은 호출의 형식을 판정할 뿐 그 호출이 사용자의 의도에 맞는지는 보지 못한다. 동료에게 보내는 메일이 허용된 형식이라면 삽입된 지시가 본문에 포함시킨 기밀 요약도 같은 형식으로 통과한다. Progent가 최소 권한 안의 조작을 범위 밖으로 둔 것도, 설계 패턴 논문이 격리된 LLM조차 이력서의 순위나 메일의 인자를 조작당할 수 있다고 적은 것도 같은 한계를 가리킨다. 인가된 형식 안의 악용을 막으려면 인자의 값이 어디에서 왔는지, 즉 데이터의 출처를 판정의 입력에 넣어야 한다.

ETH 취리히 등의 연구진이 발표한 **CaMeL(Defeating Prompt Injections by Design, 2025)**은 이중 LLM 패턴을 구체적으로 구현해 이 문제를 다룬다. 특권 LLM(P-LLM)은 신뢰할 수 있는 사용자 질의만 보고 계획을 파이썬과 비슷한 코드로 쓰며 도구의 반환값을 보지 않는다. 격리 LLM(Q-LLM)은 도구 접근 없이 신뢰할 수 없는 데이터를 정해진 스키마로 파싱만 한다. 전용 인터프리터가 이 코드를 실행하면서 데이터 흐름 그래프를 추적하고 값마다 출처와 읽을 수 있는 대상을 적은 capability를 붙이며, 도구 호출 직전에 파이썬 함수로 적은 보안 정책을 검사해 위반하면 차단하고 사용자의 승인을 구한다. 그 결과 신뢰할 수 없는 데이터는 제어 흐름을 바꿀 수 없고 인가되지 않은 데이터 흐름으로 정보가 유출되는 경로가 막힌다. AgentDojo에서 증명 가능한 보안 아래 과제의 77%를 해결해 방어가 없는 시스템의 84%에 근접했고, 중앙값 과제 기준으로 입력 토큰은 약 2.82배, 출력 토큰은 약 2.73배가 들었다. 저자들은 사용자가 정책을 작성하고 유지해야 하는 부담, 예외와 실행 시간을 통한 사이드 채널, 필요한 행동 자체가 신뢰할 수 없는 데이터에 달린 과제를 풀 수 없다는 점, 허용된 제어 흐름 블록을 이어 붙이는 공격의 가능성을 한계로 든다. 데이터 흐름 통제는 PEP가 보는 입력을 호출의 형식에서 인자의 출처까지 넓히는 대신 표현력의 제약과 추가 비용을 감수해야 한다.

도입의 설계 판단과 남은 과제

실행 경계의 정책 집행을 실제 시스템에 도입할 때 아직 해법이 정립되지 않은 문제는 다음과 같다.

첫째, 정책의 작성과 검증이다. 정책을 LLM이 생성하게 하면 작성 부담은 줄지만 AgentSpec의 저자들은 생성된 규칙이 예시에 과적합되고 미탐과 오탐을 낸다고 보고했다. 정책도 코드처럼 테스트 케이스로 검증하고 변경을 리뷰하는 절차가 필요하며, Progent처럼 SMT 솔버로 변경이 범위를 좁히는지 넓히는지를 기계적으로 가리는 방식이 한 방향이다.

둘째, 기본 거부의 운영 부담이다. 예상하지 못한 정상 요청이 차단되고 승인 요청이 잦아지면 사용자는 내용을 보지 않고 승인하게 된다. 정책의 평가 오류도 운영에서 유의해야 한다. Cedar는 평가 중 오류를 낸 정책을 판정에서 제외하므로 오류를 낸 forbid 정책은 거부 판정을 만들지 못하고 결과는 나머지 정책에 의해 결정된다.

셋째, 다중 에이전트에서의 권한 전파다. 오케스트레이터가 하위 에이전트에 작업을 위임할 때 위임받은 쪽의 권한이 위임한 쪽의 권한을 넘지 않도록 좁혀 전달하는 방식은 아직 정립되지 않았다. 신원과 권한의 남용이 별도의 위험 항목으로 분류된 것도 이 위임 사슬의 문제와 맞닿아 있다.

넷째, 정책 형식과 판정 기록의 표준 부재다. AgentSpec은 자체 DSL, Progent는 JSON Schema, CaMeL은 파이썬 함수, Cedar는 범용 인가 언어로 정책을 적는다. 도구 호출을 PDP에 넘기는 요청의 형식과 판정 기록의 형식이 정해져 있지 않아 구현마다 감사 로그를 다시 맞춰야 한다.

다섯째, 킬스위치의 실효 조건이다. 킬스위치가 실제로 기능하려면 발급한 자격증명과 위임한 권한을 즉시 회수할 수 있어야 하고, 진행 중인 도구 호출과 하위 프로세스를 중단할 수 있어야 하며, 중단 시점의 상태를 보존해 복구하거나 되돌릴 수 있어야 한다. 무엇보다 중단 경로가 에이전트의 통제 밖에 있어야 한다. 에이전트가 수정하거나 호출할 수 있는 설정으로 구현된 중단은 정책이 놓친 바로 그 공격에 함께 무력해진다. 피해 범위를 한정하는 자격증명 격리는 "MCP Gateway 기술 심층 이해와 활용"에서, 격리 기술의 계층은 "소프트웨어 개발 하네스를 에이전트로 구현하는 기술 동향"에서 다뤘다.

정리 및 요약

에이전트의 위험은 응답의 문장에서 도구 호출의 부작용으로 옮겨 갔고, 데이터와 지시가 같은 토큰 열로 들어오는 구조에서 모델 수준의 탐지는 적응형 공격 앞에 유지되지 않는다. 그래서 표준과 연구는 통제 지점을 모든 부작용이 지나는 실행 경계로 옮기고 있다. 그 경계에서 PEP가 호출을 가로채고 모델 밖의 PDP가 주체, 행위, 자원, 맥락으로 결정론적 판정을 내리며 AgentSpec, Progent, Cedar가 그 정책을 적는 서로 다른 방식을 보여 준다. 호출의 형식만으로 막지 못하는 악용은 CaMeL처럼 값의 출처를 capability로 추적하는 데이터 흐름 통제가 보완하지만 그 대가로 표현력의 제약과 토큰 비용을 감수해야 한다.

결국 에이전트 실행 통제는 더 영리한 가드레일을 고르는 문제가 아니라 우회할 수 없는 판정 지점을 어디에 두고, 그 판정이 틀렸을 때 피해를 어디까지로 한정하며, 누가 어떤 경로로 멈출 수 있게 할지를 정하는 신뢰 경계 설계의 문제다.

참고 자료

← Blog