Microsoft, Project Perception에 Guardian Agents 도입 — 에이전트 보안 자동화

SVIL - Singularity Visual Intelligence Lab 2026. 10. 20 15 min read

회사 시스템에 연결된 AI 에이전트는 실수하거나 외부 입력에 흔들릴 수 있습니다. Microsoft는 Project Perception의 Guardian Agents와 동적 권한 조절로 에이전트 보안을 다루겠다고 밝혔습니다.

에이전트를 내부자 위험으로 보는 Microsoft의 변화

Microsoft는 기업 안에서 데이터를 읽고 도구를 호출하며 업무 시스템에 조치를 남기는 AI 에이전트를 새로운 내부 위험으로 설명했습니다. 외부 공격자가 침투하지 않아도 에이전트가 과도한 권한을 가진 채 의도와 다르게 움직일 수 있다는 주장입니다.

이는 에이전트를 악의적 행위자로 규정한다기보다, 권한이 있는 소프트웨어의 행동을 계속 관찰해야 한다는 보안 관점입니다. 실제 위험은 모델뿐 아니라 연결된 도구와 실행 환경에서 생깁니다.

Project Perception은 7월 발표에서 출발했습니다

Microsoft의 10월 글은 Project Perception이 이미 발표된 에이전트 보안 체계라고 밝히며, 이번에는 기업 내부에서 움직이는 에이전트를 관리하는 방향으로 확장한다고 설명합니다.

따라서 이번 소식은 완전히 새 제품이 처음 만들어졌다는 발표가 아닙니다. 기존 보안 프로젝트에 내부 에이전트 탐지와 지속 감독의 활용 방향을 더한 업데이트로 읽는 편이 맞습니다.

Guardian Agents는 무엇을 맡는다고 하나

Microsoft는 Guardian Agents를 에이전트 행동을 계속 살피고 위험이 커질 때 대응하도록 돕는 보안 에이전트 팀으로 소개했습니다. 모델과 도구가 만든 행동을 분석하고, 정해진 정책에 맞춰 조치하는 역할입니다.

회사 설명은 보호 자동화의 제품 구상입니다. 이 명칭이나 설명만으로 모든 에이전트 행동이 사전에 완벽히 차단된다고 볼 수는 없습니다.

사람이 목표와 승인 경계를 정합니다

Microsoft Security Blog는 Playbooks와 Guardian Agents가 정책, 승인 경계, 위임 규칙 안에서 작동하도록 설계한다고 설명합니다. 사람은 보호 목표와 중요한 결정의 책임을 계속 가집니다.

자동 대응은 사람의 판단을 완전히 대신하는 구조로 제시되지 않았습니다. 실제 제품에서 어떤 조치가 자동화되고 어느 지점에 승인이 필요한지 구성별로 확인해야 합니다.

위험은 행동과 맥락에 따라 달라집니다

Microsoft는 에이전트가 접근하는 데이터, 도구, 시스템, 실행 위치를 함께 살펴 동적으로 위험을 평가하는 구상을 설명했습니다. 같은 도구 호출도 상황과 권한 범위에 따라 위험도가 달라질 수 있습니다.

이 접근에는 신호의 품질과 맥락 추론이 중요합니다. 관측하지 못한 도구나 외부 에이전트가 있으면 위험 평가도 불완전해질 수 있습니다.

각 에이전트에 식별 가능한 신원이 필요합니다

Microsoft Entra Agent ID는 에이전트와 사람·서비스 계정을 구분하는 식별 및 권한 관리 기능을 제공합니다. 관리자에게는 소유자와 스폰서, 권한, 생성 경로를 연결해 관리할 수 있는 기반이 됩니다.

에이전트별 신원은 누가 어떤 행동을 했는지 감사하는 데 유용합니다. 다만 신원을 만들어 두는 것만으로 과도한 권한이나 정책 위반이 해결되는 것은 아닙니다.

사용자 대신 행동하는 에이전트와 자율 에이전트는 다릅니다

Entra 문서는 사용자 문맥을 빌려 행동하는 에이전트와 자체 신원으로 자율적으로 움직이는 에이전트를 구분합니다. 인증과 권한 부여도 각 방식에 맞춰 설계해야 합니다.

이 차이를 흐리면 실행 기록을 사람 행동으로 오해하거나, 에이전트가 필요 이상으로 넓은 접근을 얻게 될 수 있습니다. 작업 방식이 바뀌면 신원 모델도 다시 검토해야 합니다.

