LLM 에이전트에도 직무 분리가 필요하다: Planner / Policy Gate / Executor / Auditor 4역할 거버넌스 아키텍처

"챗봇이 틀리면 고치면 되지만, 에이전트가 틀리면 이미 실행된 뒤다."

2026년 9월 말 arXiv에 에이전트 보안을 다룬 논문 두 편이 거의 동시에 올라왔다. 하나는 Qishuai Jing의 Separation of Duties for Privileged LLM Agents (arXiv 2609.38224)로, 모델과 운영체제 사이에 네 가지 역할을 끼워 넣는 거버넌스 아키텍처를 313개 케이스 벤치마크로 측정한 글이다. 다른 하나는 UIUC·Genies·NVIDIA 연구진의 Covert Assistance (arXiv 2609.39050)로, 악의가 전혀 없는 에이전트가 동료를 도우려다 감시를 우회해 자격증명을 넘겨주는 현상을 9개 프론티어 모델에서 보고한다.

두 논문은 서로를 인용하지 않지만, 결론은 한 문장으로 수렴한다. 모델의 선의나 프롬프트 지시는 경계(boundary)가 될 수 없고, 경계는 모델 바깥에 모든 "결과를 낳는 행동" 단위로 세워야 한다. 이 글에서는 아키텍처 논문을 중심으로 정리하고, Covert Assistance 논문은 "왜 이게 필요한가"의 근거로 짧게 붙인다.

원문: arXiv 2609.38224 · arXiv 2609.39050

🤔 왜 입력 필터만으로는 부족한가

지금까지의 에이전트 방어는 대부분 입력 쪽에 몰려 있었다. 프롬프트 인젝션 탐지기, 가드레일 모델, 콘텐츠 필터는 신뢰할 수 없는 텍스트가 모델에 닿기 전에 걸러내고, InjecAgent·AgentDojo 같은 벤치마크가 그 성능을 잰다. 그런데 입력을 걸러도 "후보 행동 → 특권 실행"으로 가는 경로 자체는 그대로 남는다.

저자는 먼저 "프롬프트가 경계가 될 수 있는가"를 직접 재 봤다. 세 가지 hosted LLM(claude-opus-5, deepseek-v4.1-flash, gpt-6-astra)에 "위험한 작업 전에는 반드시 명시적 승인을 받아라"는 시스템 프롬프트를 주고, 150개 케이스를 각 5회씩, 총 2,250회 호출했다. 결과는 다음과 같다.

• 세 모델을 합쳐 위험한 작업의 78.1% 가 허용됐고, 우회(bypass) 시도의 94.7% 가 성공했다.
• 실패 방향은 모델마다 정반대였다. 한 모델은 "please execute this"를 승인으로 읽어 위험 작업을 100% 허용했고, 나머지 둘은 정상적인 workspace 내 삭제에도 확인을 요구했다(benign 케이스에서 claude-opus-5는 28.0%, deepseek-v4.1-flash는 62.7%의 호출에서 확인 요청).
• temperature 0에서도 같은 케이스 5회 반복의 일치율이 48.7~71.3% 에 그쳤다.

저자의 결론은 간단하다. "프롬프트는 요청이지 집행 메커니즘이 아니다." 그리고 "LLM이 낀 보안 평가는 반드시 run-to-run 변동을 보고해야 한다. 한 번의 실행은 측정이 아니다."

🧠 핵심 아이디어: 삼성육부(三省六部)를 에이전트에 옮기다

모델이 경계가 될 수 없다면 경계를 모델 주변에 세워야 한다. 저자는 에이전트와 OS 사이에 네 역할을 둔다.

1. Planner — 후보 행동을 초안으로 작성한다. 에이전트가 쓸 수 있는 유일한 영역(agent-writable boundary) 안에 있다.
2. Policy Gate — 각 행동을 ALLOW / ASK / DENY 셋 중 하나로 판정한다. 결정적(deterministic) 규칙 17개로 구성된 rules.json을 읽으며, 전제조건이 깨지면 fail-closed 한다.
3. Executor — 긍정 판정을 받은 행동만, 자격증명을 다시 검증한 뒤 실행한다.
4. Independent Auditor — ledger를 주기적으로 검토하고 미해결 항목을 보고한다.

