에이전트가 사내 툴을 직접 사용하고, 메모리에서 사용자 맥락을 꺼내며, 외부 서비스로 결과를 보내는 상황에서도 프롬프트 한 줄만으로 통제할 수 있을까? 지금 쟁점은 모델 성능보다 집행력이다. arXiv에 올라온 Governance by Construction for Generalist Agents는 범용 에이전트를 도메인마다 다시 만들지 않고, 정책 계층으로 허용 행동·인간 승인 조건·정보 노출 범위를 제어하자는 방향을 제시한다. 기업 입장에서는 “똑똑한 에이전트”보다 “멈출 수 있는 에이전트”를 제품 구조 안에 넣을 수 있는지가 더 중요해졌다.

세 줄 요약

• 핵심 이슈는 범용 LLM 에이전트 위에 정책-as-code 계층을 두고, 어떤 액션을 허용할지·언제 사람 승인을 받을지·어떤 정보를 노출할지를 분리해 관리하자는 접근이다.
• 이 접근이 중요한 이유는 에이전트 리스크가 답변 품질보다 툴 사용, 권한 상승, 데이터 유출 같은 실행 단계에서 커지기 때문이다. 프롬프트 지침만으로는 강한 집행을 기대하기 어렵다.
• 에이전트를 도입할 때는 “모델이 무엇을 할 수 있나”보다 “툴 호출 직전에 무엇이 차단되나”를 먼저 검증해야 한다. 승인 트리거·데이터 노출 규칙·감사 로그를 구조에 포함하는지도 확인할 필요가 있다.

현황

원문 발췌에서 확인되는 사실은 비교적 명확하다. 이 데모는 CUGA의 정책 시스템을 소개하고, 이를 범용 LLM 에이전트와 결합해 프로덕션 수준의 거버넌스를 구현하겠다고 설명한다. 초점은 세 가지다. 어떤 행동을 허용할지, 언제 인간 감독이 필요한지, 어떤 정보가 외부로 노출될 수 있는지다.

이 접근의 핵심은 에이전트 자체를 도메인별로 다시 학습하거나 다시 짜지 않는 데 있다. 대신 정책을 코드처럼 분리해 얹는다. 이 구상은 엔터프라이즈 운영 환경과 맞닿아 있다. 실제 배포에서는 모델이 “답을 잘 내는가” 못지않게 “금지된 행동을 실행 전에 멈추는가”가 운영 기준이 되기 때문이다.

다만 정책 레이어라는 표현만으로 집행 강도가 보장되지는 않는다. 조사 결과에 따르면 프롬프트 수준 지침만으로는 강하게 집행된다고 보기 어렵다. 반면 툴 호출 직전에 가로채는 참조 모니터, 프록시, 도구 호출 인터셉션처럼 구조적으로 삽입된 방식은 정책 위반 액션을 실행 전에 차단하고 감사 가능성도 높이는 방향으로 설명된다. 여기서 확인되는 기준점은 세 개다. 이번 원문은 arXiv:2605.20874v1이고, 권한 상승 완화를 다룬 별도 연구는 arXiv:2601.11893이며, 데이터 유출 공격을 다룬 연구는 arXiv:2604.05432다.

분석

의사결정 관점에서 보면 이 논문의 메시지는 단순하다. If 범용 에이전트를 여러 도메인에 빠르게 배치해야 한다면, Then 정책을 에이전트 바깥 계층으로 분리하는 편이 운영상 유리하다. 정책 변경이 곧 제품 변경이 되지 않기 때문이다. 승인 규칙을 바꾸거나 정보 노출 범위를 좁힐 때 모델을 다시 구성하는 부담도 줄어든다. NIST AI RMF 자료도 인간-AI 협업에서 역할과 책임, 감독 정책을 지속적인 거버넌스 과제로 다룬다. 이 맥락과 맞닿아 있다.

그렇다고 이 구조를 과신할 수는 없다. If 정책 레이어가 모델 출력 옆에 붙은 안내문 수준이라면, Then 공격 표면은 그대로 남는다. 권한 상승을 노린 자연어 공격이나, 도구 사용을 비틀어 메모리 데이터를 빼내는 시나리오는 별도 연구에서도 제기됐다. 반대로 If 정책이 실제 툴 실행 경로를 감싼다면, Then 차단력과 감사 가능성은 올라간다. 트레이드오프도 있다. 차단 규칙을 촘촘히 걸면 에이전트 자율성이 떨어지고 승인 대기 때문에 속도가 느려질 수 있다. 느슨하게 두면 현장 생산성은 나아질 수 있지만 사고 비용은 커질 수 있다. 결국 이 문제는 “성능 대 안전”의 추상 논쟁보다 “어느 액션을 어디서 멈출 것인가”라는 설계 문제에 가깝다.

