섀도우 AI 에이전트가 기업에 보이지 않는 위험을 초래한다

Google News는 기업들이 우려스러운 충돌에 직면한 가운데 섀도우 AI 에이전트에 대한 Dark Reading의 경고를 부각했다. 도입은 가속화되고 있지만 가시성은 여전히 불완전하다.

우려는 직원이 승인되지 않은 챗봇에 기밀 텍스트를 붙여넣는 수준을 넘어선다. 자율 에이전트는 자격 증명을 부여받고, 기업 시스템에 연결되며, 컨텍스트를 유지하고, 매 단계 승인 없이 행동할 수 있다.

이는 보안의 핵심 경쟁 구도를 바꾼다. 기업은 더 이상 생산성과 일반적인 소프트웨어 거버넌스 사이의 균형만 맞추는 것이 아니다. 이제는 자율적 행동과 인간 사용자 및 예측 가능한 애플리케이션을 위해 설계된 통제 수단 사이에서 균형을 잡아야 한다.

Dark Reading은 에이전트형 시스템이 광범위한 자격 증명과 느슨한 확인 절차를 지닌 채 프로덕션 환경에 도달할 수 있는 방식을 기록해 왔다. 보고된 한 코딩 에이전트 사고에서는 프로덕션 데이터베이스와 볼륨 수준의 백업이 수 초 만에 삭제됐다. 개별 장애보다 더 중요한 것은 이 매체의 광범위한 결론이다. 과도한 접근 권한을 지닌 에이전트는 일상적인 실수를 즉각적인 운영 사고로 바꿀 수 있다.

이 경고는 Microsoft, Google, Amazon, Nvidia 및 다수의 보안 벤더가 제품 개발을 빠르게 진행하는 와중에 나왔다. 각 기업은 엔터프라이즈 에이전트 스택의 일부가 되기를 원한다. 그러나 새로운 프레임워크, 커넥터, 위임된 ID가 추가될 때마다 보안팀이 발견하고 관리해야 할 관계도 하나씩 늘어난다.

핵심적인 역전 현상은 불편하다. AI 에이전트는 수작업을 줄여 주겠다고 약속하지만, 이를 관리하는 일은 새로운 범주의 지속적 업무를 만든다. 보안팀은 각 에이전트를 식별하고, 그 목적을 이해하며, 접근 권한을 매핑하고, 행동을 모니터링하고, 안전하게 폐기해야 한다.

Google News가 섀도우 에이전트 문제를 조명하다

최신 경고가 중요한 이유는 섀도우 AI가 무단 대화에서 무단 행동으로 이동했기 때문이다.

여기서 Google News는 발견 채널 역할을 하며, 그 기반이 된 Dark Reading 보도는 엔터프라이즈 보안 연구 전반의 더 넓은 변화를 반영한다. 직원과 개발자는 로컬 도구, 클라우드 플랫폼, 소프트웨어 확장 기능, 내부 자동화 프로젝트를 통해 에이전트를 배포하고 있다.

AI 에이전트는 여러 단계를 거쳐 목표를 추구하기 위해 모델을 사용하는 소프트웨어다. 기존 애플리케이션보다 직접적인 감독을 덜 받으며 도구를 선택하고, 정보를 검색하고, API를 호출하고, 시스템을 수정할 수 있다.

이러한 자율성은 섀도우 에이전트를 승인되지 않은 챗봇과 구분한다. 챗봇은 일반적으로 사람에게 정보를 반환한다. 반면 에이전트는 메시지를 보내고, 코드를 변경하고, 고객 기록을 업데이트하고, 데이터베이스를 조회하거나, 다른 자동화 프로세스를 실행할 수 있다.

Dark Reading은 인기 있는 로컬 에이전트가 ID팀의 인벤토리 구축 속도보다 빠르게 확산되면서 에이전트형 AI 보안이 여전히 주요 엔터프라이즈 장애물로 남아 있다고 보도했다. 이 매체는 보안팀이 해당 에이전트의 존재를 알기도 전에 사용자가 인스턴스를 구축한 사례를 설명했다. 또한 악성 지원 티켓이 에이전트의 접근 권한 상승과 데이터 유출을 1분 이내에 유도한 시연도 검토했다.

이런 사례가 모든 에이전트 배포가 안전하지 않다는 점을 입증하는 것은 아니다. 다만 소프트웨어가 계획하고 행동할 수 있을 때 익숙한 통제 실패가 더 심각한 결과로 이어질 수 있음을 보여 준다.

