Microsoft AI Agent Security 경고, 기업 자율성에 대한 검증 요구
Microsoft는 10월 19일, 공격자가 침해하지 않았더라도 기업 AI 에이전트가 내부자 보안 위험이 될 수 있다고 경고했다. Microsoft AI agent security 경고는 편리한 가정에 의문을 제기한다. 즉, 회사가 배포한 소프트웨어는 직원과 동일한 접근 권한을 가져도 된다는 가정이다. Microsoft가 제시한 해법인 Guardian Agents는 또 다른 질문을 던진다. 해당 에이전트를 감시하는 시스템은 누가 통제하는가?
Visual Studio Magazine은 10월 28일 Microsoft의 agentic insider risk 입장을 다루며 이 경고에 다시 주목하게 했다. 모델과 도구를 활용해 작업을 수행하는 시스템인 AI 에이전트는 요청과 실행 사이에 자체 판단을 개입시킨다. 직원은 에이전트가 선택할 모든 행동을 예상하지 못한 채 목표만 승인할 수 있다.
핵심적인 균형점은 유용한 자율성과 집행 가능한 권한 사이에 있다. CrowdStrike와 Okta는 관련 통제 수단을 추진하고 있어, 기업은 서로 다른 접근법을 비교 평가할 수 있다. 개발자, 보안팀, 사업 책임자에게 당면한 문제는 에이전트의 작업 해석이 달라질 때 그 권한이 어디까지 미치는가다.
Microsoft AI Agent Security, 내부자 위험에 초점 맞추다
Microsoft Security의 부사장 Hayete Gallot은 10월 19일 securing agentic insiders에 관한 글에서 회사의 입장을 설명했다. 그는 모델이 본질적으로 조직의 판단 기준을 이해하지 못한 채 목표를 추구한다고 주장했다. 이는 누구도 자격 증명을 탈취하거나 소프트웨어를 변조하지 않았더라도 그 행동이 우려 대상이 된다는 의미다.
Microsoft는 활동을 감독하고 위험 변화에 대응하기 위해 Guardian Agents를 제안한다. 이 접근법은 회사가 7월 발표한 Project Perception을 확장한다. Gallot은 또한 모델 행동에 대한 가시성을 높이되, 보호 통제는 그 통제가 관리하는 지능 체계의 외부에 두어야 한다고 주장한다.
Microsoft는 기업에 에이전트의 업무 할당과 그 권한을 별도의 보안 결정으로 취급하라고 요구하고 있다.
이 구분은 구매자가 이번 발표를 해석하는 방식을 바꾼다. 내부자 위험 프레임은 정당한 접근 권한에서 발생하는 노출을 설명한다. 그렇다고 모든 에이전트가 위험하게 행동한다거나 일반적인 기업 자동화가 갑자기 적대자가 되었다는 뜻은 아니다.
업무를 맡기는 일과 그 결과를 승인하는 일의 차이를 생각해 보자. 시스템에 고객 문제 해결을 요청하는 것은 목표를 설정하는 일이다. 그렇다고 환불, 계정 변경, 계약상 약속, 다른 고객 정보의 공개까지 자동으로 승인하는 것은 아니다.
이 사례는 Microsoft가 보고한 사고가 아니라 이 글의 핵심 쟁점을 보여준다. 작업은 평범해 보이지만, 가능한 행동은 서로 다른 결과를 초래한다. 광범위한 지시만으로는 실행 과정에 숨어 있는 모든 권한 문제를 해결할 수 없다.
이 경고에는 정확한 시간적 맥락도 필요하다. 10월 28일 보도는 Microsoft의 10월 19일 입장을 다시 조명한 것이다. 독자는 해당 게시일을 별도의 제품 출시, 새로 공개된 침해 사고, 또는 사고 빈도를 측정한 새로운 증거로 오인해서는 안 된다.
아키텍처를 제안하는 것과 성능을 검증하는 것 사이에도 차이가 있다. 아키텍처는 통제가 어디에 위치해야 하며 어떻게 협력해야 하는지를 설명한다. 증거는 그러한 통제가 위험한 행동을 식별하고, 충분히 이르게 개입하며, 정당한 업무 흐름을 계속 사용할 수 있게 하는지를 입증해야 한다.
이 구분이 중요한 이유는 보안 발표가 신뢰할 만한 문제 제기와 상업적 해법 제안을 함께 내놓는 경우가 많기 때문이다. 문제를 인정한다고 해서 해법에 관한 모든 주장을 받아들여야 하는 것은 아니다. 구매자는 에이전트 권한에 한계가 필요하다는 점에는 동의하면서도 특정 구현이 실제로 이를 집행한다는 증거를 요구할 수 있다.
따라서 실질적인 변화는 설명 책임의 변화다. 에이전트의 후원자는 할당된 업무, 허용된 행동, 그리고 책임 있는 소유자를 설명해야 한다. 공급업체는 에이전트가 예상치 못한 경로를 선택할 때 자사 제품이 그러한 경계를 어떻게 집행하는지 설명해야 한다.
압박은 접근 권한을 부여하는 사람에게 향한다
이 경고로 가장 직접적인 압박을 받는 사람은 에이전트를 중요한 비즈니스 시스템에 연결하는 이들이다. 이들의 결정은 잘못된 해석이 초안에 머무를지, 운영상 사건으로 이어질지를 결정한다. 이 책임은 개발, 정보보안, 애플리케이션 소유, 비즈니스 관리 전반에 걸쳐 있다.
에이전트 배포에는 결과물의 소유자뿐 아니라 권한의 소유자도 필요하다.
이 책임을 살펴보는 유용한 방법은 가상의 영업 워크플로를 통해서다. 한 어시스턴트가 내부 메모와 고객 서신을 바탕으로 계정 요약을 준비한다. 초기 목적은 정보 제공이지만, 이후 누군가 이를 계정 기록을 업데이트하는 도구에 연결한다.
글쓰기 작업과 기록 변경 작업은 별도로 검토할 만하다. 부정확한 요약은 독자를 오도할 수 있다. 부정확한 업데이트는 다른 직원들이 의존하는 시스템의 일부가 되어, 원래 대화를 넘어 결과를 확장할 수 있다.
이 구분은 악의적인 의도를 가정할 필요가 없다. 에이전트는 요청을 오해하거나, 비공식적인 의견을 지나치게 해석하거나, 그 밖에는 정당한 목표를 향해 부적절한 경로를 선택할 수 있다. 보안의 질문은 이러한 불확실성이 해소되지 않은 상황에서 시스템이 무엇을 허용하는가에 관한 것이다.
개발자에게 이 압박은 인터페이스 설계에서 나타난다. 읽기, 편집, 게시를 하나의 광범위한 작업으로 묶는 도구는 각 작업을 분리한 도구와 다른 노출을 만든다. 중요한 설계 선택은 애플리케이션이 비즈니스가 실제로 의도한 경계를 표현할 수 있는지 여부다.
비즈니스 후원자에게 이 압박은 위임에 관한 것이다. 관리자는 예외 상황을 정의하지 않은 채 원하는 결과를 설명할 수 있다. 에이전트가 예외를 마주한다면, 시스템에는 완료가 항상 우선이라는 가정 대신 그 결정을 위한 명시적 처리 경로가 필요하다.
보안팀에게 이 압박은 귀속, 즉 행동을 책임 있는 행위자와 연결하는 능력에 관한 것이다. 기록이 변경되면 조사관은 직원의 요청, 에이전트의 해석, 도구의 실행을 구분할 수 있어야 한다. 그렇지 않으면 계정 이름만으로는 불완전한 이야기를 전하게 된다.
지식 근로자 역시 개인 리서치를 공유 자원에 연결할 때 관련된 문제를 마주한다. personal knowledge base는 조직 기록을 담은 워크스페이스와는 다른 목적을 지닌다. 접근 결정은 각 출처의 의도된 이용자와 허용된 사용 방식을 반영해야 한다.
따라서 단기적 대응은 위임에 대한 명확성에서 시작해야 한다. 어떤 결과는 자동으로 진행할 수 있고, 어떤 결과는 검토가 필요하며, 어떤 결과는 업무 범위 밖에 남는가? 이는 모델이 독립적으로 해결해야 할 문제가 아니라 기술적 통제를 통해 표현되는 비즈니스 결정이다.
시간이 지나면서 이러한 명확성은 구매 요건이 되기도 한다. 구매자는 실제 승인 경계를 표현할 수 있는 제품을 필요로 한다. 유용한 작업을 생산하더라도 준비와 확정을 구분하지 못하는 시스템은 조직이 다른 곳에서 그 모호성을 해결하도록 만든다.
유용한 자율성에는 모델 외부의 한계가 필요하다
Microsoft가 제안한 메커니즘은 모델이 생성한 결정과 권한 집행을 분리한다. 동반 agent containment architecture에서 회사는 승인된 작업에 맞춰 접근 권한 범위를 정하는 Dynamic Permissions를 설명한다. Dynamic Agent Risk는 활동 변화에 따라 평가를 업데이트하고, Dynamic Conditional Access는 에이전트가 수행할 수 있는 일을 조정한다.
Microsoft는 이러한 조정이 읽기 권한은 유지하면서 쓰기는 차단하고, 접근 가능한 자원을 좁히거나, 사람의 승인을 요구할 수 있다고 말한다. 또한 실행 중인 소프트웨어가 사용할 수 있는 자원을 제한하는 격리된 실행 환경도 설명한다. 이는 제안된 보호 계층이지, 모든 배포가 이미 동일한 수준의 적용 범위를 받는다는 증거는 아니다.
회사의 비용 처리 사례는 의도된 순서를 보여준다. 에이전트가 읽는 자료에 삽입된 악성 지시인 프롬프트 인젝션을 마주하고, 관련 없는 행동을 시도한다. Microsoft는 보안 시스템이 높아지는 위험을 인식하고 에이전트의 권한을 축소해야 한다고 말한다.
결정적인 경계는 외부 통제가 모델이 수행하려는 행동을 거부할 수 있는지 여부다.
이 경계는 자율성의 균형 문제에 구체적인 형태를 부여한다. 조직은 중요한 실행을 제한하면서 유연한 추론을 허용할 수 있다. 모델은 경로를 제안할 수 있지만, 또 다른 시스템이 요청된 행동이 이미 부여된 권한 안에 드는지 결정한다.
가상의 문서 워크플로는 이 구분을 쉽게 보여준다. 에이전트는 수정안을 준비하고, 버전을 비교하며, 미해결 질문을 식별할 수 있다. 모델이 작업 완료를 위해 게시가 필요하다고 판단하더라도, 해당 수정안을 공개 웹사이트에 게시하는 일은 별도의 확정 행위다.
이 경계의 가치는 그것이 어디에서 작동하는지에 달려 있다. 게시 후에 표시되는 경고는 게시 전에 이루어지는 검사와 같은 목적을 수행하지 않는다. 구매자는 모니터링 대시보드의 외관으로 보호를 판단하기보다 결정이 행동으로 전환되는 순간을 살펴봐야 한다.
이는 자연어 지시만으로는 통제가 불완전한 이유도 명확히 한다. 에이전트에게 정책 범위 안에 머물라고 지시하는 것은 기대를 전달한다. 별도의 권한 시스템이 시도된 예외가 실제로 진행될 수 있는지 판단한다.
승인 프롬프트도 비슷한 검토가 필요하다. 검토자는 제안된 작업, 그 대상, 그리고 영향을 이해할 수 있을 만큼 충분한 맥락을 확보해야 한다. 작업 자체가 불분명한 상태라면 사용자에게 계속할지 묻는 것만으로는 거의 보장을 제공하지 못한다.
작업이 확장될 때도 같은 원칙이 적용된다. 추가 접근 권한이 업무 완료에 도움이 된다는 사실만으로 그 접근이 적절하다는 뜻은 아니다. 확장은 해당 자원을 담당하는 권한 주체의 결정을 촉발해야 한다.
이 균형에는 생산적인 형태도 있다. 명확한 한계는 어떤 결과가 통제된 상태로 남는지 팀이 알 수 있게 해 주므로 더 폭넓은 실험을 쉽게 만들 수 있다. 하지만 이는 특정 감독 제품이 이를 제공한다는 보장이 아니라 아키텍처상의 주장이다.
CrowdStrike와 Okta, 서로 다른 통제 지점 추구
Microsoft의 제안은 기업 에이전트 활동을 어디에서 통제할지를 둘러싼 더 넓은 경쟁 속에 있다. CrowdStrike는 기기에서의 실행을 강조하고, Okta는 요청에 연결된 아이덴티티를 강조한다. 두 접근법은 서로 다른 위치에서 동일한 자율성 문제를 다룬다.
CrowdStrike는 9월 1일 Falcon Guardian을 공개했다. agent runtime security 발표에서는 에이전트를 발견하고, 그 활동을 기기 이벤트와 연결하며, 접근 통제를 집행하는 방식을 설명한다. 런타임은 소프트웨어가 실행되는 기간을 뜻하므로, 핵심 질문은 에이전트가 기기에서 실제로 무엇을 하는가다.
Okta는 Agent Gateway를 에이전트와 엔터프라이즈 도구 사이의 중개자로 설명합니다. 런타임 ID 적용 방식은 요청한 사용자와 실행하는 에이전트를 모두 확인합니다. Okta는 도구 호출, 즉 작업 실행 요청이 발생할 때 정책이 적용된다고 말합니다.
경쟁하는 접근 방식에서는 가디언이라는 명칭보다 적용 범위와 집행 방식이 더 유용한 비교 기준이 됩니다.
이는 벤더의 설명이지 독립적으로 비교 가능한 성능 결과는 아닙니다. 우선순위의 차이는 보여주지만 우열을 증명하지는 않습니다. 구매자는 여전히 제품이 어떤 작업을 관찰하는지, 어떤 작업을 차단할 수 있는지, 그리고 다른 통제가 어디서 이어받아야 하는지를 판단해야 합니다.
가상의 코딩 워크플로는 이 구분이 중요한 이유를 보여줍니다. 에이전트는 외부 비즈니스 애플리케이션에 대한 접근을 요청하기 전에 로컬 파일을 편집할 수 있습니다. 직원에게는 하나의 연속된 업무처럼 느껴지더라도, 이러한 작업은 서로 다른 경계를 넘습니다.
따라서 기기 중심 통제와 ID 중심 중개자는 서로 다른 질문에 답할 수 있습니다. 프로세스가 예기치 않은 작업을 수행했는가? 이 특정 에이전트는 이 사용자를 대신해 이 특정 도구를 요청할 권한이 있었는가?
어느 질문도 다른 하나를 불필요하게 만들지는 않습니다. 누가 작업을 요청했는지 안다고 해서 그 작업이 비즈니스 측면에서 타당한지까지 저절로 확인되는 것은 아닙니다. 기기에서의 작업을 관찰한다고 해서 직원에게 위임된 권한의 전체 범위가 자동으로 확인되는 것도 아닙니다.
아키텍처 비교는 벤더 분류가 아니라 워크플로를 따라야 합니다. 구매자는 정보가 어디로 들어오는지, 결정이 어디서 이뤄지는지, 외부 효과가 어디서 가능해지는지를 추적할 수 있습니다. 각 전환 지점은 보호 주장이 구체적인 설명을 필요로 하는 위치를 드러냅니다.
조달 논의에서도 현재 동작과 계획된 확장을 구분해야 합니다. 발견 기능 시연은 차단 기능 시연과 다른 것을 증명합니다. 계획된 통합은 고객 환경에서 작동하는 연결과 다른 것을 증명합니다.
더 넓은 업계 차원의 의미는 위임을 점검 가능하게 만드는 방향으로의 전환입니다. Microsoft, CrowdStrike, Okta는 에이전트 활동을 엔터프라이즈 통제와 연결하는 서로 다른 방식을 설명합니다. 제품이 환경의 서로 다른 부분을 차지하더라도, 이들의 주장은 같은 운영 질문을 통해 평가받아야 합니다.
구매자에게 이는 구체성을 요구할 기회를 만듭니다. 제품이 AI 에이전트를 보호하는지 묻는 대신, 어떤 중대한 작업을 관리하는지 물어야 합니다. 답변은 집행 지점, 적용되는 ID, 그리고 사후에 이용 가능한 증거를 식별해야 합니다.
가디언 에이전트에도 자체 검증 책임이 따른다
에이전트를 사용해 다른 에이전트를 감독하면 두 번째 불확실성 계층이 추가됩니다. 감독자는 활동을 해석하고, 허용 가능한 변동과 위험한 일탈을 구분하며, 적절한 대응을 선택해야 합니다. 이러한 판단은 감독받는 시스템의 행동과 함께 평가되어야 합니다.
10월 23일 보도에서 Dark Reading은 새로운 Guardian Agent 기능이 Microsoft와 일부 고객에게만 제한되어 있다고 전했습니다. 에이전트 감독의 한계를 다룬 이 보도에는 예측하기 어려운 감독자에 대한 Forrester 애널리스트 Andras Cser의 우려도 포함됐습니다. Suzu Labs CTO Denis Calderone은 승인된 접근 권한 안에서도 유해한 결과가 발생할 수 있다고 경고했습니다.
이러한 관찰은 별개의 문제를 지적합니다. 권한 경계는 올바르게 집행되면서도 해로운 비즈니스 결정을 허용할 수 있습니다. 감독자는 정당한 작업을 잘못 해석해 유용한 업무를 중단시킬 수도 있습니다.
가디언은 측정 가능한 판단과 자체 권한에 대한 집행 가능한 한계를 통해 신뢰를 얻습니다.
고객 기록을 업데이트할 권한이 있는 가상의 에이전트를 생각해 보겠습니다. 올바른 도구를 사용해 올바른 필드에 잘못된 결론을 기록할 수 있습니다. 모든 접근 검사가 성공하더라도 비즈니스 결과는 여전히 잘못될 수 있습니다.
이 사례는 권한 통제만으로 전체 보증 책임을 감당할 수 없는 이유를 설명합니다. 권한 부여는 행위자가 작업을 수행할 수 있는지를 결정합니다. 그 작업의 기초가 되는 판단이 정확하고 적절하며 이용 가능한 증거로 뒷받침되는지까지 확인하지는 않습니다.
감독자에게도 정의된 대응 경계가 필요합니다. 의심스러운 활동을 탐지하고 제한을 제안하는 것은 비즈니스 기록을 독자적으로 변경하거나 관련 없는 서비스를 비활성화하는 것과 다릅니다. 구매자는 가디언이 무엇을 변경할 수 있는지, 그리고 그 권한 확대를 누가 승인하는지 물어야 합니다.
평가는 놓친 위험뿐 아니라 불필요한 개입도 다뤄야 합니다. 일상 업무를 차단하는 시스템은 이를 우회해야 한다는 압박을 만듭니다. 의심스러운 활동을 지나치게 많이 허용하는 시스템은 안심시키는 감독 인터페이스가 있더라도 조직을 노출된 상태로 둡니다.
따라서 유용한 평가에는 일상 작업, 모호한 요청, 명백히 금지된 작업이 포함되어야 합니다. 중요한 증거는 결과로 나타난 행동과 설명입니다. 구매자는 제품이 이러한 사례 전반에 걸쳐 의도한 정책을 일관되게 적용하는지 확인해야 합니다.
투명성에 관한 주장도 똑같이 신중하게 다뤄야 합니다. 모델의 설명은 조사자가 작업에 대한 가설을 세우는 데 도움이 될 수 있습니다. 하지만 실제 요청, 도구 활동, 리소스 접근, 그리고 그에 따른 변경 사항과 대조해 확인해야 합니다.
가용성의 구분은 여전히 핵심입니다. 제한된 고객 사용은 가치 있는 학습을 제공할 수 있지만, 서로 다른 엔터프라이즈 환경 전반에서 폭넓은 신뢰성을 입증하지는 않습니다. 이 발표는 접근 방식을 검토할 근거는 제공하지만, 구매자가 제안된 모든 기능에 의존해야 하는지까지 결론내리지는 않습니다.
따라서 Microsoft AI agent security는 여러 차원의 검증 책임을 안고 있습니다. 회사는 적용 범위, 개입 행동, 출시 상태를 설명해야 합니다. 고객은 통제가 자신들의 워크플로와 승인 경계에 부합한다는 증거를 필요로 합니다.
회의적인 입장이 에이전트 감독을 거부할 필요는 없습니다. 이는 감독자의 판단이 틀렸을 때에도 감독자가 책임을 지는지 묻습니다. 이 질문은 중단이나 피해를 초래하는 작업이 발생한 뒤에만 등장할 것이 아니라, 처음부터 배포 결정에 포함되어야 합니다.
다음 신호는 가용성, 상호운용성, 그리고 결과다
향후 몇 달은 성공이나 실패를 미리 가정하지 않고 Microsoft의 방향성을 평가할 구체적인 방법을 제공합니다. 가장 유용한 신호는 고객이 무엇을 배포할 수 있는지, 통제가 어떤 시스템을 관리할 수 있는지, 실제 워크플로 중 어떤 일이 일어나는지에 관한 것입니다. 각각은 자율성의 상충 관계 중 다른 부분을 검증합니다.
가장 강력한 증거는 중대한 작업이 발생하기 전에 명시된 정책을 관찰 가능한 결정과 연결할 것입니다.
첫째, 정확한 가용성 공개를 지켜봐야 합니다. Microsoft는 발표된 아키텍처, 제한된 접근, 프리뷰 기능, 일반 제공 기능을 구분해야 합니다. 더 폭넓은 접근은 제안이 운영 단계로 전환되고 있다는 근거를 강화하는 반면, 계속된 모호함은 구매자가 합리적으로 내릴 수 있는 결론을 제한할 것입니다.
가용성 세부 정보는 관련 환경과 전제 조건을 식별해야 합니다. 특정 배포에서 접근 가능한 기능이 다른 환경에서도 자동으로 적용 범위를 보장하는 것은 아닙니다. 고객은 광범위한 제품명만으로 가용성을 추정하는 대신, 보호된 워크플로를 재현할 수 있을 만큼 충분한 정보를 필요로 합니다.
둘째, 서로 다른 공급업체 제품 간의 조율된 운영을 뜻하는 입증된 상호운용성을 지켜봐야 합니다. 유용한 증거는 ID와 정책 맥락이 온전하게 유지된 채 조직 시스템을 가로지르는 완전한 워크플로입니다. 파트너십 발표만으로는 운영상의 질문이 해소되지 않습니다.
설득력 있는 시연은 결정이 어디서 집행됐는지와 접근이 변경됐을 때 어떤 일이 발생했는지를 보여줘야 합니다. 대시보드에 제한이 표시되지만 하류 작업이 여전히 성공한다면, 해당 통제는 의도한 경계를 제공하지 못한 것입니다. 실제로 작동하는 집행은 더 넓은 아키텍처 주장을 강화할 것입니다.
셋째, 고객 배포에서 측정된 결과를 지켜봐야 합니다. 유용한 보고는 차단된 유해 작업, 불필요한 중단, 제품 적용 범위 밖에서 발생한 사고를 구분할 것입니다. 테스트 환경을 설명하면 그러한 결과는 단일 성공 사례보다 더 의미 있어집니다.
중요한 비교는 팀이 의도한 승인 경계를 유지하면서 유용한 자율성을 얻는지 여부입니다. 신뢰할 수 있는 개입의 증거는 Microsoft의 주장을 뒷받침할 것입니다. 빈번한 우회, 불명확한 책임 주체, 또는 승인된 권한 안에서 발생하는 피해 작업은 추가 통제가 필요한 영역을 드러낼 것입니다.
개발자에게 이러한 신호는 인터페이스와 배포 선택에 정보를 제공합니다. 엔터프라이즈 구매자에게는 평가 기준과 계약상 질문을 형성합니다. 직원에게는 에이전트의 확장되는 기능이 이해 가능한 한계와 함께 도입되는지를 결정합니다.
Microsoft AI agent security는 궁극적으로 지시가 비즈니스 결과로 바뀌는 지점에서 평가받아야 합니다. 그곳에서 위임된 업무의 약속은 이후에 일어나는 일에 대한 조직의 책임과 만납니다.
에이전트의 업무 범위를 확대하기 전에 직원의 요청부터 최종 효과까지 중대한 작업을 추적하십시오. 누가 이를 승인했는지, 어떤 시스템이 이를 거부할 수 있는지, 어떤 증거가 결과를 설명할 수 있는지 식별하십시오. 그런 다음 벤더에게 실제 승인 규칙을 사용해 그 경계를 시연하도록 요청하십시오. 일상 작업, 모호한 요청, 그리고 반드시 금지되어야 하는 작업을 포함하십시오. 목표는 모델이 예상치 못한 경로를 선택했을 때 책임이 어디에 있는지 확립하는 것입니다. 의도에 관한 보증이 아니라 관찰 가능한 행동에 평가의 초점을 맞추십시오. 내일 에이전트가 중대한 작업을 제안한다면, 그 일이 발생하기 전에 이를 멈출 권한은 누구에게 있습니까?
