기업 AI 공격 표면의 3분의 2는 보이지 않는다, Snyk 경고

Snyk는 기업 AI 위험에 대한 충격적인 수치를 제시했다. 관련 공격 표면의 거의 3분의 2가 보안 팀의 직접적인 가시권 밖에 있을 수 있다는 것이다. Google News를 통해 부각된 이 경고는 일상 업무 전반에서 연결되는 에이전트, 플러그인, 데이터세트, 데이터 파이프라인에 주목한다. 기업이 AI 실험을 실제 운영 환경으로 옮기면서 이러한 구성 요소는 빠르게 늘어난다.

이 수치는 전체 기업 시장을 대상으로 한 독립 감사가 아니라 Snyk가 제시한 것이다. 이를 뒷받침하는 분석은 Snyk Evo와 연관된 500개 이상의 기업 환경에서 얻은 익명화 정보를 활용한다. 이 차이는 중요하다. 해당 데이터는 참여 환경을 보여 주지만, 더 광범위한 주장은 다른 플랫폼과 산업 전반에서 추가 검증이 필요하다.

이런 단서가 있더라도, Snyk가 설명하는 문제는 한 공급업체의 텔레메트리를 넘어선다. Cloud Security Alliance의 연구에 따르면 설문 대상 조직 중 68%는 AI 에이전트의 행동과 사람의 활동을 명확히 구분하지 못했다. OWASP도 프롬프트 인젝션, 과도한 권한, 통제되지 않는 자율성을 중대한 애플리케이션 위험으로 별도로 문서화했다.

따라서 핵심 충돌은 AI 도입과 저항 사이의 문제가 아니다. 알려진 애플리케이션, 인간 신원, 안정적인 인벤토리를 중심으로 구축된 보안 시스템과 빠르고 분산된 배포 방식 간의 충돌이다. 기업은 더 많은 소프트웨어에 추론과 행동 권한을 부여하는 동시에, 무엇이 자사 데이터에 연결돼 있는지에 대한 확신을 잃고 있다.

이 격차는 보안 팀을 압박할 뿐 아니라 개발자, 플랫폼 엔지니어, 조달 책임자, 사업 부서 책임자에게도 영향을 미친다. 어느 집단이든 AI 의존성을 새로 도입할 수 있다. 하지만 그 결과로 만들어진 모델, 플러그인, 신원, 데이터세트, API, 운영 작업의 연결 고리를 하나의 시스템에서 매핑할 수 있는 조직은 드물다.

Snyk의 경고가 Google News에 소개된 이유

Snyk의 가장 중요한 주장은 AI가 새로운 취약점을 만든다는 점이 아니다. 기업이 그러한 취약점을 만드는 시스템을 신뢰성 있게 파악할 수 없다는 점이다.

Snyk는 2026년 2월 소프트웨어 개발과 에이전틱 시스템을 아우르는 계층인 AI Security Fabric을 선보였다. 회사는 이 접근 방식이 소프트웨어 개발 수명 주기 전반에 걸쳐 가시성, 예방, 거버넌스를 결합할 것이라고 밝혔다.

이 제품 발표에는 Snyk의 2026 State of Agentic AI Adoption 연구 결과도 포함됐다. 회사에 따르면, 분석은 500개 이상의 기업 Evo 환경에서 얻은 익명화 인사이트를 다뤘다. Snyk는 배포된 모든 AI 모델이 데이터세트와 서드파티 도구를 포함해 거의 세 배에 달하는 숨겨진 구성 요소와 연결돼 있다고 밝혔다.

헤드라인 주장은 이 관찰을 한 단계 더 확장한다. Snyk는 기업 AI 위험의 약 3분의 2가 가장 눈에 띄는 모델 계층 아래에 있다고 말한다. 숨겨진 부분에는 개발이나 일상 업무 중 직원이 연결하는 에이전트 도구, 플러그인, 연결된 리포지토리, 외부 서비스, 데이터 파이프라인이 포함된다.

이러한 구성 요소가 자동으로 악성인 것은 아니다. 플러그인은 단순히 문서를 가져오거나, 내부 API를 호출하거나, 승인된 메시지를 보낼 수 있다. 보안 문제는 구성 요소와 그 권한, 입력 소스, 그리고 후속 작업을 촉발할 수 있는 능력 사이의 관계에서 발생한다.