또 하나의 포인트는 통합 가능성이다. 조사 결과 기준으로는 기존 프레임워크와 기업 보안 체계에 붙일 여지가 있다. LangChain은 PII 탐지, human-in-the-loop, 접근권한과 권한부여 같은 운영 통제를 제공하는 것으로 알려져 있고, NIST AI RMF는 인간 감독 프로세스와 역할·책임 정책을 요구한다. 즉, 정책 계층은 완전히 새로운 체계를 만들기보다 기존 IAM, 승인, 로그, 데이터 보호 절차와 맞물리는 미들웨어에 가깝다. 다만 어떤 프레임워크에 얼마나 쉽게 붙는지, 특정 보안 스택과 직접 연동하는지는 여기서 확인되지 않았다.

실전 적용

제품팀이나 플랫폼팀이 먼저 판단할 질문은 하나다. “우리 에이전트의 안전장치는 응답 생성 단계에 있나, 실행 단계에 있나?” 실행 단계가 비어 있으면 거버넌스는 문서에 머문다. 예를 들어 사내 문서 검색과 티켓 생성, 메일 발송을 묶은 에이전트가 있다고 하자. 이때 검색은 허용하되 외부 전송은 승인 후에만 가능하게 하고, 사용자 식별 정보는 요약본에서 자동 마스킹하며, 모든 툴 호출을 로그로 남기는 식으로 정책을 나눌 필요가 있다.

도입 순서도 현실적으로 정리할 수 있다. 먼저 에이전트가 호출하는 툴 목록을 만들고, 각 툴마다 허용 액션과 금지 액션을 분리한다. 다음으로 인간 승인 조건을 정의한다. 마지막으로 데이터 노출 범위를 정한다. 이 순서가 중요한 이유는 모델 추론보다 툴 권한이 실제 피해로 이어지는 경우가 더 직접적이기 때문이다.

오늘 바로 할 일

• 에이전트가 호출하는 모든 툴에 대해 “실행 전 인터셉션이 있는가”를 점검하라.
• 고위험 액션에는 사람 승인 트리거를 넣고, 승인 없이 통과하는 예외 경로를 제거하라.
• 출력 필터만 볼 것이 아니라 입력·메모리·툴 응답 단계별 데이터 노출 규칙과 감사 로그를 분리해 설계하라.

FAQ

Q. 정책-as-code만 도입하면 에이전트 보안 문제가 해결되나?
그렇지 않습니다. 정책을 어디에 두느냐보다 어디에서 집행하느냐가 더 중요합니다. 프롬프트 지침만으로는 강한 집행을 기대하기 어렵고, 실제 툴 호출 직전의 인터셉션이나 프록시 같은 구조가 있어야 차단력이 높아집니다.

Q. 기존 에이전트 프레임워크와 충돌하지 않나?
조사 결과 기준으로는 충돌보다 결합 가능성이 더 큽니다. 정책·승인·데이터 보호를 미들웨어 계층에 붙이는 방식이어서, 기존 프레임워크의 오케스트레이션 위에 통제 레이어를 얹는 구성이 가능합니다.

Q. 인간 승인을 많이 넣으면 자동화 이점이 사라지지 않나?
그럴 수 있습니다. 그래서 모든 단계에 승인을 넣기보다 권한 상승, 외부 전송, 민감정보 접근처럼 사고 비용이 큰 액션에만 선택적으로 거는 설계가 현실적입니다. 핵심은 승인 수를 늘리는 것이 아니라 승인 지점을 정확히 고르는 것입니다.

결론

이 논의의 중심은 더 똑똑한 에이전트를 만드는 법이 아니라, 더 통제 가능한 에이전트를 배포하는 법이다. 범용 에이전트 위에 정책 계층을 분리하는 접근은 관심을 끌 수 있다. 다만 핵심은 정책 문법 자체보다 실행 경로에서의 집행력과 감사 가능성에 있다.

다음으로 읽기

• AI 자료 모음 (24h) - 2026-05-23
• AI 자료 모음 (24h) - 2026-05-22
• MOCHA로 본 스킬 최적화
• 멀티모델 LLM 스케줄링 핵심
• AI 자료 모음 (24h) - 2026-05-20

참고 자료

• AI RMF Core - AIRC - airc.nist.gov
• Taming Various Privilege Escalation in LLM-Based Agent Systems: A Mandatory Access Control Framework - arxiv.org
• Your LLM Agent Can Leak Your Data: Data Exfiltration via Backdoored Tool Use - arxiv.org
• arxiv.org - arxiv.org