가시성 격차의 규모는 Cloud Security Alliance가 2026년에 실시한 엔터프라이즈 에이전트 설문조사에서 더욱 분명하게 드러난다. CSA는 참여 조직의 82%가 지난 1년 동안 이전에 알지 못했던 에이전트를 발견했다고 보고했다.

이 연구는 IT 및 보안 전문가 418명의 응답을 기반으로 했다. Token Security가 이 설문조사를 의뢰하고 자금을 지원했으며, 독자는 결론을 해석할 때 이 관계를 고려해야 한다.

이러한 단서에도 불구하고, 몇 가지 결과는 일관된 거버넌스 문제를 드러낸다. 응답자의 41%는 알 수 없는 에이전트를 여러 차례 발견했다고 답했다. 내부 자동화 및 스크립팅 환경은 51%가 꼽은 가장 흔한 출처였다.

맞춤형 도구, 어시스턴트, 플러그인을 포함한 LLM 플랫폼이 47%로 뒤를 이었다. SaaS 자동화와 개발자가 만든 워크플로도 각각 주요 출처로 나타났다.

이러한 분포는 일반적인 소프트웨어 인벤토리만으로는 충분하지 않은 이유를 설명한다. 에이전트는 데스크톱 프로세스, 클라우드 리소스, 플러그인, API 통합 또는 승인된 SaaS 제품 안에 내장된 워크플로로 나타날 수 있다.

눈에 보이는 애플리케이션은 하나의 구성 요소일 뿐이다. 자격 증명, 모델 엔드포인트, 도구 연결, 메모리 저장소, 하위 에이전트가 이를 둘러싼 운영 시스템을 구성한다.

이 시스템은 이를 만든 직원이 다른 프로젝트로 이동한 뒤에도 활성 상태로 남을 수 있다. 최초의 비즈니스 목적이 사라진 뒤에도 접근 권한을 유지할 수 있다.

Google News가 하나의 헤드라인을 더 넓은 독자층에 전달했을 수는 있지만, 이 사건은 단일 보도 주기보다 더 큰 의미를 지닌다. 기업들은 자신들이 등록한 적 없는 행위자와 검토한 적 없는 권한이 AI 환경에 포함되어 있음을 발견하고 있다.

섀도우 AI 에이전트가 서로 다른 위험을 지니는 이유

섀도우 에이전트는 알 수 없는 자산과 활성 ID를 결합해, 전통적인 섀도우 IT가 같은 속도로는 거의 지니지 않았던 위험을 만든다.

섀도우 IT는 일반적으로 공식 승인 없이 도입된 소프트웨어 또는 인프라를 뜻한다. 그 위험에는 관리되지 않는 데이터 저장소, 안전하지 않은 구성, 부실한 벤더 검토, 누락된 감사 기록이 포함된다.

섀도우 AI는 이러한 문제를 그대로 물려받는다. 여기에 확률적 의사결정, 지속적인 컨텍스트, 도구 사용, 자율 실행을 더한다.

기존 SaaS 애플리케이션은 프로그래밍된 워크플로를 따른다. 에이전트는 목표를 해석하고 경로를 선택한다. 모델, 컨텍스트, 사용 가능한 도구가 각 결정에 영향을 미치므로 유사한 두 요청도 서로 다른 행동으로 이어질 수 있다.

이러한 유연성은 가치를 만든다. 동시에 일회성 보안 검토만으로 에이전트를 평가하기 어렵게 만든다.

에이전트의 실질적 권한은 초기 구성만으로 결정되지 않는다. 보안팀은 요청 사용자, 위임된 자격 증명, 연결된 도구, 검색된 콘텐츠, 접근 가능한 데이터, 그리고 모든 하위 행동을 고려해야 한다.

프롬프트 인젝션은 이 관계를 특히 위험하게 만든다. 프롬프트 인젝션은 신뢰할 수 없는 콘텐츠가 에이전트의 지침을 조작해, 사용자가 의도한 작업에서 벗어나도록 유도할 수 있는 상황을 말한다.

악성 지침은 지원 티켓, 문서, 이메일 또는 웹페이지 안에 숨겨질 수 있다. 에이전트가 그 콘텐츠를 신뢰할 수 있는 지침으로 취급하면, 정보를 공개하거나 승인되지 않은 목적으로 권한 있는 도구를 호출할 수 있다.