모델 인벤토리만으로는 이러한 관계를 포착할 수 없다. 두 팀이 동일한 모델을 사용하더라도 전혀 다른 위험 프로필을 가진 에이전트를 통해 사용할 수 있다. 한 에이전트는 공개 문서를 요약할 수 있다. 다른 에이전트는 소스 코드를 읽고, 고객 기록을 조회하며, 운영 시스템에 변경 사항을 기록할 수 있다.

이 때문에 이 이야기는 직원이 승인받지 않은 챗봇을 사용한다는 익숙한 경고 이상으로 다뤄질 가치가 있다. 이제 Shadow AI에는 승인된 소프트웨어에 내장된 기능, 로컬 배포 모델, 에이전트 프레임워크, 브라우저 확장 프로그램, 자동화 서비스, 머신 ID가 포함된다. 일부는 정식 조달 절차를 통해 도입된다. 다른 일부는 직원이 업무를 마치기 위해 도구 하나를 더 연결할 때 나타난다.

Google News는 이 주장에 광범위한 배포 채널을 제공하지만, 집계가 그 근본 수치를 검증하는 것은 아니다. 독자는 3분의 2 추정치를 Snyk의 고객 관련 환경 데이터에서 도출된 공급업체의 발견으로 받아들여야 한다. 더 강한 결론은 기업이 에이전트 행동, 권한, 구성 요소 의존성을 인벤토리화하는 데 어려움을 겪는다는 보강 증거에 기반한다.

이 구분은 분석이 제품 마케팅으로 전락하는 것을 막는다. Snyk의 정확한 시장 전체 추정치는 여전히 검증의 여지가 있다. 그러나 가시성 문제 자체는 이미 여러 독립적이고 표준 지향적인 출처의 뒷받침을 받고 있다.

AI 공격 표면은 더 이상 애플리케이션 목록이 아니다

이제 실질적인 공격 표면은 변화하는 그래프처럼 작동하며, 모델, 신원, 도구, 데이터 저장소가 연결 관계를 통해 위험을 만들어 낸다.

전통적인 애플리케이션 보안은 비교적 안정적인 객체에서 출발한다. 팀은 애플리케이션을 소유하고, 리포지토리를 유지하며, 의존성을 추적하고, 알려진 인프라를 통해 배포한다. 보안 도구는 코드, 패키지, 컨테이너 이미지, 클라우드 구성, 노출된 엔드포인트를 스캔할 수 있다.

AI 네이티브 시스템에는 더 많은 가변 요소가 추가된다. Snyk의 AI-native applications 분석은 사전 학습 모델, 임베딩, 서드파티 에이전트, 데이터세트, 외부 서비스를 포함할 수 있는 공급망을 설명한다. 각 구성 요소는 애플리케이션의 소스 코드와 독립적으로 바뀔 수 있다.

임베딩은 콘텐츠의 의미를 비교하는 데 사용되는 수치 표현이다. 벡터 데이터베이스는 검색을 위해 수백만 개의 이러한 표현을 저장할 수 있다. 권한이나 소스 라벨이 잘못되면 에이전트는 사용자가 원래 접근해서는 안 되는 정보를 검색할 수 있다.

흔히 RAG로 줄여 부르는 검색 증강 생성은 모델이 답변을 만들기 전에 선택된 문서나 기록을 제공한다. RAG는 정확성을 높일 수 있지만, 또 다른 신뢰 경계를 만든다. 검색 계층은 에이전트가 어떤 소스를 검색할 수 있는지, 어떤 콘텐츠를 반환해야 하는지를 결정해야 한다.

도구는 더욱 중대한 경계를 만든다. 이메일, 소스 제어, 클라우드 인프라 또는 고객 데이터베이스에 연결된 에이전트는 텍스트 생성에 그치지 않을 수 있다. 개발자가 부여한 권한에 따라 정보를 읽고, 쓰고, 실행하고, 승인하거나, 전송할 수 있다.

이는 구매한 애플리케이션 중심으로 구성된 보안 인벤토리와의 불일치를 만든다. 기업은 모델 제공업체와 에이전트 프레임워크를 승인했을 수 있다. 그러나 배포 후 연결된 모든 도구 엔드포인트, 서비스 계정, 데이터세트, 프롬프트 템플릿, 플러그인에 대한 완전한 기록은 없을 수 있다.

