마이크로소프트(Microsoft), 사내 AI 에이전트의 권한·위험 관리 확대

이번 확장은 퍼셉션의 출발점과 연결된다. 마이크로소프트는 7월 27일 최초 발표에서 공격 경로를 찾는 레드팀, 위험을 조사하는 블루팀, 수정 조치를 수행하는 그린팀 에이전트를 제시했다. 당시에는 외부 공격에 대응하는 보안 조직의 작업을 중심에 뒀다. 10월 발표에서는 이 체계를 조직이 직접 배치한 에이전트의 행동을 감독하는 데도 적용하겠다고 설명했다.

문제의식은 공격자가 침입한 경우에만 한정되지 않는다. 같은 날 경영진이 공개한 설명은 목표 달성에 최적화된 모델의 행동이 조직의 규범과 어긋날 수 있다고 지적한다. 모델, 작업을 조정하는 소프트웨어, 사용 가능한 도구, 실행 환경을 하나의 시스템으로 보고 각각 통제해야 한다는 주장이다. 이는 회사가 제시한 보안 관점이며 모든 에이전트가 문제를 일으킨다는 실증 결과는 아니다.

구체적인 확대 항목은 목록화다. 회사는 로컬 에이전트 발견 대상을 35종 추가해 총 60종으로 넓히고, 마이크로소프트 에이전트 365(Microsoft Agent 365)와 등록부·보안 정보를 공유한다고 밝혔다. 다만 발견 수 자체가 차단 능력이나 사고 감소율을 뜻하지는 않는다.

새로 소개한 동적 권한(Dynamic Permissions)은 업무에 필요한 범위와 시간에 맞춰 권한을 부여한다. 조직 정책이 상한을 정하고, 사용자 자신에게 없는 권한은 에이전트에도 부여하지 않는다는 원칙이다. 직원의 전체 접근 권한과 에이전트의 작업 권한을 분리하는 설계다.

동적 에이전트 위험(Dynamic Agent Risk)은 보안 정보를 모아 위험을 갱신하고, 동적 조건부 액세스(Dynamic Conditional Access)는 이에 맞춰 허용 행동을 조절한다. 회사는 읽기를 유지하면서 쓰기를 막거나 실행을 격리하는 대응을 제시했다. 위험 변화마다 같은 종료 조치를 내리는 대신 단계적으로 통제한다.

별도 신원을 관리하는 기반은 마이크로소프트 엔트라 에이전트 ID(Microsoft Entra Agent ID) 문서에서 확인할 수 있다. 개별 에이전트의 신원을 만드는 공통 틀을 두고 인증·활동 기록을 관리한다. 자사 플랫폼 밖에서 만든 에이전트의 연동도 설명한다. 다만 신원 생성 기능을 쓸 수 있다는 사실과 보안 기능 전체를 적용할 수 있다는 사실은 다르다. 해당 문서는 에이전트에 엔트라 보안 기능을 확장하려면 에이전트 365가 필요하다고 명시한다.

공식 지원표는 발표를 해석하는 데 중요한 경계를 보여준다. 로컬 에이전트 발견은 관리 대상 장치에서 실제 활동이 관찰돼야 이뤄진다. 프로그램이 설치돼 있다는 사실만으로 목록에 나타나는 것은 아니다. 또한 윈도 서브시스템 포 리눅스(Windows Subsystem for Linux) 지원은 일반 리눅스 장치 지원과 같지 않으며, 맥OS(macOS)의 발견 기능도 미리보기로 표기돼 있다.

같은 문서는 실행 중 보호를 별도 항목으로 구분한다. 에이전트가 제공하는 이벤트 인터페이스로 관찰하는 방법과 네트워크 통신을 검사하는 방법의 지원 범위가 다르다. 서버 인증서를 특정 값으로 고정하거나 HTTP/3 통신을 쓰는 에이전트는 네트워크 검사 대상에서 제외된다고 명시한다. 따라서 ‘발견 60종’이라는 발표를 60종 전체에 동일한 실시간 방어가 적용된다는 뜻으로 확대하면 안 된다. 문서의 마지막 갱신 표시는 10월 9일로, 이날 발표의 모든 세부 사항을 반영했다고 단정하기도 어렵다.

보안 에이전트를 다시 감독자로 투입한다는 점도 쟁점이다. 경영진 설명은 모델의 입출력뿐 아니라 추론 과정의 투명성이 더 필요하다고 주장하면서도, 그것이 격리와 권한 통제를 대체하지는 않는다고 밝혔다. 편집 관점에서 이번 변화의 핵심은 AI가 스스로 안전하다고 판단하는 데 의존하기보다 별도 시스템이 행동을 제한하도록 책임을 배치한 데 있다. 이 구조의 효과를 판단하려면 각 고객 환경에서 수집할 수 있는 신호와 실제 집행 가능한 통제를 함께 봐야 한다.