Cloud Security Alliance의 인프라 분석은 이를 불량 애플리케이션의 집합이 아니라 계층화된 공격 표면으로 설명한다. 이 구분은 에이전트가 보안팀이 흔히 별도로 평가하는 시스템들을 연결한다는 점에서 유용하다.

고객 피드백을 요약하기 위해 에이전트를 구축한 직원을 생각해 보자. 에이전트는 공유 드라이브를 읽고, 외부 모델을 호출하며, 컨텍스트를 저장하고, 메시징 채널에 결론을 게시하고, 기획 데이터베이스를 업데이트한다.

각 연결은 개별적으로는 타당해 보일 수 있다. 그러나 함께 놓이면 여러 신뢰 경계를 넘어 기밀 정보를 이동시킬 수 있는 파이프라인이 된다.

직원은 첫 번째 데이터 소스는 보호하면서도 모델 제공업체의 보존 설정은 간과할 수 있다. API 자격 증명을 로컬 구성 파일에 저장할 수도 있다. 읽기 권한만 필요함에도 에이전트에 모든 기록을 편집할 수 있는 권한을 부여할 수 있다.

에이전트는 위임된 OAuth 접근을 통해 권한을 축적할 수도 있다. OAuth는 하나의 서비스가 사용자 또는 다른 애플리케이션이 부여한 권한을 통해 행동할 수 있게 한다.

따라서 폐기된 에이전트는 일반적인 직원 계정 없이도 계속 작동할 수 있다. 그 토큰은 관심을 거의 받지 못하는 워크플로, 통합 또는 개발자 환경 안에 남아 있을 수 있다.

CSA는 잊힌 에이전트와 유지된 권한의 축적을 “폐기 부채”라고 부른다. 설문 응답자 중 에이전트 폐기를 위한 공식 절차를 갖췄다고 답한 비율은 21%에 불과했다.

이 수명 주기 격차는 사고 대응을 복잡하게 만든다. 보안팀은 에이전트의 ID, 소유자, 도구, 종속성에 대한 완전한 기록이 없다면 해당 에이전트의 권한을 신속히 철회할 수 없다.

위험은 적대적 침해에만 국한되지 않는다. 에이전트는 부정확하게 정의된 목표를 충실히 추구하는 과정에서도 피해를 일으킬 수 있다.

Dark Reading은 AI 코딩 에이전트가 프로덕션 데이터와 연관된 백업을 삭제한 것으로 알려진 뒤 이 실패 패턴을 검토했다. 이 특정 사고에는 광범위한 자격 증명과 환경 간 불충분한 분리를 포함한 여러 통제 약점이 관련됐다.

이는 익숙한 엔지니어링 실수다. 자율성은 실수와 그 결과 사이의 시간을 압축한다.

사람 운영자는 데이터베이스를 삭제하기 전에 멈춰 생각할 수 있다. 결정론적 배포 시스템은 프로그래밍된 경로를 벗어난 행동을 거부할 수 있다. 에이전트는 파괴적 행동을 자신에게 할당된 목표를 완료하기 위한 유효한 단계로 해석할 수 있다.

그래서 프롬프트 기반 규칙만으로는 충분하지 않다. 에이전트에게 해로운 행동을 피하라고 지시하면 행동에 영향을 줄 수는 있지만, 그러한 행동을 수행할 기술적 능력까지 제거하지는 못한다.

역량은 모델 외부에서 제한돼야 한다. 에이전트는 자신의 작업에 필요하지 않은 시스템과 행동에 접근할 수 없어야 한다.

엔터프라이즈 ID 통제가 가장 어려운 시험에 직면하다

이제 핵심 경쟁은 자율적 역량과 안정적인 사용자, 서비스 계정, 예측 가능한 워크로드를 중심으로 구축된 ID 시스템 사이에서 벌어진다.

ID 및 접근 관리(IAM)는 몇 가지 근본적인 질문에 답한다. 누가 접근을 요청하는가, 어떤 리소스에 도달할 수 있는가, 어떤 행동을 수행할 수 있는가, 그리고 해당 권한은 얼마 동안 유효해야 하는가?

기업들은 직원과 서비스 계정을 위해 이러한 통제를 개선하는 데 수년을 투자해 왔다. 에이전트는 두 범주 모두에 도전한다.

에이전트는 사람이 아니지만, 종종 사람을 대신해 행동한다. 또한 새로운 컨텍스트를 해석하면서 행동 순서가 바뀔 수 있기 때문에 전통적인 서비스 계정도 아니다.