이 연결 고리는 전통적인 릴리스 없이도 변할 수 있다. 모델 제공업체가 동작을 업데이트할 수 있다. 서드파티 도구가 기능을 추가할 수 있다. 데이터세트에 새 문서가 들어갈 수 있다. 사용자가 위임된 인증을 통해 애플리케이션이 접근할 수 있는 대상을 결정하는 OAuth 범위를 확장할 수도 있다.

이러한 변화가 중요한 이유는 위험이 조합에 따라 달라지기 때문이다. 읽기 전용 접근 권한을 가진 요약 에이전트의 피해 범위는 제한적이다. 같은 에이전트에 이메일 전송, 파일 편집, 제한 없는 웹 엔드포인트 호출 권한을 부여하면 조작된 입력이 전혀 다른 결과를 낳을 수 있다.

따라서 공격 표면에는 코드 취약점 이상이 포함된다. 과도한 권한, 오염된 컨텍스트, 노출된 자격 증명, 안전하지 않은 출력 처리, 취약한 승인 규칙, 불완전한 작업 로그도 포함된다. 이들 문제 중 상당수는 소스 파일이나 알려진 소프트웨어 패키지만 검사하는 스캐너에서 보이지 않는다.

엔지니어링 팀에게 문서화는 통제 시스템의 일부가 된다. 아키텍처 결정, 승인된 도구, 권한 범위, 사고 조사 결과를 검색 가능한 형태로 기록하면 개별 대시보드가 놓치는 관계를 파악하는 데 도움이 된다. 구조화된 engineering knowledge base는 이 작업을 지원할 수 있지만, 보안 모니터링을 대체하지는 않는다.

더 큰 교훈은 단순하다. AI 시스템은 하나의 모델 엔드포인트로 거버넌스할 수 없다. 운영 전반에서 데이터, 도구, 신원, 작업이 계속 보이는 연결형 애플리케이션으로 다뤄야 한다.

에이전틱 AI가 신원 통제를 압박한다

가장 빠르게 커지는 사각지대는 자율 소프트웨어가 인간 사용자를 위해 설계된 권한을 상속하는 지점에 있다.

Cloud Security Alliance는 2026년 3월 agent identity research를 발표했다. 이 설문조사에서는 73%의 조직이 향후 1년 안에 AI 에이전트가 필수적이 될 것으로 예상했다. 그러나 68%는 에이전트가 수행한 작업과 사람이 수행한 작업을 명확히 구분하지 못했다.

이 68% 수치와 Snyk의 약 3분의 2 경고는 유사해 보이지만, 서로 다른 대상을 측정한다. Snyk는 AI 환경 전반의 숨겨진 구성 요소와 위험을 다룬다. Cloud Security Alliance 설문은 신원 귀속과 접근 관리에 초점을 맞춘다.

두 조사 결과는 함께 동일한 구조적 약점을 드러낸다. 조직은 인증, 권한 부여, 모니터링 방식을 업데이트하는 속도보다 더 빠르게 소프트웨어 신원에 비즈니스 시스템 접근 권한을 부여하고 있다.

머신 ID는 사람이 아닌 소프트웨어가 사용하는 자격 증명이다. API 키, 서비스 계정, 인증서, 워크로드 ID 또는 OAuth 토큰 형태를 취할 수 있다. 에이전트는 데이터에 접근하고 작업을 수행하기 위해 이러한 자격 증명에 의존한다.

인간 신원 시스템은 대체로 사람이 로그인하고, 정의된 역할을 부여받으며, 해당 계정에 연결된 활동을 생성한다고 가정한다. 에이전트는 이 모델을 복잡하게 만든다. 하나의 에이전트가 여러 사용자를 대신해 행동하고, 여러 도구를 호출하며, 수초 안에 머신 생성 작업의 연쇄를 만들 수 있다.

에이전트가 공유 서비스 계정을 사용할 때 귀속은 특히 어려워진다. 로그에는 해당 계정이 기록을 변경했거나 파일을 다운로드한 사실이 나타날 수 있다. 그러나 그 작업을 유발한 직원 요청, 모델 결정, 검색된 문서 또는 플러그인 호출은 식별하지 못할 수 있다.