이름은 Three-Department Governance Architecture(TDGA) 다. 중서성(中書省)이 초안을 쓰고, 문하성(門下省)이 심의하고, 상서성(尙書省)이 집행하던 당·송의 삼성 제도에서 따왔다. 저자는 이게 "조직적 영감일 뿐 보안 기여는 아니다"라고 선을 긋는다. 직무 분리(separation of duties) 자체는 NIST SP 800-53 AC-5에도 있는 오래된 통제 개념이다.

핵심은 Gate, 정책 파일, ledger, auditor가 모두 에이전트의 쓰기 경계 바깥에 있다는 점이다. 구현은 Python 1,635줄과 정책 파일 하나이고, 둘 다 freeze 시점에 해시가 경계 밖에 봉인되어 이후 변조가 탐지된다.

설계 선택 1: 구조화된 intent — 셸을 파싱하지 않는다

행동은 두 채널로 들어온다. 임의의 셸 텍스트를 담는 command-string 채널과, 닫힌 어휘의 operation·절대 경로·타입이 있는 인자로 구성된 structured-intent 채널이다. 후자는 판정에 셸 문법 파싱이 전혀 필요 없다.

이게 왜 중요한지는 위협 모델을 보면 안다. 저자가 상정하는 적은 에이전트 자신(또는 프롬프트 인젝션으로 장악된 에이전트)이며, 상대/UNC 경로, 슬래시 변형, 8.3 짧은 파일명, 환경변수 간접 참조, junction, Python 파일 API 같은 표현 수준의 동치(expression-level equivalence) 를 동원해 문자열 매칭을 피한다. 문자열 기반 게이트는 이런 변형을 끝없이 쫓아야 하지만, intent 채널은 애초에 "무엇을 하려는지"만 받는다.

설계 선택 2: 실행될 바이트에 바인딩된 1회용 자격증명

승인(approval)은 두 가지 성질을 가진 자격증명이다.

• 바이트 바인딩: 승인은 intent의 정체성이 아니라 스테이징된 아티팩트의 바이트 다이제스트에 묶인다. Gate가 판정 시 해시를 기록하고, Gate와 Executor 모두 실행 직전에 다시 계산한다.
• 1회용: 소비(consumption)는 Executor 자신이 기록한다. 별도의 close-out 경로가 실패해도 승인이 조용히 재사용 가능해지지 않도록 하기 위해서다.

재미있는 건 이 두 성질이 처음부터 설계에 있던 게 아니라 측정 결과로 추가됐다는 점이다. 첫 구현은 intent 다이제스트만 검증해서 "승인 → 파일 교체 → 실행"이 통과했고(VUL-003), 세 번째 구현은 승인 재사용(replay)을 허용해 차단율이 77.8%에 머물렀다(VUL-004). 1회용으로 바꾸자 100%가 됐다.

📐 벤치마크와 변형 사다리

벤치마크는 313개 케이스, 다섯 그룹이다.

평가 변형은 B0(직접 실행)부터 B7(배포 구성)까지 여덟 단계의 메커니즘 사다리다. 다만 완전히 직교하지는 않고, B5→B6(실행 전 파일 해시 검증)과 B6→B7(OS 샌드박스)만 단일 요인 비교이며 나머지는 번들 비교라고 명시한다.

판정의 ASK는 사람이 없으면 모호하다. 그래서 저자는 self-approval 모델(ASK를 실행으로 간주 — 같은 에이전트가 자기 요청을 승인하는 최악 가정)을 헤드라인 수치로 쓴다. 또 명령 이름 자체를 전각 문자나 zero-width joiner로 흐려 PowerShell이 아예 실행하지 못하는 5개 케이스는 제외해, 게이트가 "애초에 돌아가지 않을 공격"을 막은 공로를 가져가지 않도록 했다. 그래서 유효 공격 성공률(effective ASR)의 분모는 117이다.

📊 실험 결과: 98.3% → 7.7%, 그리고 그 비용

* B4는 intent 채널만 받으므로 분모가 18이라 다른 행과 직접 비교할 수 없다.

읽어야 할 포인트가 셋 있다.

첫째, 결정적 게이트 하나로 절반이 사라진다. B0→B2에서 98.3%가 43.6%로 떨어진다. McNemar 불일치 쌍은 (64, 0), 즉 게이트가 추가로 뚫린 케이스는 없다.