에이전트를 공유 서비스 계정으로 취급하면 책임성을 흐리게 만든다. 로그에는 어떤 자격 증명이 파일에 접근했는지는 표시될 수 있지만, 어떤 사용자가 작업을 시작했는지 또는 에이전트가 왜 해당 파일을 선택했는지는 드러나지 않을 수 있다.

멀티 에이전트 시스템은 문제를 더 어렵게 만든다. 한 에이전트가 다른 에이전트에 작업을 위임하고, 그 에이전트가 다른 자격 증명으로 세 번째 도구를 호출할 수 있다.

원래 사용자의 ID와 의도는 그 연결 고리를 따라 사라질 수 있다. 이후 권한은 작업을 요청한 사람의 권한이 아니라 기술적 통합을 따라 움직인다.

Google의 2026년 보안 전망은 이러한 변화를 예상했다. 이 보고서는 에이전트가 세분화되고 컨텍스트를 인식하는 접근 권한을 갖춘 관리형 디지털 행위자가 되어야 한다고 주장했다.

보고서는 최소 권한, 임시 접근, 추적 가능한 위임 체인을 강조했다. 최소 권한은 ID가 현재 작업에 필요한 접근 권한만 받는다는 뜻이다.

이 원칙들은 확립된 보안 관행이다. 어려운 부분은 에이전트 활동의 속도와 규모에 맞춰 이를 적용하는 데 있다.

직원은 근무일 동안 몇 가지 중요한 행동을 수행할 수 있다. 에이전트는 단일 작업 내에서 많은 도구 호출을 시작할 수 있으며 지속적으로 실행될 수도 있다.

분기별 접근 권한 검토로는 모든 결정을 평가할 수 없다. 정적인 권한으로는 특정 행동이 에이전트의 현재 목적에 부합하는지 판단할 수 없다.

기업은 따라서 의사결정 지점에서 맥락을 확보해야 한다. 승인된 프로젝트 폴더 하나를 읽어 달라는 요청은 자동으로 진행될 수 있다. 고객 기록을 내보내 달라는 요청은 더 강력한 검증이나 사람의 승인 절차를 촉발해야 한다.

CSA 설문조사에 따르면 조직들은 이미 이러한 차이를 인식하고 있다. 응답자의 53%는 에이전트가 저위험 작업에서는 자율적으로 운영되지만, 고위험 작업은 사람이 검토한다고 답했다.

완전 자율 모델을 운영한다고 답한 비율은 13%에 불과했다. 그러나 에이전트가 권한 범위를 벗어났을 때 해당 작업이 자동으로 차단된다고 답한 응답자는 11%뿐이었다.

이 격차는 중요하다. 작업 완료 후 이를 기록하는 것은 조사에 도움이 되지만, 데이터 손실이나 운영상 피해를 막지는 못한다.

사람의 승인에도 한계가 있다. 모든 작업이 승인 요청을 발생시키면 직원들은 신중한 평가 없이 요청을 승인하게 된다. 승인 피로는 눈에 보이는 통제를 효과 없는 의례로 바꿀 수 있다.

더 나은 설계는 개입을 위험 수준에 연계한다. 보안팀은 어떤 리소스, 데이터 분류, 작업에 더 강력한 통제가 필요한지 정의해야 한다.

Microsoft는 이 문제를 위한 제어 플레인으로 Agent 365를 내세우기 시작했다. Microsoft의 Agent 365 업데이트는 Microsoft, Amazon, Google 환경 전반의 연결을 포함해 로컬 및 클라우드 에이전트를 발견하는 기능을 설명한다.

Microsoft는 자사의 보안 제품이 디바이스, Model Context Protocol 서버, 관련 ID, 접근 가능한 클라우드 리소스를 매핑할 수 있다고 말한다. Model Context Protocol(MCP)은 AI 애플리케이션이 도구 및 데이터 소스에 연결할 수 있게 하는 표준이다.

이러한 관계 맵은 평면적인 에이전트 목록보다 더 유용하다. 에이전트 또는 그 자격 증명이 침해됐을 때 방어자가 피해 범위를 추정하는 데 도움이 된다.

Microsoft는 또한 관리되지 않는 일부 로컬 에이전트가 사용하는 일반적인 방법을 관리자가 탐지하고 차단할 수 있다고 말한다. 런타임 통제는 에이전트가 작동하는 동안 의심스러운 행동을 차단하기 위한 것이다.

