기업들이 AI 에이전트를 빠르게 도입하는 과정에서 덜 눈에 띄는 문제가 드러나고 있다. 이런 시스템은 신원, 권한, 그리고 비즈니스 도구에 대한 지속적인 접근을 필요로 하지만, 많은 보안 프로그램은 자율 소프트웨어 작업자를 관리하도록 설계되지 않았다. BankInfoSecurity와 TechRepublic의 최근 보도는 같은 새로운 우려를 가리킨다. AI 에이전트가 기업 환경 안에 새로운 신원 보안 격차를 만들고 있다는 것이다.

이 보도는 특정 제품 출시나 침해 사고 공개를 다루지 않는다. 대신, 이는 기업 AI 배포의 더 넓은 변화를 반영한다. 기업들이 단순한 보조용 챗봇 사용에서 AI 에이전트에게 앱, 데이터베이스, 내부 시스템 전반의 업무를 맡기기 시작하면서, 실제 권한을 행사할 수 있는 새로운 비인간 신원도 함께 만들어지고 있다. 이는 중요한데, 이미 신원은 클라우드 소프트웨어의 핵심 통제 평면이고, AI 에이전트는 이 모델을 더 자율적이고 예측하기 어려운 행위자 범주로 확장하기 때문이다.

AI 에이전트가 신원 모델을 바꾸는 이유

전통적인 기업 신원 프로그램은 직원, 계약직, 서비스 계정, 애플리케이션 연동을 기준으로 구축됐다. AI 에이전트는 이들 범주 중 어느 하나에도 깔끔하게 들어맞지 않는다. 실제로 에이전트는 지식 베이스를 읽고, 고객 기록을 조회하고, CRM에 기록을 쓰고, 협업 도구에서 워크플로를 트리거하고, 외부 API를 호출해야 할 수 있다. 즉, 에이전트는 종종 자격 증명, 토큰, 위임된 권한, 또는 추적과 모니터링이 어려운 애플리케이션 수준 접근을 통해 동작한다.

BankInfoSecurity와 TechRepublic가 제기한 문제는 단순히 AI가 또 다른 계정 유형을 추가한다는 데 있지 않다. 생산 워크플로에 배치된 뒤에는 AI 에이전트가 제한된 인간 검토만으로 시스템 전반에 걸쳐 행동을 연결할 수 있다는 점이다. 일반적인 소프트웨어 통합은 좁은 작업 하나만 수행할 수 있다. 더 넓은 자율성을 위해 설계된 에이전트는 목표를 부여받고, 어떤 도구를 사용할지 스스로 판단한 뒤, 여러 단계를 거쳐 작업을 완료할 수 있다. 신원 보안 관점에서 보면, 권한이 과도하거나 비밀 정보가 잘못 처리되거나, 방어자가 해석할 수 있는 방식으로 활동이 기록되지 않을 경우 피해 범위가 훨씬 넓어진다.

이는 빠른 배포를 원하는 기업 AI 프로그램에서 특히 중요하다. 제품 팀은 접근 관리를 구현 세부사항으로 취급하면서, 에이전트가 Slack, Salesforce, 문서 저장소, 티켓팅 플랫폼, 내부 대시보드 전반에서 동작할 수 있도록 넓은 자격 증명을 부여할 수 있다. 그 결과 인간 사용자에게 적용되는 일반적인 생애주기 통제 바깥에 숨은 기계 접근 계층이 생길 수 있다.

보도에서 지적한 기업 보안 격차

인용된 기사들의 전체 원문은 출처 노트에 없으므로, 이 묶음에 대해 가장 타당한 해석은 두 매체 모두 조직이 AI 기반 행위자를 만들어 내는 속도가 이들을 위한 정책과 거버넌스를 구축하는 속도보다 빠르다는 구조적 문제를 지적하고 있다는 것이다.

TechRepublic는 이를 새로운 기업 보안 격차로 설명한다. 이 표현은 도입과 통제 사이의 운영적 불일치를 시사한다. 기업은 직원 신원, 특권 접근 관리, 서비스 계정에 대한 정책을 갖고 있을 수 있지만, AI 에이전트가 어떻게 인증해야 하는지, 자율 시스템의 최소 권한은 어떤 모습이어야 하는지, 에이전트 자격 증명은 얼마나 오래 유지돼야 하는지, 실험이 끝났을 때 접근 권한을 어떻게 회수해야 하는지에 대한 명확한 기준은 여전히 없을 수 있다.

BankInfoSecurity의 프레이밍은 더 직접적으로 신원 보안에 초점을 맞춘다. 이 강조는 AI 리스크가 실제로 구체화되는 지점이 대개 신원이기 때문에 중요하다. AI 에이전트는 민감한 시스템에 이미 정당한 접근 권한을 갖고 있다면, 소프트웨어 취약점을 악용하지 않고도 피해를 줄 수 있다. 잘못 설정되거나 과도한 권한을 가진 에이전트는 기록을 유출하거나 의도하지 않은 비즈니스 행위를 유발하거나, 여러 기업 도구를 한 번에 열 수 있는 토큰과 비밀 정보를 노리는 공격자에게 매력적인 표적이 될 수 있다.