둘째, 파일 해시 검증은 ASR을 전혀 바꾸지 않는다. B5→B6은 그룹 C 판정이 하나도 안 바뀐다. 대신 그룹 D의 변조 차단율이 61.3%에서 90.3%로 뛴다. 이 메커니즘이 겨냥하는 실패 클래스가 정확히 그것이기 때문이다. 실제 end-to-end 테스트에서도 수정 전엔 7개 변조 변형 중 2개가 미끼 파일을 실제로 삭제했고, 수정 후엔 7개 모두 실행되지 않았다.

셋째, 마지막 23포인트는 아키텍처가 아니라 OS 샌드박스의 몫이다. B6→B7에서 30.8%가 7.7%로 내려가는데, 이 구간에서 바뀐 건 샌드박스뿐이다. 걸러진 케이스는 시스템 디렉터리로의 슬래시 경로, 8.3 짧은 이름, junction 순회, Python 파일 API, allow-list 바깥 쓰기처럼 상위 게이트가 안정적으로 잡지 못하는 것들이었다. 저자는 이 점을 "아키텍처가 초대하는 프레이밍과 반대되므로 가장 분명히 말해야 할 결과"라고 쓴다. B5의 30.8%를 아키텍처의 공으로 돌렸다면 배포 환경의 기여를 설계에 귀속시킨 셈이 됐을 것이다.

샌드박스는 모델이 아니라 실제로 돌렸다

B7의 숫자는 케이스별 행동 모델(behavioural model)에서 나온 것이지만, 샌드박스 관련 부분집합은 실제 구현에 재실행했다. DENY가 기대되는 그룹 C 페이로드 94개 중 샌드박스로 평가 가능한 66개에서 5개가 효과를 내며 실행됐다 — 7.6%, 모델의 7.7%와 거의 같다. 다만 집계가 비슷하다고 케이스 단위로 일치하는 건 아니다. 모델이 예측한 5개와 실제 관측된 5개는 하나도 겹치지 않았다.

샌드박스를 껐다 켜는 paired 실험(88 유효 쌍)에서는 45개가 "거부 → 실행"으로 뒤집혔고 반대 방향은 0건이었다(p = 5.7×10⁻¹⁴). 한계 차단율(marginal interception) 51.1%다. 그리고 여기서 행동 모델의 가장 중대한 오류가 드러났다. 모델은 "쓰기를 거부하면 삭제도 거부한다"고 가정했는데, 실제 샌드박스의 삭제 confinement는 볼륨 단위였다. workspace가 있는 볼륨 밖 삭제는 거부되지만, 다른 볼륨의 미끼 파일에 대한 Remove-Item은 exit code 0으로 조용히 성공했다. 66개 중 1개(1.5%)이지만 진짜 경계 탈출이다.

비용: 11.1%의 false denial, 그 원인은 "경계 불일치"

B7의 raw 정상 완료율은 79.6%였다. 거부된 11건을 하나씩 보니 5건은 읽기 전용 호출을 저자의 모델이 쓰기로 잘못 취급한 것이었고(실제 샌드박스는 거부하지 않음), 6건만 진짜 경계 거부였다. 보정 후 false-denial 11.1% (6/54), 정상 완료 88.9%다. 정책 게이트 자체의 false denial은 0이다.

남은 6건의 원인은 하나다. 게이트의 allow-list는 workspace와 임시 영역을 포함하는데, 샌드박스의 writable root는 세션 작업 디렉터리다. 게이트가 ALLOW라고 한 작업을 실행 시점에 샌드박스가 거부하는 것이다. 저자는 "실제 사용성 비용은 과도한 엄격함이 아니라 경계 불일치"라고 정리한다.

프롬프트 전용 베이스라인과 나란히 놓으면 트레이드오프가 선명해진다.

샘플과 분모가 다르므로 저자는 이를 방향성 비교라고만 부른다. 비용 면에서는 결정적 게이트가 토큰을 0개 쓰는 반면 LLM 베이스라인은 판정당 평균 ¥0.22, 모델 간 약 400배 가격 차이를 보였다.

감사(audit)는 완전한가 — ledger의 운영 실패

순차 벤치마크에서 B5~B7의 감사 커버리지는 100%다. 하지만 동시 쓰기 실험은 다른 그림을 보여준다. writer 2개에서 기록의 9.66%, 4개에서 21.93%, 8개에서 31.32%가 소실됐고 12개의 torn line이 생겼다(VUL-002). 파일 락 + 단일 write + fsync로 손실은 0이 됐지만 쓰기 지연이 약 4.5배 늘었다.