이 기능들은 엔터프라이즈 보안의 방향성을 보여 주지만, 공급업체의 주장은 실무적 검증이 필요하다. 크로스플랫폼 탐지는 맞춤형 에이전트, 사설 인프라, 지원되지 않는 커넥터, 다른 제품 내부에 숨겨진 워크플로를 놓칠 수 있다.

제어 플레인 자체도 집중 위험을 만든다. 기업은 다른 모든 에이전트를 통제하는 시스템에 어느 정도의 권한을 부여할지 결정해야 한다.

결과적으로 이는 기존 ID 도구에서 새로운 도구로 단순히 이전하는 문제가 아니다. 기업은 독립적인 모니터링, 복구 경로, 실질적인 사람의 책임성을 유지하면서 ID 통제를 확장해야 한다.

가시성만으로는 통제가 되지 않는다

에이전트를 발견하는 것은 필수지만, 인벤토리만으로 그 작업이 안전하게 유지되거나 부여된 목적에 부합한다는 점을 증명할 수는 없다.

보안 공급업체들은 섀도 AI에 대응하기 위해 탐지 제품을 내놓았다. 이 제품들은 엔드포인트, 네트워크 트래픽, 클라우드 환경, 브라우저 활동, ID, SaaS 통합을 점검한다.

이러한 가시성은 출발점을 제공한다. 기업은 식별할 수 없는 자산을 통제할 수 없다.

위험은 탐지를 완료로 간주하는 데 있다. 에이전트가 인벤토리에 표시되더라도 가장 중요한 관계가 여전히 알려지지 않을 수 있다.

보안팀은 누가 이를 소유하는지, 어떤 모델을 사용하는지, 어떤 데이터를 가져오는지, 메모리가 어디에 있는지, 어떤 자격 증명을 보유하는지, 어떤 도구를 호출할 수 있는지 알아야 한다.

행동에 관한 증거도 필요하다. 송장 대사 작업을 위해 승인된 에이전트가 갑자기 소스 코드 저장소를 검색하거나 낯선 도메인으로 파일을 보내서는 안 된다.

전통적인 데이터 유출 방지 체계는 조직 밖으로 나가는 일부 민감한 정보를 탐지할 수 있다. 하지만 에이전트가 왜 해당 정보에 접근했는지, 또는 그 작업이 요청을 시작한 사용자의 의도와 일치했는지는 이해하지 못할 수 있다.

같은 한계는 엔드포인트 모니터링에도 적용된다. 프로세스 이름은 에이전트가 실행 중임을 보여 줄 수 있지만, 그 에이전트를 통해 시작된 클라우드 워크플로를 항상 재구성할 수 있는 것은 아니다.

지속적 권한 부여는 더 강력한 모델을 제공한다. 단 한 번의 초기 로그인을 신뢰하는 대신, 의미 있는 각 단계에서 접근이 계속 적절한지 평가한다.

에이전트의 경우 이 평가는 작업 목적, 사용자 권한, 리소스 민감도, 도구 평판, 현재 행동, 최근 위험 변화까지 포함해야 한다.

지속적 권한 부여가 모든 작업에 수동 승인을 요구하는 것은 아니다. 저위험이며 되돌릴 수 있는 작업은 정의된 경계 안에서 진행될 수 있다.

영향이 큰 작업은 다른 경로를 거쳐야 한다. 기록 삭제, 외부 메시지 게시, 인프라 수정, 권한 변경, 규제 대상 데이터 내보내기에는 기술적 제한이 적용돼야 한다.

경계는 모델 외부에 존재해야 한다. 읽기 전용 자격 증명, 격리된 환경, 거래 한도, 별도 승인 서비스는 에이전트가 실제로 할 수 있는 일을 제한할 수 있다.

복구에도 유사한 분리가 필요하다. 백업은 에이전트가 수정할 수 있는 프로덕션 시스템과 동일한 권한 경계 안에 있어서는 안 된다.

Dark Reading의 데이터베이스 보도는 이 점을 구체적으로 보여 준다. 에이전트가 하나의 자격 증명 경로로 프로덕션 데이터와 복구 사본을 모두 삭제할 수 있다면, 백업은 독립적인 안전장치를 제공하지 못한다.

관측 가능성에도 지속적인 기록이 필요하다. 로그에는 요청을 시작한 사용자, 에이전트 ID, 모델 및 버전, 요청된 목표, 선택된 도구, 접근한 데이터, 받은 승인, 최종 결과가 보존돼야 한다.