이 격차는 하나의 배포 방식에만 국한되지 않는다. 내부 코파일럿, 고객 지원 자동화, 개발자 도구, 워크플로 오케스트레이션 시스템에서도 나타날 수 있다. 사람이나 팀을 대신해 AI 에이전트를 사용하는 환경이라면 누구나 어려운 질문에 답해야 한다. 신원 스택에서 에이전트는 누구이며, 그것이 무엇을 할 수 있는지에 대해 누가 책임을 지는가?

실제 워크플로에서 위험이 드러나는 지점

빌더와 보안팀에게 이 문제는 구현 세부사항을 통해 이해하는 것이 가장 쉽다. 많은 AI 에이전트는 모델 API, 오케스트레이션 프레임워크, 커넥터, 기업 앱 권한으로 구성된다. 이론상 모든 커넥터는 좁게 범위가 설정돼야 한다. 하지만 실제로는 세밀한 권한 설정이 느리고 데모를 망가뜨릴 수 있기 때문에 팀들이 넓은 접근으로 시작하는 경우가 많다.

그 결과 여러 실패 모드가 생긴다. 하나는 과도한 프로비저닝이다. 에이전트가 필요 이상으로 시스템에 대한 읽기 및 쓰기 권한을 받는 경우다. 또 하나는 지속성이다. 프로토타입용으로 생성된 API 키나 OAuth 토큰이 프로젝트가 다른 사람에게 넘어간 뒤에도 오래 활성 상태로 남아 있을 수 있다. 세 번째는 가시성이다. 로그에는 시스템 계정이 기록을 건드렸다는 사실만 보이고, 그 행위가 사용자, 워크플로 규칙, 혹은 AI 에이전트의 추론 결과로 시작됐는지는 보이지 않을 수 있다.

조직이 다단계 프로세스에 AI 에이전트를 도입할수록 이러한 문제는 더 복잡해진다. 예를 들어 구매 지원 에이전트는 정책 문서를 확인하고, 요청을 생성하고, Slack으로 관리자에게 알리고, Salesforce의 기록을 업데이트할 수 있다. 각 단계는 개별적으로는 타당할 수 있다. 하지만 권한, 승인 게이트, 감사 추적이 함께 설계되지 않으면, 기업은 누가 무엇을 승인했는지, 왜 변경이 일어났는지, 자동화가 위임된 범위를 넘었는지에 대한 확신을 잃을 수 있다.

같은 논리는 개발 환경에도 적용된다. 내부 코딩 또는 운영 에이전트는 저장소 접근, 클라우드 권한, 배포 권한이 필요할 수 있다. 통제가 느슨하면 비인간 신원이 사람에게 부여되었다면 훨씬 더 엄격한 검토를 받았을 권한을 조용히 축적할 수 있다.

증거, 주장, 그리고 아직 불확실한 점

이 이야기에서 가장 강하게 확인되는 사실은 출처 증거가 뒷받침하는 범위로 제한된다. BankInfoSecurity는 “AI Agents Are Creating a New Identity Security Problem”이라는 제목의 보고서를, TechRepublic는 “AI Agents Are Creating a New Enterprise Security Gap”이라는 제목의 보고서를 발행했다. 두 보도 모두 조직 내부에서 AI 에이전트의 보안 영향에 대한 언론 및 업계의 관심이 커지고 있음을 보여준다.

하지만 이 증거가 제공하지 않는 것은 자세한 사고 건수, 이름이 공개된 피해 기업, 벤치마크 데이터, 또는 이 묶음과 연결된 특정 벤더 발표다. 따라서 이를 에이전트 관련 침해 사고가 광범위하게 확산되고 있다는 증거로 제시하는 것은 과장이다. 현재의 증거는 정량화된 시장 조사표가 아니라, 기업 위험 노출과 통제 격차에 대한 트렌드성 이야기만을 뒷받침한다.

이 구분은 AI 보안 시장이 벤더 주장으로 가득 차 있기 때문에 중요하다. 신원 공급업체, 클라우드 보안 기업, AI 거버넌스 스타트업 모두 AI 에이전트, 비인간 신원, 기업 AI 리스크를 중심으로 자사 제품을 포지셔닝하고 있다. 직접적인 원문이 없는 한, 도입 수준, 공격 빈도, 제품 효용에 대한 주장은 독립적으로 검증되기 전까지는 벤더 보고로 취급해야 한다.

그럼에도 핵심 위험 논리는 단순하며, 자극적인 사고 데이터에 의존하지 않는다. 기업이 의미 있는 접근 권한을 가진 비인간 신원을 더 많이 만들수록, 그에 맞춰 거버넌스의 필요성도 커진다. 이는 클라우드 보안에서 이미 잘 알려진 패턴이며, AI 에이전트가 이를 가속하고 있는 것으로 보인다.