이는 단순한 감사상의 불편이 아니다. 취약한 귀속은 사고 대응을 더 어렵게 만든다. 보안 팀은 어떤 에이전트, 사용자 또는 워크플로가 의심스러운 활동을 시작했는지 모른다면 적절한 자격 증명을 확실히 폐기할 수 없다.

과도한 권한은 피해를 키운다. 메시지를 요약하는 용도로만 구축된 도구가 메시지를 전송하거나 삭제할 권한을 받을 수 있다. 코드 어시스턴트는 하나의 프로젝트만 검토하면 되는데도 여러 리포지토리에 대한 쓰기 권한을 얻을 수 있다.

OWASP는 이러한 상태를 excessive agency라고 설명한다. 해당 지침은 과도한 기능, 권한, 자율성을 근본 원인으로 지목한다. OWASP는 사용 가능한 도구를 제한하고, 권한을 좁히며, 사용자 컨텍스트에서 작업을 실행하고, 영향이 큰 작업에 승인을 요구할 것을 권고한다.

이러한 통제는 성숙한 제로 트러스트 관행과 닮아 있다. 각 요청은 구체적인 신원, 정의된 권한 부여, 현재 컨텍스트를 바탕으로 평가돼야 한다. 모델이 작업 허용 여부를 스스로 결정해서는 안 된다.

에이전트는 인간 운영자와 구별되는 자체 ID도 필요하다. 로그는 사용자의 요청, 에이전트 인스턴스, 선택된 도구, 사용된 자격 증명, 그리고 그에 따른 작업 결과 사이의 관계를 보존해야 한다. 이 연결 고리가 없다면 기업은 막대한 양의 텔레메트리를 수집하고도 여전히 상황을 파악하지 못할 수 있다.

이 지점에서 AI 도입은 보안 아키텍처에 압박을 가한다. 비즈니스 팀은 반복적인 승인 절차를 없애고 여러 단계의 작업을 완료하는 보조 도구를 원한다. 보안 팀은 점검 지점, 제한된 권한, 그리고 재구성 가능한 의사결정 과정을 필요로 한다. 모든 점검 지점을 없애면 속도는 높아지지만, 잘못되거나 조작된 작업이 초래할 수 있는 피해 범위도 커진다.

이 갈등은 완전한 자율성을 선택하거나 에이전트를 금지하는 방식으로 해결되지 않을 것이다. 기업은 결과의 중요도에 따라 서로 다른 수준의 자율성을 적용해야 한다. 요약문 작성은 자동으로 유지할 수 있다. 자금 송금, 기록 삭제, 운영 인프라 변경, 보호 대상 데이터 공개에는 더 강력한 통제가 필요하다.

진짜 상충 관계는 속도와 검증 가능한 통제 사이에 있다

에이전트가 시스템 경계를 넘을 때 기업은 가치를 얻지만, 연결이 하나 늘어날 때마다 행동을 검증하기는 더 어려워진다.

에이전트형 AI가 기업에 매력적인 이유는 분리된 단계를 하나의 워크플로로 연결할 수 있기 때문이다. 고객 지원 에이전트는 티켓을 읽고, 계정 이력을 조회하고, 긴급도를 분류하고, 답변을 제안한 뒤 고객 기록을 업데이트할 수 있다. 이 순서는 수작업 조율을 줄일 수 있다.

그러나 같은 순서 안에는 여러 보안 경계가 존재한다. 티켓에는 신뢰할 수 없는 텍스트가 포함될 수 있다. 계정 이력에는 보호 대상 데이터가 들어 있을 수 있다. 모델은 안전하지 않은 도구 지시를 생성할 수 있다. 고객 시스템은 지속적인 영향을 미치는 업데이트를 수용할 수 있다.

프롬프트 인젝션은 이 상충 관계를 구체적으로 보여 준다. 프롬프트 인젝션은 조작된 콘텐츠가 모델의 지시 이행 방식을 바꾸는 경우를 말한다. 이러한 콘텐츠는 사용자에게서 직접 오거나 웹페이지, 문서, 이메일, 저장소 또는 검색된 기록을 통해 간접적으로 유입될 수 있다.