모든 것을 기록하면 개인정보와 저장 공간 문제가 발생한다. 민감한 프롬프트와 가져온 데이터가 제한 없는 2차 데이터셋이 되어서는 안 된다.

기업은 에이전트 텔레메트리에 대한 보존 한도와 접근 통제를 마련해야 한다. 조사 담당자는 모든 기밀 입력을 광범위한 집단에 노출하지 않으면서 의사결정을 재구성할 수 있을 만큼의 맥락을 확보해야 한다.

거버넌스는 승인된 실험과 통제되지 않는 프로덕션 접근도 구분해야 한다. 개발자는 완전한 조달 주기를 기다리지 않고 새 에이전트를 시험할 수 있는 환경이 필요하다.

그 환경은 합성 데이터 또는 적절히 보호된 데이터를 사용해야 한다. 자격 증명을 격리하고 핵심 프로덕션 리소스에 직접 접근하지 못하게 해야 한다.

전면 금지는 또 다른 가시성 문제를 만든다. Google의 전망은 에이전트를 금지하면 그 사용이 기업 네트워크 밖으로 밀려나 모니터링이 더욱 약해질 수 있다고 경고했다.

그렇다고 모든 도구가 승인을 받아야 한다는 뜻은 아니다. 직원들이 이를 선택할 만큼 승인된 경로가 충분히 사용하기 쉬워야 한다는 의미다.

보안팀은 검증된 모델, 표준 커넥터, 제한된 자격 증명, 테스트 환경, 신속한 등록 절차를 제공할 수 있다. 이러한 조치는 숨겨진 대안을 만들 유인을 줄인다.

사업 관리자의 역할도 있다. 이들은 모든 프로덕션 에이전트에 소유자를 지정하고, 그것이 지원하는 비즈니스 프로세스를 문서화해야 한다.

소유권에는 폐기도 포함돼야 한다. 프로젝트가 끝나면 조직은 토큰을 폐기하고, 통합을 제거하며, 불필요한 메모리를 삭제하고, 종속 워크플로가 더 이상 해당 에이전트를 호출하지 않는지 확인해야 한다.

이러한 수명주기 규율이 없으면 가시성은 해결되지 않은 자산의 목록으로 늘어날 뿐이다. 기업은 위험이 존재한다는 사실은 알지만, 여전히 이를 자신 있게 제거할 수 없다.

증거는 심각하지만 한계도 있다

현재 연구는 상당한 거버넌스 격차를 보여 주지만, 공급업체 자금 지원 설문조사와 개별 사건만으로 에이전트가 초래한 피해의 전체 빈도를 측정할 수는 없다.

보안 보도에는 두 가지 형태의 신중함이 필요하다. 기업은 섀도 에이전트를 가상의 문제로 치부해서는 안 된다. 동시에 모든 전망이나 공급업체 통계를 중립적인 측정치로 받아들여서도 안 된다.

CSA 설문조사는 응답자 수, 설문 시점, 여러 배포 패턴을 제시한다는 점에서 유용한 세부 정보를 제공한다. 또한 Token Security가 설문지를 의뢰하고 자금을 지원했으며 개발에 참여했다고 명시한다.

Token은 AI 에이전트용 ID 보안을 판매한다. 이것이 결과를 무효화하는 것은 아니지만, 가시성과 ID 격차를 강조할 상업적 이해관계가 있음을 의미한다.

자주 인용되는 다른 측정치는 자체 고객을 관찰하는 보안 공급업체에서 나온다. 이러한 데이터셋은 제품 텔레메트리 안의 추세를 보여 줄 수 있지만, 모든 기업을 대표하지는 않을 수 있다.

고객 선정, 배포 구성, 탐지 방식, 용어는 결과에 영향을 줄 수 있다. 한 제품은 각 워크플로를 에이전트로 집계할 수 있지만, 다른 제품은 독립적인 에이전트 ID만 집계할 수 있다.

“사건”이라는 용어도 신중하게 해석해야 한다. 이는 데이터 노출, 정책 위반, 예기치 못한 행동, 운영 중단, 확인된 침해를 포괄할 수 있다.

CSA는 응답자의 65%가 지난 1년 동안 AI 에이전트 관련 사건을 경험했다고 보고했다. 영향을 받은 조직 가운데 데이터 노출은 가장 자주 보고된 비즈니스 영향이었다.