Playbooks는 반복 가능한 보안 대응을 구성합니다

Microsoft는 Playbooks를 원하는 보안 결과와 대응 흐름을 정의하는 방식으로 설명했습니다. Guardian Agents가 관련 증거를 모으고 대응 권고나 정책에 따른 조치를 수행할 수 있습니다.

플레이북이 실제 환경에서 어떤 조건으로 활성화되는지는 중요한 운영 세부사항입니다. 오탐, 승인 실패, 롤백이 어떻게 처리되는지도 공개된 구체 자료를 확인해야 합니다.

Defender는 에이전트 탐지를 넓히는 축입니다

보도와 Microsoft의 설명에 따르면 Defender에는 직원이 업무 환경으로 가져온 여러 에이전트를 식별하는 기능이 추가됩니다. TechCrunch는 약 60종을 탐지할 수 있다고 보도했습니다.

약 60종이라는 수치는 보도 시점의 제품 설명에 기반합니다. 모든 에이전트나 자체 제작 도구가 빠짐없이 탐지된다는 보장은 아니므로 적용 범위와 지원 버전을 확인해야 합니다.

미등록 에이전트는 가시성의 빈틈을 만듭니다

직원이 개인적으로 설치한 코딩 도구나 사내에서 만든 에이전트는 중앙 목록에 나타나지 않을 수 있습니다. 알려진 에이전트만 관리하면 조직 안의 실제 실행 주체를 놓칠 수 있습니다.

발견 기능은 첫 단계입니다. 이후 등록, 소유자 지정, 권한 축소, 데이터 접근 정책을 연결해야 관리 가능한 자산이 됩니다.

행동 관찰과 차단은 다른 기능입니다

시스템이 에이전트의 행동을 기록한다고 해서 모든 행동을 사전에 막는 것은 아닙니다. 모니터링, 정책 판단, 승인 요청, 실제 실행 취소는 각각 다른 능력입니다.

도입 검토에서는 각 기능이 제품의 어떤 구성 요소에 포함되는지 따져야 합니다. 단순 경고를 실시간 차단으로 이해하면 보안 수준을 잘못 평가할 수 있습니다.

권한은 작업에 필요한 최소 범위로 줘야 합니다

에이전트는 문서 검색, 코드 실행, 메시지 전송, 결제 같은 도구 권한을 조합할 수 있습니다. 불필요한 권한이 많으면 예상하지 못한 연쇄 행동이 더 큰 피해로 이어질 수 있습니다.

Microsoft의 신원 관리 접근과 관계없이 조직은 역할별 허용 범위, 사용자 위임, 민감한 행동의 승인 기준을 별도로 정의해야 합니다.

모델이 낸 계획보다 실제 도구 호출을 살펴야 합니다

에이전트의 위험은 답변 문장에만 드러나지 않습니다. 파일 읽기, 외부 연결, 코드 실행, 권한 변경처럼 시스템에 영향을 주는 실제 행동을 관측해야 합니다.

제품 소개에서 설명하는 ‘이유를 이해한다’는 기능은 어떤 로그와 증거를 바탕으로 하는지 확인이 필요합니다. 내부 추론을 모두 볼 수 있다는 뜻으로 확대해서는 안 됩니다.

연속 감독에는 신호의 출처가 중요합니다

보안 시스템은 ID, 클라우드, 네트워크, 데이터, 엔드포인트, 런타임에서 신호를 가져와 에이전트의 활동을 묶는다고 설명합니다. 신호가 분리되면 한 행동의 전체 흐름이 보이지 않을 수 있습니다.

조직마다 사용하는 제품과 로그 보존 기간이 다르므로, 연결 가능한 데이터의 범위와 누락 구간을 실사해야 합니다.

자동 격리는 서비스 장애를 만들 수도 있습니다

위험 점수가 높을 때 에이전트를 격리하거나 권한을 줄이면 피해를 막는 데 도움이 될 수 있습니다. 동시에 중요한 업무 흐름이 멈추거나 진행 중인 작업이 손상될 수 있습니다.

운영자는 어떤 수준에서 자동 차단할지, 사람 승인을 거칠지, 긴급 해제와 복구는 어떻게 할지 사전에 정해야 합니다.

사고 뒤에는 감사 가능한 기록이 남아야 합니다

관리자가 원인과 대응을 검토하려면 에이전트 신원, 사용한 도구, 적용된 정책, 위험 신호, 승인 여부를 시간순으로 볼 수 있어야 합니다.