기존 애플리케이션은 엄격한 구문과 접근 제어를 통해 명령과 데이터를 분리한다. 언어 모델은 둘 다 컨텍스트 안의 토큰으로 처리한다. 이 설계 때문에 모델이 외부 텍스트를 지시가 아닌 신뢰할 수 없는 데이터로 항상 처리하도록 보장하기는 어렵다.

OWASP의 최신 가이드라인은 완벽한 프롬프트 인젝션 방지 방법은 알려져 있지 않다고 말한다. 또한 행동을 제한하고, 예상 출력 형식을 검증하며, 입력과 출력을 필터링하고, 모델에 부여되는 권한을 제한할 것을 권고한다.

이러한 완화 조치는 영향을 줄이지만 확실성을 만들지는 않는다. 제한된 문서 컬렉션만 읽을 수 있는 에이전트는 셸 명령을 실행할 수 있는 에이전트보다 위험이 적다. 사람의 승인 단계는 의심스러운 작업을 포착할 수 있지만, 검토자가 정보에 근거한 결정을 내릴 수 있을 만큼 충분한 컨텍스트를 제공받을 때에만 가능하다.

속도는 각 보호 장치에 압박을 가한다. 팀은 반복적인 통합 작업을 피하기 위해 광범위한 접근 권한을 부여할 수 있다. 사용자별 권한 부여는 구현에 시간이 더 걸리므로 공유 자격 증명을 사용할 수 있다. 사용자가 마찰을 불평하면 승인 프롬프트를 없앨 수도 있다.

따라서 핵심 경쟁 구도는 배포 속도와 검증 가능한 통제 사이의 상충 관계다. Snyk은 AI 시스템이 간헐적인 검토로 대응하기에는 너무 빠르게 변화하므로 보안도 지속적이어야 한다고 주장한다. 이 회사는 해당 요구 사항을 중심으로 포지셔닝된 제품을 판매하므로 상업적 이해관계도 분명하다.

따라서 구매자는 진단과 제안된 플랫폼을 분리해서 봐야 한다. 통합 보안 계층은 가시성을 개선할 수 있지만, 대규모 기업 전반의 모든 모델, 로컬 배포 환경, 브라우저 도구, 데이터세트, ID, 외부 통합을 하나의 제품이 관찰할 수 있음을 입증한 공급업체는 없다.

범위에 대한 주장은 통합과 텔레메트리에 달려 있다. 승인된 클라우드 모델은 탐지하기 쉬울 수 있다. 개발자 워크스테이션에서 로컬로 호스팅되는 모델은 그렇지 않을 수 있다. 익숙한 소프트웨어 패키지 안의 AI 기능은 일반 애플리케이션 트래픽처럼 보이는 활동을 생성할 수 있다.

암호화된 연결과 개인정보 보호 규정은 추가적인 한계를 만든다. 프롬프트나 검색된 문서를 모니터링하면 민감한 직원 및 고객 데이터가 노출될 수 있다. 보안 팀은 기밀 정보의 두 번째 저장소를 만들지 않으면서 오용을 탐지할 수 있을 만큼의 컨텍스트를 확보해야 한다.

지역별 데이터 규정은 또 다른 제약을 더한다. 다국적 기업은 모든 AI 상호작용 로그를 중앙화하지 못할 수 있다. 현지 처리, 선별된 메타데이터, 보존 통제, 그리고 관할권별로 다른 모니터링 정책이 필요할 수 있다.

이러한 복잡성이 Snyk의 경고를 무효화하지는 않는다. 오히려 단순한 해결책에 의문을 제기하면서도 그 핵심 주장을 강화한다. 가시성은 필요하지만, 가시성 자체에도 설계·개인정보 보호·운영상의 비용이 따른다.

3분의 2라는 주장이 입증하지 못하는 것

Snyk의 데이터는 심각한 거버넌스 공백을 시사하지만, 모든 기업 환경의 3분의 2가 침해됐거나 악용 가능하다는 점을 입증하지는 않는다.

가장 중요한 한계는 표본 추출이다. Snyk은 500개가 넘는 엔터프라이즈 Evo 환경에서 얻은 익명화된 인사이트를 설명한다. 해당 환경을 사용하는 조직은 규모, 소프트웨어 관행, AI 성숙도 또는 보안 우선순위 면에서 더 넓은 시장과 다를 수 있다.