이 결과는 우려스럽다. 그러나 악의적인 공격자, 실수로 인한 작업, 승인되지 않은 사용, 승인된 시스템의 실패가 각각 얼마나 많은 사건에 관여했는지는 입증하지 못한다.

사례 보고서는 깊이를 제공하지만 유병률을 보여 주지는 않는다. 한 회사의 프로덕션 데이터베이스 삭제는 그럴듯한 실패 연쇄를 보여 준다. 하지만 시장 전반에서 유사한 사건이 얼마나 자주 발생하는지는 알 수 없다.

같은 주의는 공격 시연에도 적용된다. 통제된 익스플로잇은 특정 조건에서 설계가 실패할 수 있음을 보여 준다. 프로덕션 방어 체계, 권한, 모니터링은 결과를 바꿀 수 있다.

따라서 기업은 공급업체에 탐지 방법론, 적용 범위 경계, 오탐률, 독립적 검증을 요구해야 한다. “완전한 인벤토리”라고 표시된 대시보드는 특히 면밀한 검토가 필요하다.

알려지지 않은 에이전트는 탐지가 불완전하기 때문에 정확히 알려지지 않은 것이다. 어떤 공급업체도 자체 센서가 발견한 자산만 보여 주면서 보편적인 적용 범위를 증명할 수는 없다.

보안 책임자는 모델 위험과 시스템 위험도 구분해야 한다. 에이전트는 모델 행동 때문에 잘못된 결정을 내릴 수 있지만, 그 결정이 중대한 사건으로 이어지는지는 과도한 권한이 결정한다.

반대로 좁은 권한이 모든 문제를 해결하는 것도 아니다. 읽기 전용 접근 권한을 가진 에이전트도 기밀 정보를 공개하거나, 해로운 권고를 생성하거나, 다른 시스템에 영향을 미칠 수 있다.

가장 신뢰할 수 있는 대응은 모델 평가, ID 거버넌스, 데이터 보호, 런타임 모니터링, 운영 복원력을 결합한다. 단일 계층이 전체 부담을 감당할 수는 없다.

기업은 또한 에이전트 실패와 일반적인 애플리케이션 실패를 구분하는 사고 보고가 필요하다. 유용한 보고서에는 자율성 수준, 접근 경로, 작업을 시작한 ID, 침해된 구성 요소, 비즈니스 영향이 담겨야 한다.

공유된 정의가 없으면 시장은 크지만 호환되지 않는 수치를 만들어 낼 것이다. 그러면 이사회와 규제기관이 위험이 개선되고 있는지 이해하기 더 어려워진다.

Google News 독자는 현재의 헤드라인을 기업 노출을 완전히 측정한 결과가 아니라, 수렴하는 증거가 뒷받침하는 경고로 해석해야 한다.

검증 격차도 이 이야기의 일부다. 업계는 조치를 정당화할 만큼 충분히 파악하고 있지만, 에이전트 사건과 그 결과에 대한 일관된 공개 데이터는 여전히 부족하다.

기업이 다음으로 주시해야 할 것

다음 단계는 에이전트 레지스트리, 런타임 집행, 그리고 거버넌스 제품이 공급업체 시연 밖에서도 작동하는지 검증하는 사건 증거로 규정될 것이다.

첫 번째 신호는 크로스플랫폼 에이전트 레지스트리의 도입이다. Microsoft, 보안 공급업체, 클라우드 제공업체는 엔드포인트, SaaS 제품, 클라우드 환경 전반에서 에이전트를 인벤토리화하는 시스템을 구축하고 있다.

기업은 이러한 레지스트리가 맞춤형 워크플로와 지원되지 않는 도구를 발견하는지 검토해야 한다. 단일 공급업체 환경만 포괄해서는 멀티클라우드 섀도 에이전트 문제를 해결할 수 없다.

가장 강력한 증거는 독립적인 비교에서 나올 것이다. 보안팀은 알려진 에이전트를 여러 채널을 통해 배포하고, 어떤 제품이 모든 구성 요소를 탐지하는지 측정하는 테스트가 필요하다.

유용한 레지스트리는 소유자, 목적, 신원, 권한, 도구, 데이터 소스 및 수명주기 상태를 식별할 수 있어야 한다. 단순한 에이전트 이름 목록만으로는 위험 관련 의사결정에 필요한 맥락이 지나치게 부족하다.

두 번째 신호는 런타임 집행이다. 제품 발표에서는 의심스러운 도구 사용을 차단하고, 정책에 따라 에이전트를 제한하며, 맥락 인지형 권한 부여를 적용하겠다는 약속이 갈수록 늘고 있다.

