AI 에이전트의 위험은 답변보다 행동에서 커집니다. 메일을 보내고, DB를 조회하고, 파일을 삭제하고, 다른 에이전트에 일을 넘기는 순간부터는 “프롬프트로 조심시키기”만으로 부족합니다.
Microsoft Agent Governance Toolkit, AGT는 이 지점에 붙는 거버넌스 도구입니다. 에이전트가 도구를 직접 실행하지 않고, 실행 전에 신원, 정책, 위험, 민감도, 감사 요건을 확인하도록 만드는 실행 통제 계층에 가깝습니다.
핵심 질문은 단순합니다.
이 에이전트가 지금 이 도구를, 이 맥락에서, 이 수준의 권한으로 실행해도 되는가?
AGT는 에이전트의 “행동”을 통제한다
AGT는 PyPI에 Microsoft 서명 공개 프리뷰 패키지로 제공됩니다.1 전체 스택 설치 명령은 다음과 같습니다.
pip install agent-governance-toolkit[full]다만 공개 프리뷰 단계이므로 GA 이전에 API가 변경될 수 있다는 점은 감안해야 합니다.1
AGT를 이해할 때는 하나의 라이브러리라기보다 여러 구성요소를 묶은 거버넌스 스택으로 보는 편이 좋습니다. AGT 메타 패키지는 Agent OS, AgentMesh, Agent Runtime, Agent SRE를 함께 설치하는 통합 패키지입니다.1
각 구성요소의 역할은 다음처럼 나눌 수 있습니다.
Agent OS: 정책 엔진, 기능 모델, 감사 로깅, 시스템 호출 계층을 담당합니다.1
AgentMesh: 제로 트러스트 신원, 에이전트 간 mTLS, 암호화 채널, 신뢰 점수를 제공합니다.1
Agent Runtime: 실행 링, 리소스 제한, 런타임 샌드박싱, 킬 스위치를 담당합니다.1
Agent SRE: 상태 모니터링, SLO 적용, 사고 대응, 카오스 엔지니어링을 담당합니다.1
기본 설치는 커널과 트러스트 메시를 포함하고, full 옵션은 런타임과 SRE까지 추가합니다.1 따라서 실험 단계에서는 최소 구성으로 시작하고, 운영에 가까워질수록 런타임 격리와 관측, 사고 대응 기능을 확장하는 식으로 접근할 수 있습니다.
정책은 프롬프트가 아니라 실행 경로에 있어야 한다
AGT의 중요한 전제는 에이전트가 도구를 바로 실행하지 않는다는 것입니다. 에이전트가 어떤 작업을 요청하면, 그 요청은 먼저 거버넌스 계층을 거칩니다. 이 계층은 에이전트 신원, 신뢰 점수, 위험 등급, 요청 도구, 작업 유형, 민감도 수준 같은 실행 컨텍스트를 확인한 뒤 허용 여부를 판단합니다.
이 차이는 큽니다. 프롬프트 지침은 모델이 따르기를 기대하는 규칙입니다. 반면 실행 경로의 정책은 실제 호출을 막거나 승인 절차로 돌릴 수 있는 통제 지점입니다.
예를 들어 delete_file, send_email, drop_table처럼 영향이 큰 작업은 정책에서 차단하거나 별도 승인 대상으로 지정할 수 있습니다.2 에이전트가 그럴듯한 이유를 제시하더라도 정책 계층이 거부하면 실행되지 않습니다.
AGT의 정책 평가는 Agent OS의 StatelessKernel을 통해 실행 컨텍스트와 함께 수행될 수 있습니다.1 즉 “무슨 도구인가”만 보는 것이 아니라, “누가, 어떤 상황에서, 어떤 위험 수준의 작업을 요청했는가”까지 함께 판단하는 구조입니다.
기존 에이전트 프레임워크를 대체하기보다 보강한다
AGT는 에이전트 프레임워크 자체를 대체하려는 도구라기보다, 그 위에 행동 통제 레이어를 추가하는 접근에 가깝습니다.
Microsoft Agent Framework와 함께 사용할 때는 미들웨어 파이프라인에 붙어 도구 호출, 리소스 접근, 에이전트 간 메시지를 실행 전에 검사하는 방식으로 동작합니다.3 이 구조 덕분에 에이전트의 추론과 실행을 분리해 볼 수 있습니다.
에이전트는 목표를 해석하고 다음 행동을 제안합니다.
거버넌스 계층은 그 행동이 정책상 가능한지 판단합니다.
허용된 작업만 실제 도구 호출로 이어집니다.
판단과 실행 결과는 감사 가능한 형태로 남습니다.
이렇게 하면 에이전트가 더 복잡해져도 통제 기준을 모델 내부에만 의존하지 않아도 됩니다.
실습에서는 작게 시작하는 편이 좋다
AGT를 처음 다룰 때 모든 기능을 한 번에 켤 필요는 없습니다. Google Colab 같은 실습 환경에서는 먼저 간단한 도구 호출을 거버넌스 계층으로 감싸고, 정책 평가가 어떻게 동작하는지 확인하는 것부터 시작하는 편이 현실적입니다.
초기 실습에서 확인할 핵심은 다음입니다.
에이전트가 도구를 직접 실행하지 않도록 한다.
각 작업 요청을 거버넌스 계층으로 보낸다.
요청 컨텍스트에 신원, 신뢰 점수, 위험 등급, 도구 이름, 작업 유형, 민감도 수준을 포함한다.
정책 평가 결과에 따라 허용, 거부, 승인 요청으로 분기한다.
판단 결과와 실행 결과를 감사 로그로 남긴다.
이 정도만 구현해도 AGT의 핵심 개념은 분명해집니다. 에이전트 안전은 “답변을 더 조심스럽게 생성하는 문제”가 아니라 “실행을 어떤 조건에서 허가할 것인가의 문제”입니다.
운영 적용 기준: 위험한 행동부터 통제한다
실제 적용에서는 모든 도구를 같은 수준으로 통제할 필요가 없습니다. 먼저 위험도가 높은 작업부터 분류하는 것이 좋습니다.
우선순위가 높은 대상은 보통 다음과 같습니다.
민감 데이터 조회 또는 전송
유료 API 호출
파일 생성, 수정, 삭제
데이터베이스 변경
인프라 조작
외부 메시지 발송
다른 에이전트로의 작업 위임
위험이 낮은 실험이라면 정책 평가와 감사 로그부터 시작할 수 있습니다. 민감 데이터, 유료 API, 인프라 조작, 다중 에이전트 위임이 들어가면 신원 확인, 신뢰 점수, 승인 워크플로, 샌드박싱, 킬 스위치까지 단계적으로 붙이는 편이 안전합니다.
운영 환경에서 특히 중요한 것은 “어떤 에이전트가, 어떤 정책 아래, 왜 허용됐는가”를 남기는 것입니다. AGT 문서는 감사 가능성과 의사결정 추적을 주요 목표로 제시합니다.4 장애나 규제 대응 상황에서 “AI가 그렇게 했다”는 설명만으로는 충분하지 않기 때문입니다.
결론: 에이전트 안전은 모델 밖에서 완성된다
AGT가 주는 메시지는 명확합니다. AI 에이전트의 안전은 모델 프롬프트만으로 해결되지 않습니다. 실제 위험은 도구 호출, 리소스 접근, 에이전트 간 위임처럼 외부 세계에 영향을 주는 행동에서 발생합니다.
따라서 프로덕션 환경의 에이전트에는 실행 허가층이 필요합니다. 권한, 정책, 승인, 로그, 위험 평가를 도구 사용의 기본 경로에 넣어야 합니다.
Microsoft Agent Governance Toolkit은 그 구조를 실험하고 구현할 수 있는 참고점입니다. 공개 프리뷰 단계라 API 변경 가능성은 있지만, 에이전트 워크플로에 거버넌스를 어떻게 끼워 넣을지 이해하기에는 충분히 실용적인 출발점입니다.
1agent_governance_toolkit · PyPI
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.