이 회사는 자사 표본이 모든 산업 또는 지리적 지역을 대표한다는 점을 공개적으로 확립하지 않았다. 또한 더 광범위한 보안 커버리지를 선호하는 방식으로 문제를 정의할 상업적 이유도 있다. 어느 쪽도 데이터를 거짓으로 만들지는 않지만, 둘 다 신중한 출처 표기를 요구한다.

“위험”은 “취약점”보다 더 넓은 개념이다. 숨겨진 구성 요소는 악용 가능한 결함을 포함하지 않더라도 관리되지 않거나 자산 목록에 충분히 반영되지 않았을 수 있다. 이는 취약한 권한, 민감한 데이터, 안전하지 않은 입력 또는 중대한 작업을 수행할 능력과 결합될 때 위험해진다.

마찬가지로 “3분의 2”는 보안 팀이 모든 환경의 정확히 3분의 1만 본다는 뜻이 아니다. 이 추정치는 관찰된 환경의 패턴을 요약한다. 개별 조직의 커버리지는 훨씬 더 좋거나 나쁠 수 있다.

“공격 표면”이라는 표현은 서로 다른 문제를 더 모호하게 만들 수 있다. 여기에는 인터넷에 노출된 자산, 내부 API, 소프트웨어 의존성, 에이전트 도구, 데이터 흐름, ID, 모델 행동이 포함될 수 있다. 공급업체마다 이러한 요소를 다르게 계산한다.

독립적인 측정을 위해서는 공통된 정의가 필요하다. 연구자는 알려진 자산과 알려지지 않은 자산, 도달 가능한 구성 요소와 비활성 구성 요소, 이론적 노출과 입증된 공격 경로를 구분해야 한다. 이러한 구분이 없다면 큰 비율은 관심을 끌 수 있어도 운영상 지침은 제한적으로만 제공한다.

NIST는 AI Risk Framework를 통해 보다 중립적인 토대를 제공한다. 이 프레임워크는 AI 위험을 거버넌스, 매핑, 측정, 관리 중심으로 정리한다. 또한 위험 관리는 시스템 수명 주기 전반에 걸쳐 지속되어야 한다는 점을 강조한다.

매핑은 Snyk의 주장과 특히 관련이 깊다. 조직은 위험을 측정하기 전에 모델, 의도된 작업, 사용자, 데이터, 의존성, 배포 맥락 및 영향을 받는 당사자를 식별해야 한다. 스캐너가 누락된 모든 정책이나 소유권 결정을 복원할 수는 없다.

측정에는 테스트도 필요하다. 기업은 에이전트의 의도된 권한을 문서화해 놓고도 운영 환경에서 실제 권한을 검증하지 않을 수 있다. 승인된 도구를 기록하면서 업데이트된 통합을 통해 추가된 기능은 간과할 수 있다.

따라서 회의적인 관점은 사각지대가 가상의 문제라는 것이 아니다. 한 공급업체의 텔레메트리만으로는 아직 시장 전체에서 그 정확한 규모를 정의할 수 없다는 것이다. 이 헤드라인은 자산 목록화와 테스트를 촉진해야 하며, 둘 중 어느 하나를 대체해서는 안 된다.

보안 리더는 공급업체에 커버리지를 어떻게 계산하는지 물어야 한다. 분모, 탐지 방식, 제외된 환경, 업데이트 빈도, 중복되거나 오래된 자산을 해결하는 절차를 요청해야 한다. 이 맥락 없는 정확한 비율은 잘못된 확신을 만들 수 있다.

또한 결과를 측정해야 한다. 더 많은 구성 요소를 발견하는 일은 조직이 위험한 관계의 우선순위를 정하고, 소유자를 지정하고, 권한을 줄이고, 검증된 경로를 개선할 수 있을 때에만 유용하다. 관리할 수 없는 경보 대기열을 만드는 더 큰 자산 목록은 또 다른 형태의 사각지대가 될 수 있다.

사각지대가 해소되고 있는지 보여 줄 세 가지 신호

다음 단계는 ID 귀속, 구성 요소 목록, 그리고 위험한 에이전트 권한의 검증된 감소를 통해 측정될 것이다.