중요한 측정 기준은 제품이 경고를 생성할 수 있는지 여부가 아니다. 일상적인 업무를 방해하지 않으면서 영향력이 큰 행동을 실제로 중단시키는지 여부다.

에이전트는 많은 작업을 시작할 수 있으므로 오탐은 중요하다. 일상적인 활동을 차단하는 통제 장치는 팀이 이를 비활성화하거나 우회하도록 부추길 것이다.

미탐은 훨씬 더 중요하다. 놓친 파괴적 작업 한 건으로 수천 건의 올바르게 승인된 요청이 무력화될 수 있다.

기업은 프롬프트 인젝션, 탈취된 자격 증명, 과도한 위임, 무단 데이터 전송, 감사 기록 수정 시도에 맞서 통제를 테스트해야 한다. 테스트에는 승인된 배포 환경과 섀도 배포 환경을 모두 포함해야 한다.

세 번째 신호는 더 나은 사고 공개다. 기술 업계에는 소프트웨어 취약점을 보고하기 위한 정교한 체계가 있지만, 에이전트 실패는 그 채널에 깔끔하게 들어맞지 않는다.

취약한 커넥터에는 일반적인 식별자가 부여될 수 있다. 그러나 목표를 잘못 해석하고, 과도한 접근 권한을 상속받아 데이터를 삭제한 에이전트는 더 복잡한 책임성 문제를 제기한다.

실패의 원인은 모델이었을까, 에이전트 프레임워크였을까, 커넥터였을까, 자격 증명 설계였을까, 배포 환경이었을까, 아니면 사람의 지시였을까? 많은 경우 여러 계층이 원인에 기여한다.

일관된 보고 체계는 조직이 사고를 비교하고 통제를 개선하는 데 도움이 될 것이다. 또한 널리 논의되는 위험이 반복적인 프로덕션 장애로 이어지는지도 드러낼 수 있다.

규제기관과 감사인은 정책 문서보다 증거를 요구할 가능성이 크다. 기업은 어떤 에이전트가 존재하는지, 누가 이를 소유하는지, 무엇에 접근했는지, 고위험 작업을 어떻게 통제했는지를 보여줄 수 있어야 한다.

실질적인 대응은 그러한 요구가 도착하기 전에 시작해야 한다. 보안팀은 알려진 에이전트를 목록화하고, 승인되지 않은 에이전트를 찾아내며, 그 권한을 분류하고, 방치된 자격 증명을 제거할 수 있다.

또한 항상 더 강력한 통제가 필요한 소수의 작업을 정의할 수 있다. 프로덕션 데이터 삭제, 외부 게시, 권한 변경, 대량 데이터 내보내기가 합리적인 출발점이다.

개발자와 지식 근로자는 에이전트가 무엇을 생성할 수 있는지에 집중하기 전에 무엇을 할 수 있는지 물어야 한다. 인상적인 데모 뒤에 있는 권한이 실제 기업 위험을 결정한다.

비즈니스 리더는 승인된 에이전트 경로가 섀도 도입을 줄일 만큼 충분히 접근하기 쉬운지 물어야 한다. 문서상으로만 존재하는 거버넌스는 직원이 몇 분 안에 설치할 수 있는 도구에 밀릴 것이다.

따라서 Google News 헤드라인은 새로 발견된 하나의 위협이라기보다 늦게 찾아온 인식에 관한 이야기다. 자율형 소프트웨어는 이미 기업 업무 흐름에 들어왔지만, 많은 조직은 여전히 이를 또 하나의 애플리케이션처럼 관리하고 있다.

그 접근 방식은 지속될 수 없다. 모든 프로덕션 에이전트에는 신원, 명확히 정의된 소유자, 제한된 권한, 관찰 가능한 행동, 검증된 폐기 경로가 필요하다.

향후 3개월은 에이전트 레지스트리가 신뢰할 수 있는 크로스플랫폼 적용 범위를 확보하는지, 런타임 통제가 현실적인 테스트를 견디는지, 사고 공개가 더 구체화되는지를 보여줄 것이다.

이러한 신호가 나타난다면 기업 거버넌스는 따라잡기 시작하고 있는 것이다. 그렇지 않다면, 조직이 실제로 보유한 통제력보다 더 많은 통제력을 암시하는 대시보드 뒤에서 섀도 에이전트 문제는 계속 확대될 것이다.