Abnormal AI가 직원과 에이전트를 함께 감시한다…정식 제품은 하나뿐
실용 가이드 1
Microsoft, AI 에이전트를 ‘내부자’로 규정…별도 감시가 시작됐다
Microsoft Security 총괄 부사장 하예테 갈로는 2026년 10월 19일 Microsoft의 공식 발표에서 기업이 배치한 AI 에이전트를 “They are agentic insiders.”라고 규정하고, Project Perception에 Guardian Agents를 더하는 구상을 공개했다. 회사가 업무를 맡기고 데이터와 도구에 접근하도록 허용한 에이전트의 행동을 지속적으로 살피며, 위험에 따라 행동 권한을 조정하겠다는 내용이다.
TechCrunch의 같은 날 보도는 Guardian Agents를 Project Perception에 추가되는 기능으로 설명하며, 모델을 공급하는 쪽과 에이전트의 행동을 감시·통제하는 쪽을 분리하자는 주목했다. 발표된 것은 감시와 대응 체계를 확장하는 설계다. 기업 보안팀에 중요한 질문은 에이전트가 업무를 수행하는 도중 누가 접근 권한을 바꾸고, 그 결정이 실제 실행 경로에서 강제되는가다.
감시 대상은 이미 권한을 받은 에이전트의 행동
Guardian Agents가 살피려는 것은 에이전트가 생성한 답변의 문장만이 아니다. 어떤 신원으로 실행되는지, 어느 데이터와 도구에 접근하는지, 맡은 업무에서 벗어난 행동을 시도하는지, 그때 위험이 어떻게 달라지는지가 통제 대상이다. 처음에는 적절했던 접근 권한도 업무 중 들어온 정보와 바뀐 맥락에 따라 과도해질 수 있다는 전제가 깔려 있다.
여기서 ‘내부자’는 에이전트에게 직원과 같은 의도가 있다는 뜻이 아니라, 기업 안에서 이미 권한을 부여받아 중요한 시스템에 영향을 줄 수 있다는 보안상의 위치를 가리킨다. 에이전트는 모델의 판단에 따라 도구를 연속 호출하고 작업 계획을 바꿀 수 있다. 따라서 배치할 때 정한 권한만으로 진행 중인 모든 행동의 위험을 설명하기는 어렵다.
Project Perception은 원래 기업 외부에서 벌어지는 AI 기반 공격에 대응하기 위해 소개됐다. 이번 구상은 신호를 모으고 위험을 판단해 대응하는 구조를 기업이 직접 배치한 에이전트에도 적용한다. 감시 범위가 외부 공격에서 내부 실행으로 넓어지면서, 에이전트가 다음 행동을 하기 전에 권한을 제한할 수 있는지가 관건이 됐다.
발견한 에이전트에 별도 신원을 부여한다
Microsoft Security의 기술 설명에 따르면 로컬 에이전트 탐지 지원 대상은 35종이 추가돼 총 60종이 됐으며, Claude Code, OpenAI Codex, GitHub Copilot이 포함된다. 이 수치는 탐지할 수 있는 에이전트 유형의 범위다. 기업에 존재하는 모든 에이전트가 발견되거나 같은 방식으로 제어된다는 뜻은 아니어서, 실제 배치 경로별 탐지 범위가 중요하다.
발견된 에이전트는 통합 등록부에서 소유자, 활동, 위험과 연결하도록 설계됐다. 그다음 필요한 것은 에이전트를 이를 사용하는 사람과 구별하는 지속적인 신원이다. 사용자 계정을 그대로 물려받아 작업하면 사람이 직접 한 일과 에이전트가 대신 한 일을 분리하기 어렵고, 에이전트에만 적용할 정책의 대상도 흐려진다.
Microsoft Entra Agent ID의 확장 방향에는 로컬에서 발견됐거나 기존 통합 절차를 거치지 않은 에이전트에도 신원 유형을 부여하는 내용이 포함된다. 자산 목록에 이름을 올리는 데서 그치지 않고, 특정 에이전트의 권한과 위험을 계속 연결하기 위한 장치다. 업무가 바뀌어 권한을 줄여야 할 때에도 통제 시스템이 같은 주체를 식별할 수 있어야 한다.
위험이 달라지면 실행 전에 권한도 바뀐다
Project Perception 구상의 다음 고리는 관찰한 신호를 현재의 행동 허용 범위에 연결하는 것이다. Dynamic Agent Risk는 신원, 데이터, 기기, 클라우드, 네트워크, 실행 환경과 에이전트 활동을 함께 살펴 위험을 계속 갱신하도록 설계됐다. 같은 에이전트라도 무엇을 읽거나 바꾸려는지, 어떤 도구를 호출하는지에 따라 필요한 통제가 달라질 수 있다.
Dynamic Permissions는 에이전트가 사용자의 모든 권한을 상속하는 대신 승인된 업무에 필요한 범위와 기간에 맞춰 권한을 받도록 하는 구상이다. 위험이 커지면 Dynamic Conditional Access는 읽기를 유지하면서 쓰기를 막거나, 접근할 수 있는 자원을 좁히고, 임시 권한을 단축·철회하는 대응을 맡는다. 영향이 큰 행동에는 확인 가능한 사람의 승인을 요구하고, 위험이 더 커지면 실행 환경을 격리하거나 작동을 멈추는 방식도 제시됐다.
예를 들어 비용 승인 에이전트가 업무와 무관한 작업을 시도했다면, 신청 내용을 읽을 권한은 남기되 승인이나 수정 권한은 보류할 수 있다는 설명이다. 이는 모든 위험 신호에 에이전트를 완전히 중지시키는 방식보다 세밀한 통제다. 다만 이런 조정이 효력을 가지려면 정책을 판단하는 곳뿐 아니라 데이터 접근과 도구 호출을 실제로 막는 집행 지점도 에이전트의 실행 경로에 있어야 한다.
Guardian Agents가 조사하고, 사람은 승인 경계를 정한다
Guardian Agents는 위험이 바뀐 이유를 조사하고 관련 증거를 모아 억제 조치를 권고하거나 적용하는 역할로 제시됐다. 함께 소개된 Playbooks는 사람이 정한 목표, 승인 경계와 위임 규칙에 맞춰 대응을 조정한다. 반복적인 감시와 초기 대응을 자동화하더라도 영향이 큰 결정에 대한 권한은 사람이 갖는 구조다.
이 역할은 기존의 경고를 보안팀에 전달하는 기능과 차이가 있다. Guardian Agents가 위험 변화에 맞춰 대응을 이어 가고, 권한 통제 계층이 다음 행동의 허용 범위를 바꾼다는 점이다. 에이전트를 멈추는 것과 특정 도구 호출만 보류하는 것은 업무에 미치는 영향이 다르므로, 단계별 대응에는 명확한 정책과 집행 경계가 필요하다.
더 깊은 모델 내부 신호를 위험 판단에 활용하는 방향도 제시됐다. 작업 의도에서 벗어나는 징후를 파악하는 데 도움이 될 수 있지만, 모델 내부를 관찰하는 능력과 접근 권한을 강제하는 능력은 서로 다른 문제다. 모델이 스스로 감시 정책을 바꾸거나 집행 장치를 우회할 수 없다면, 판단에 쓰이는 증거가 늘어나더라도 기업의 권한 통제는 모델 바깥에 남는다.
모델 공급자와 통제자를 분리하려면
모델 공급자의 안전 약속에 기업의 승인·차단 권한까지 맡기지 말자는 주장은 통제의 독립성에 관한 것이다. 모델이 업무를 판단하더라도 어떤 데이터에 접근하고 어떤 행동을 실행할지는 기업의 정책이 결정해야 한다. 이 정책과 집행 지점이 모델의 수정 범위 밖에 있어야 에이전트가 자신의 권한이나 감시 기록을 임의로 바꾸지 못한다.
Microsoft는 AI 모델과 에이전트 관련 사업을 운영하면서 보안 제품도 판매한다. 따라서 별도 통제 계층이라는 설계 원칙만으로 공급업체의 이해관계가 사라지는 것은 아니다. 기업 보안팀에는 누가 위험 기준과 정책을 변경할 수 있는지, 다른 공급자의 에이전트에도 같은 통제가 적용되는지, 긴급 권한 회수와 사람 승인이 실제 호출을 멈추는지가 구체적인 검증 항목이 된다.
감사 기록 역시 그 집행력을 드러내야 한다. 에이전트 신원, 요청한 작업, 적용된 정책, 승인자와 권한 변경 시점이 이어져야 사고 뒤에 행동을 재구성할 수 있다. 이번 발표는 추적 가능성을 목표로 제시했지만, 고객 환경별 로그의 완전성과 통제 결과는 공개된 발표만으로 확인할 수 없다. 제품 문서와 실제 배치에서 집행 범위가 드러날 때, 기업은 이 감시 계층이 기존 경고 체계를 얼마나 넘어서는지 판단할 수 있다.
함께 읽기:
관련 기사
뉴스레터 구독
최신 Web3, AI, 암호화폐 뉴스를 이메일로 받아보세요.
0