첫 번째 신호는 기업이 로그에서 에이전트 활동과 인간 활동을 구분할 수 있는지 여부다. Cloud Security Alliance의 68% 조사 결과는 직접 텔레메트리가 아닌 설문조사에서 나온 것이긴 하지만 명확한 기준선을 제공한다.

개선은 중대한 모든 작업에 에이전트 ID, 사용자 위임, 도구 이름, 권한 부여 맥락, 추적 가능한 결과가 함께 기록된다는 뜻이다. 이후 조사에서 귀속에 어려움을 겪는 조직이 줄어든다면, 관리 가능한 에이전트 거버넌스를 위한 근거는 더 강해질 것이다.

그 수치가 여전히 3분의 2 수준에 머문다면 반대의 결론이 나온다. 기업은 기본적인 책임성을 해결하지 못한 채 더 많은 자율 워크플로를 배포하게 될 것이다. 이는 도입과 함께 가시성 격차가 커지고 있다는 Snyk의 경고를 강화할 것이다.

두 번째 신호는 일관된 AI 자재 명세서의 등장이다. AI 자재 명세서는 시스템에서 사용되는 모델, 데이터세트, 프롬프트, 프레임워크, 도구, 서비스, 의존성을 기록한다. 이는 소프트웨어 자재 명세서 개념을 AI 특화 구성 요소로 확장한다.

유용한 버전은 배포 환경과 동기화된 상태를 유지해야 한다. 조달 과정에서 만든 정적 문서는 이후에 연결된 도구와 데이터세트를 놓치게 된다. 단순히 목록을 만드는 것보다 자동화된 탐지, 소유자 지정, 버전 이력, 실제 권한의 증거가 더 중요하다.

상호 운용 가능한 인벤토리 형식이 널리 채택된다면 기업이 가시성을 되찾을 수 있다는 주장은 강화될 것이다. 공급업체별 대시보드에 계속 의존한다면 보안 제품, 클라우드 플랫폼, 로컬 환경 사이에는 사각지대가 남게 된다.

세 번째 신호는 조직이 운영 환경에서 과도한 에이전트 권한을 줄이는지 여부다. 보안 팀은 별도의 승인 없이 데이터를 쓸 수 있고, 코드를 실행할 수 있으며, 커뮤니케이션을 보낼 수 있고, 인프라를 변경하거나 민감한 저장소에 접근할 수 있는 에이전트의 수를 추적해야 한다.

그 수가 줄어들면 기업이 AI 거버넌스를 기술적 통제로 전환하고 있음을 보여 준다. 수가 늘어난다면 생산성 목표가 여전히 격리보다 우선한다는 의미다. 과도한 권한을 가진 에이전트와 관련된 사고 보고서는 이 지표를 특히 시급하게 만들 것이다.

이러한 신호는 기업이 공개하는 AI 정책의 양보다 더 중요하다. 정책은 의도를 설명한다. ID, 인벤토리, 권한, 로그는 실제 운영 상황을 드러낸다.

Snyk의 Google News 헤드라인은 이러한 현실을 기억하기 쉬운 하나의 경고로 압축했기 때문에 효과적이다. 정확히 3분의 2라는 수치는 여전히 공급업체에서 도출한 추정치지만, 근본적인 불일치는 무시하기 어렵다. AI 구성 요소는 많은 조직이 이를 발견하고, 분류하고, 관리할 수 있는 속도보다 빠르게 늘어나고 있다.

개발자에게 당장의 질문은 모든 에이전트 연결에 이름이 명시된 소유자와 필요한 권한이 있는지 여부다. 보안 팀에게는 로그가 사용자 요청에서 모델 결정, 후속 결과에 이르기까지 하나의 작업을 재구성할 수 있는지 여부다. 기업 구매자는 두 가지 모두에 대한 증거를 요구해야 한다.

다음 분기는 실질적인 시험 기회를 제공한다. 운영 중인 에이전트 하나를 선택해 모든 모델, 도구, ID, 데이터세트, 외부 호출을 매핑한 다음, 해당 맵을 기존 보안 기록과 비교하라. 두 관점이 크게 다르다면 사각지대는 이미 조직 내부에 있다. 일치한다면 권한과 승인 통제가 문서화된 대로 작동하는지 테스트하라. Google News가 경고를 전했다면, 이제 기업 텔레메트리가 답을 제공해야 한다.