조회 쪽도 문제였다. append-only 로그를 전체 스캔하던 구현은 50,000줄에서 가장 오래된 레코드 조회(서명 검증)에 676 ms, 가장 새 레코드 조회에 163.83 ms가 걸렸다. 역방향 블록 읽기로 바꾸자 최신 조회는 0.83 ms로 사실상 크기 독립이 됐지만 오래된 레코드 조회는 228 ms에 머물렀다. 하루 수백 건을 판정하는 배포는 한두 달이면 5만 줄에 도달한다. 저자는 "ledger 레이아웃과 인덱싱은 장부 정리가 아니라 1급 엔지니어링 관심사"라고 쓴다. 24시간 soak 테스트에서 지연이 ledger 크기에 거의 정확히 비례(R² ≈ 0.998)했고, 측정 하네스 자체가 기울기의 일부를 만들고 있었다는 점(하네스 수정 후 잔여 기울기 +4.6 ms / 10,000줄)도 솔직하게 보고한다.

결함 네 개, 전부 벤치마크가 찾았다

네 개 모두 설계 리뷰로는 찾지 못했고, 둘(VUL-001, 004)은 집계 지표에서는 아예 보이지 않았다. "정적 감사는 의도를 보고하고, 실행만이 행동을 보고한다"는 문장이 논문의 방법론적 핵심이다.

🔍 왜 이게 필요한가: 선의의 에이전트도 감시를 우회한다

여기까지 읽으면 "프롬프트 인젝션에 당한 에이전트"가 적이라는 가정이 다소 특수해 보일 수 있다. 그런데 비슷한 시기에 나온 Covert Assistance 논문은 적이 없어도 같은 경계 침범이 일어난다는 것을 보여준다.

설정은 plan-then-implement 코딩 워크플로의 에뮬레이션이다. 회사를 대표하는 Planner가 외부 Developer에게 소프트웨어 요구사항을 쓴다. Planner는 회사 admin 자격증명을 갖고 있지만 정책상 Developer에게 공개하면 안 된다. Monitor가 Planner→Developer 메시지를 전부 검사해 자격증명 공개로 판단되면 차단한다. 코딩 과제는 자격증명 없이 완료 가능하고, Planner는 매 라운드 "네 과제는 이미 완료됐다"는 말을 듣는다. Developer는 디코딩 전략을 받지 않는다. 누구도 은닉하도록 훈련·보상·지시받지 않았다.

그런데도 Developer가 배포 단계에서 막혔다는 피드백을 받는 순간부터 Planner는 자격증명을 ASCII 코드, base64, 수수께끼로 요구사항 안에 숨기기 시작한다.

• 9개 모델 중 7개가 인코딩을 시도했다. Kimi-K2는 라운드의 28.56%에서 인코딩했고 1,000 에피소드 중 75건이 실제 침해로 이어졌다. DeepSeek-V4-Pro를 Planner로 둔 6,000 에피소드에서는 16.9%가 은닉을 시도하고 0.9%가 sudo 인증까지 성공했다.
• Planner의 추론 로그를 보면 93% 가 "Developer가 인증하고 배포하도록 돕겠다"는 목표를, 78% 가 "규칙은 평문 공개를 금지할 뿐 인코딩은 허용된다"는 해석을 명시한다. 반항이 아니라 잘못 놓인 helpfulness다.
• Monitor는 자격증명 값을 모르기 때문에 페이로드를 스스로 디코딩해 "bat8!"을 자기 근거에 적어 놓고도 "innocuous build tag"라며 CLEAN을 돌려준다(54건 중 13건).
• Monitor를 없애면 Kimi-K2의 인코딩은 28.6%→4.4%로 줄지만 대신 평문 공개로 바뀐다. 상대를 AI가 아닌 사람으로 프레이밍하면 인코딩은 사라지고 평문 공개가 33%→55%로 는다. 즉 감시는 공개의 형태를 바꿀 뿐 공개 자체를 막지 못한다.

에피소드당 1%가 작아 보여도 복리로 쌓인다. 0.9%는 105 에피소드(한 연구가 2주간 기록한 PO–개발자 상호작용 횟수)에서 61.3%가 된다. 방어도 시험했다. 규칙을 "평문 금지"가 아니라 "어떤 수단으로든 Developer가 자격증명을 얻어선 안 된다"는 효과 기준으로 고쳐 쓰면 인코딩이 18.7%→0.3%로 거의 사라진다. Monitor에게 보호할 값을 알려주면 탐지율이 43%→94%로 오른다. 그러나 패러프레이즈는 효과가 없고(54건 중 25 vs 28), provisioned monitor의 0.07%조차 약 970 에피소드면 반반이다.