이것이 기업 AI 팀에 의미하는 것

기업 구매자에게 실질적인 시사점은 AI 에이전트를 단순히 모델 위에 얹은 또 하나의 프런트엔드 경험으로 취급해서는 안 된다는 점이다. 에이전트는 접근 권한을 가진 소프트웨어 실체다. 즉, 기업 AI 프로젝트 검토에는 처음부터 신원 아키텍처가 포함돼야 한다. 인증 모델, 권한 부여 범위, 비밀 정보 처리, 승인 통제, 접근 회수 경로, 감사 로깅이 모두 그것이다.

빌더에게는 설계 우선순위가 바뀐다. 이제 에이전트가 데모에서 잘 작동하는 것만으로는 충분하지 않다. 팀은 어떤 작업이 באמת 자율 실행이 필요한지, 어떤 작업은 인간 개입이 필요한지, 어떤 시스템은 범용 에이전트가 절대 접근해서는 안 되는지를 알아야 한다. 최소 권한, 단기 자격 증명, 명시적 도구 허용 목록, 명확한 행동 로그는 더 이상 보안 후순위가 아니라 제품 요구사항이 된다.

CISO와 플랫폼 리더에게도 AI 에이전트는 애플리케이션 리스크와 신원 리스크의 경계를 흐리게 만든다. 이미 서비스 계정을 관리하는 보안 프로그램은 에이전트를 기존 통제 체계에 흡수할 수 있다고 가정할 수 있다. 어떤 경우에는 그렇게 될 것이다. 그러나 자율성, 도구 사용, 광범위한 워크플로 도달 범위가 결합되면 새로운 정책과 모니터링이 필요할 수 있다. 도전은 단지 침해를 막는 데 있는 것이 아니라, 소프트웨어가 위임된 권한으로 행동할 수 있을 때 책임성을 유지하는 데 있다.

경쟁 구도도 중요하다. IAM, PAM, 클라우드 보안 벤더들은 이제 기업 AI와의 관련성을 넓힐 새로운 기회를 얻었다. SaaS와 클라우드 인프라 전반에서 동작하는 AI 에이전트를 위한 비인간 신원 거버넌스, 에이전트 모니터링, 통제에 대한 포지셔닝이 더 많아질 것으로 예상된다.

다음에 주목할 점

다음에 볼 신호는 구체적인 것들이다. 첫째, 신원 및 보안 벤더들이 일반 서비스 계정이 아니라 AI 에이전트를 명시적으로 겨냥한 정책 기능을 추가하는지 보자. 둘째, 대기업들이 AI 에이전트가 어떻게 인증하고, 운영 시스템에서 행동하기 전에 어떤 승인이 필요한지에 대한 내부 표준을 공개하기 시작하는지 주목하자.

셋째, 사고 보도가 중요하다. 향후 공개에서 에이전트가 권한을 오용하거나, 커넥터를 통해 데이터를 유출하거나, 측면 이동의 경로가 되는 사례가 드러난다면 시장은 이론적 우려에서 예산이 배정된 통제 범주로 빠르게 이동할 것이다. 넷째, Slack과 Salesforce 같은 주요 기업 플랫폼에 주목하자. 이들이 네이티브 권한 모델, 감사 추적, 에이전트 전용 통제를 확장한다면, 시장이 이를 틈새 AI 문제가 아니라 주류 기업 아키텍처의 일부로 다루고 있다는 신호가 될 것이다.

마지막으로, 규제 당국과 감사인이 책임성을 어떻게 규정하는지도 살펴봐야 한다. AI 에이전트가 기업 시스템 안에서 더 많은 운영 결정을 내리기 시작하면, 추적 가능성과 위임된 권한에 대한 질문은 기술적 문제이면서 동시에 거버넌스 문제가 될 것이다.

Creati.ai 관점

여기서 중요한 변화는 AI가 완전히 새로운 보안 원칙의 범주를 도입했다는 것이 아니다. AI 에이전트가 오래된 신원 문제를 더 빠르게 움직이고 더 자율적인 형태로 패키징한다는 점이다. 기업은 이미 서비스 계정, 과도한 권한, 불완전한 자산 목록 관리에 어려움을 겪고 있다. AI 에이전트는 자동화의 속도와 비즈니스 가치를 높이지만, 동시에 이러한 약점을 더 쉽게 증폭시킨다.

창업자와 제품 팀에게 이는 경고이자 기회다. 경고는 신원 설계를 무시하는 에이전트 제품이 파일럿에서 생산 단계로 넘어갈 때 기업의 저항에 부딪힐 것이라는 점이다. 기회는 강력한 통제가 차별점이 될 수 있다는 점이다. 기업 AI에서는 유용성이 파일럿을 시작하게 만들지만, 신뢰할 수 있는 접근 관리가 대규모 도입 승인으로 이어지는 경우가 많다.