기록은 조사뿐 아니라 정책을 다시 다듬는 기반입니다. 로그 접근, 보존, 민감 정보 마스킹도 시스템 설계에 포함해야 합니다.

기업 데이터 보호와 에이전트 감시는 한 흐름입니다

에이전트가 접근하는 문서와 서비스가 늘면 누가 데이터를 읽고 어떤 결과물을 외부로 보냈는지 확인하기 어려워집니다. 보안 통제는 에이전트 신원과 데이터 권한을 함께 연결해야 합니다.

감시 도구만 추가하면 데이터 사용 기준이 자동으로 정해지지 않습니다. 데이터 민감도, 반출 허용, 보존 정책을 별도로 반영해야 합니다.

협업하는 에이전트도 각각 책임을 나눠야 합니다

한 에이전트가 다른 에이전트에 작업을 넘기면 처음 요청한 목표와 실제 실행 주체 사이에 여러 단계가 생깁니다. 각 단계의 위임과 권한을 추적할 수 있어야 합니다.

최종 결과만 기록하면 문제가 시작된 지점을 놓칠 수 있습니다. 호출 체인과 각 에이전트가 받은 범위를 기록하는 것이 중요합니다.

오탐과 미탐은 모두 운영 비용입니다

위험을 과하게 판정하면 정당한 작업이 중단되고, 부족하게 판정하면 민감한 행동이 지나갈 수 있습니다. 탐지 정확도와 대응 지연을 실제 조직 작업으로 평가해야 합니다.

벤더의 기능 설명만으로 두 오류의 균형을 판단하기 어렵습니다. 파일럿 환경에서 허용·차단 사례와 복구 절차를 측정할 필요가 있습니다.

Guardian Agents의 자동화 범위는 구성에 달려 있습니다

Microsoft는 Guardian Agents가 위험에 맞춰 권고하거나 정책에 따라 행동할 수 있다고 설명합니다. 실제 적용 범위는 조직이 설정한 정책, 연결된 시스템, 제품 구성에 좌우됩니다.

모든 고객에게 동일한 자동화가 제공된다고 가정해서는 안 됩니다. 발표 글의 구상과 현재 구독자가 쓸 수 있는 기능은 구분해 확인해야 합니다.

가용 일정과 라이선스는 실제 제품 문서에서 봐야 합니다

10월 19일 발표는 제품 방향과 관리 체계의 확장을 설명하지만 모든 세부 기능의 일반 제공 일정을 제시하지는 않습니다. Entra Agent ID와 Agent 365, Defender 기능의 조건도 각각 다를 수 있습니다.

조직은 현재 계약과 테넌트에서 사용할 수 있는 기능을 공식 문서와 관리 화면으로 확인해야 합니다. 보도에 적힌 계획을 즉시 활성화된 기능으로 간주하지 않는 것이 안전합니다.

보안 책임은 공급사 기능으로 이전되지 않습니다

에이전트 보안 기능이 생겨도 조직은 목표, 접근 권한, 개인정보 처리, 고객 영향에 대한 책임을 계속 집니다. 자동화는 통제를 돕는 도구이지 책임 주체가 아닙니다.

특히 금융·의료·인사 같은 민감 업무에서는 사람의 검토, 이의 제기, 비상 중단 경로를 업무 설계 안에 남겨야 합니다.

핵심 정리

Microsoft는 Project Perception에 Playbooks와 Guardian Agents를 더해 기업 내부 에이전트를 지속적으로 관찰하고 위험에 대응하는 구상을 공개했습니다. Entra Agent ID와 Defender의 탐지는 그 운영 기반을 보완합니다.

발표는 보안 에이전트가 모든 위험을 자동으로 없앤다는 보증이 아닙니다. 신원·최소 권한·기록·사람 승인·복구 경로가 함께 있어야 실제 통제가 됩니다.

권한 목록은 계속 관리해야 합니다

에이전트가 늘고 역할이 바뀌면, 누가 만들었고 무엇에 접근하는지 기록도 낡을 수 있습니다. Microsoft는 소유자, 목적, 활동, 권한을 볼 수 있도록 통합 등록부와 지속적인 검색을 제안합니다.

이 목록은 등록 순간만 확인하는 표가 아닙니다. 작업이 끝나거나 위험이 바뀌면 권한을 줄이고 회수하는 운영 절차와 연결되어야 합니다.

출처

협업 문의: kuroicode@gmail.com · 블로그 · 홈페이지