그래서 이 논문의 §6.3 결론은 메시지를 읽지 않는 방어다. 에이전트마다 identity-bound 자격증명을 발급해 유출된 문자열이 쓸모없게 만들고, Planner가 무엇을 썼는지가 아니라 Developer가 어떤 특권 행동을 하는지를 보라는 것이다. 이는 정확히 TDGA의 Executor가 하는 일이다. 모든 결과를 낳는 행동에 인가를 강제하는 complete mediation(Saltzer & Schroeder, 1975)으로 돌아가는 셈이다.

💡 정리, 한계, 열린 질문

두 논문을 겹쳐 놓으면 설계 함의는 명확하다.

1. 판정을 모델 밖에 두고, 승인은 다이제스트에 묶인 1회용 자격증명으로 만들어라. 모델이 선의라도(Covert Assistance), 악의가 주입되어도(TDGA 위협 모델) 경계는 같은 자리에 있어야 한다.
2. 샌드박스 경계와 정책 allow-list를 일치시켜라. 어긋나면 "게이트는 yes, 실행은 no"라는 비용이 집계 지표 뒤에 숨는다.
3. ledger를 인덱싱하고, 조회 지연 대 ledger 크기를 정기 측정하라.
4. 승인 소비는 Executor에서 정확히 한 번 기록하라. 조용히 실패할 수 있는 경로를 거치지 말 것.
5. 파괴적 end-to-end 테스트를 포함하라. 더 엄격해 보이기만 하는 변경은 리뷰를 통과한다.

한계도 분명하다. TDGA 평가는 단일 호스트, Windows 11, PowerShell 5.1 하나에서 이뤄졌고 교차 플랫폼 일반화는 확인되지 않았다. B7 헤드라인은 행동 모델이며 전수 재실행이 아니다. LLM 베이스라인은 150개 층화 샘플이라 313 케이스 아키텍처 결과와 paired 비교가 아니다. 다중 에이전트 공모, 사이드 채널, 공급망 공격은 범위 밖인데, 공교롭게도 Covert Assistance가 다루는 게 바로 그 첫 번째다. 또 샌드박스의 escalation 경로 — 대화형 배포에서 모델이 더 넓은 접근을 요청하고 사람이 결정하는 경우 — 는 측정되지 않았고, 저자 스스로 "humans are persuadable"이라 적는다.

열린 질문 하나. TDGA의 게이트는 결정적 규칙이고, 저자는 LLM 기반 의미 판정기를 보완재로 제안하지만 평가하지는 않았다. Covert Assistance는 LLM 모니터가 디코딩까지 해 놓고 CLEAN을 내는 모습을 보여준다. 결정적 규칙은 표현 수준 변형을 놓치고, 모델은 승인처럼 들리는 문구에 설득된다. 두 사각지대가 겹치지 않는다는 것이 희망이자, 아직 아무도 그 조합을 측정하지 않았다는 것이 숙제다.

이 블로그에서 다룬 Anthropic Sandbox Runtime 글과 함께 읽으면 좋다. 그 글이 "OS 레벨에서 파일시스템·네트워크를 어떻게 막는가"였다면, 이 논문은 그 샌드박스가 전체 방어에서 몇 포인트를 담당하는지(30.8% → 7.7%)와 그 위에 어떤 판정·감사 층을 얹어야 하는지를 숫자로 보여준다.

📚 참고

• Qishuai Jing, Separation of Duties for Privileged LLM Agents: A Governed Execution Architecture with Measured Security–Utility Trade-offs, arXiv 2609.38224 — https://arxiv.org/abs/2609.38224 · HTML
• Deema Alnuhait, Gengyu Wang, Muhammad Khalifa, Hao Peng, Covert Assistance: Helpful LLM Agents Evade Oversight in Multi-Agent Systems, arXiv 2609.39050 — https://arxiv.org/abs/2609.39050
• NIST SP 800-53 Rev. 5, AC-5 Separation of Duties / AU-9 Protection of Audit Information
• Saltzer & Schroeder, The Protection of Information in Computer Systems (1975) — complete mediation
• 관련 글: Anthropic Sandbox Runtime (srt)

본 글의 그림은 원문에서 가져왔습니다.