AI 에이전트의 플러그인도 공급망이다, AIR에 5000만 달러 몰린 이유

이스라엘 사이버보안 스타트업 AIR가 2026년 9월 1일 스텔스 상태에서 벗어나 총 5000만 달러의 투자 유치를 공개했다. Calcalist의 당일 보도 는 회사가 2026년 2월 설립됐으며 Sequoia Capital과 Greenoaks가 자금 조달을 주도했다고 전했다.

AIR가 같은 날 공개한 핵심 제품은 AI 에이전트의 모델을 검사하는 도구가 아니라, 에이전트가 받아들이는 정보와 외부 구성요소를 통제하는 보안 플랫폼이다. 회사의 9월 1일 공식 발표 는 검증되지 않은 애드온, 신뢰하기 어려운 웹사이트, 계속 변하는 사내 데이터가 에이전트의 컨텍스트에 도달하기 전에 걸러내는 ‘컨텍스트 방화벽’을 구축했다고 설명한다.

5000만 달러는 단일 라운드가 아니라 수주 간격으로 마감된 두 차례 시드 라운드의 합계다. TechCrunch가 확인한 투자 내역 에 따르면 Sequoia가 주도한 첫 라운드는 1000만 달러, Greenoaks가 주도한 두 번째 라운드는 4000만 달러였다.

투자금이 향한 곳은 에이전트의 새 공급망이다

AI 에이전트는 모델만으로 업무를 완성하지 않는다. 스킬에서 작업 절차를 읽고, 플러그인이나 MCP 서버로 외부 서비스에 접속하며, 웹페이지·이메일·사내 파일에서 얻은 정보를 바탕으로 코드를 실행하거나 시스템을 조작한다. 이때 에이전트가 불러오는 구성요소와 콘텐츠는 판단과 권한 사용에 직접 영향을 미친다.

이 구조가 전통적인 소프트웨어 공급망과 닮은 이유는 신뢰가 여러 외부 주체에 걸쳐 이어지기 때문이다. 승인된 에이전트라도 출처가 불분명한 스킬을 설치하거나 변조된 MCP 서버에 연결되면 그 구성요소의 위험을 함께 물려받는다. 공격자는 모델을 직접 침해하지 않고 에이전트가 읽는 문서나 내려받는 의존성에 악성 지시를 숨길 수도 있다.

차이점도 있다. 일반적인 패키지 관리는 설치 시점의 출처·버전·서명 확인이 중심이지만, 에이전트는 실행 도중 새로운 콘텐츠와 도구를 선택해 컨텍스트에 넣는다. 따라서 한 번 승인한 파일뿐 아니라 호출 시점의 웹 콘텐츠, 도구 응답, 구성요소의 변경 상태까지 통제 범위에 포함해야 한다는 것이 AIR의 사업 논리다.

5000만 달러가 몰린 이유도 이 통제 공백을 독립된 기업 보안 시장으로 본 투자 판단에서 찾을 수 있다. 다만 투자 규모는 AIR의 차단 성능이나 시장 지배력이 입증됐다는 뜻이 아니다. 아직 검증 단계인 문제에 두 대형 투자사가 큰 자본을 배치했다는 사실과 제품 효과가 확인됐다는 평가는 구분해야 한다.

AIR는 발견·판정·차단을 하나의 흐름으로 묶는다

AIR가 제시한 첫 통제 지점은 가시성이다. 엔드포인트와 클라우드, 서비스형 소프트웨어 환경에서 작동하는 에이전트를 찾아내고, 회사가 승인하지 않은 AI 도구나 개인 계정을 이용한 사용도 식별한다는 구상이다. 보안팀이 존재를 모르는 에이전트에는 허용 목록이나 접근 정책을 적용할 수 없기 때문이다.

다음 단계는 에이전트가 이용하는 스킬, 도구, MCP 서버와 애드온을 평가하는 일이다. AIR는 공개 생태계에서 수집한 구성요소의 변화와 악성 동작을 계속 확인하고, 에이전트가 스킬을 로드하거나 인터넷 콘텐츠를 가져올 때 이를 회사의 허용 목록과 대조한다고 설명한다.

마지막 단계에서는 집행 계층이 실제 상호작용을 가로채 분석한다. 소프트웨어나 외부 정보가 보안 기준을 통과하지 못하면 에이전트가 이를 컨텍스트에 넣거나 호출하지 못하게 막는 구조다. 이는 배포 전 검사와 실행 중 차단을 대체 관계가 아니라 연속된 통제로 본 접근이다.

회사가 강조하는 사전 필터링은 위험한 입력이 모델의 판단 재료가 된 뒤 대응하는 대신, 컨텍스트에 들어오기 전에 제거하려는 설계다. 그러나 공개된 설명만으로 어떤 에이전트 프레임워크와 MCP 구현을 지원하는지, 암호화된 트래픽이나 폐쇄형 사내 구성요소를 어떤 방식으로 분석하는지는 아직 판단하기 어렵다.

일회성 승인으로는 구성요소의 변화를 잡지 못한다

스킬이나 플러그인이 오늘 안전 판정을 받았다고 해서 이후에도 같은 상태라는 보장은 없다. 스킬 파일 자체가 수정되지 않아도 참조하는 저장소나 내려받는 패키지가 교체될 수 있고, 개발자 계정이나 연결 도메인의 소유권이 바뀔 수도 있다. MCP 서버도 운영 주체와 응답 내용이 달라지면 동일한 이름 아래에서 다른 위험을 전달할 수 있다.

따라서 AIR가 말하는 허용 목록은 고정된 제품 목록보다 변경을 추적하는 정책 장치에 가깝다. 구성요소에 변화가 생길 때마다 다시 평가하고, 악성·취약·미승인 상태가 확인되면 그 구성요소에 의존하는 에이전트와 업무 흐름을 찾아 조직 전체에서 사용을 철회하는 방식이다.

AIR 최고경영자 야이르 사반은 회사가 온라인에서 발견한 애드온과 스킬 가운데 약 27%를 현재 걸러낸다고 밝혔다. 이 수치는 AIR가 자체 수집한 표본과 판정 기준에서 나온 회사 주장이다. 표본 구성, 오탐과 미탐, 제3자의 재현 결과가 공개되지 않은 만큼 전체 에이전트 생태계의 위험 비율이나 기업 환경에서의 차단 정확도로 일반화할 수 없다.

일회성 스캔과 지속 재검증의 차이는 바로 여기에 있다. 전자는 특정 시점의 파일과 설정을 보여주지만, 후자는 승인 이후 발생한 변경과 실제 호출 시점의 상태를 다시 정책 판단에 넣는다. AIR가 투자자에게 제시한 경쟁력도 더 많은 항목을 한 번 검사한다는 데 있지 않고, 변화할 때마다 전체 에이전트 환경에서 다시 판정한다는 데 있다.

기업이 구분해 봐야 할 세 가지 통제 지점

AIR의 발표를 기업 보안 운영의 관점에서 보면 점검 대상은 입력, 도구 호출, 변경 관리의 세 층으로 나뉜다. 특정 제품의 도입 여부와 관계없이 이 층을 분리해야 어느 단계에서 위험을 발견하고 실제 실행을 중단할 수 있는지 확인할 수 있다.

• 입력 통제: 에이전트가 읽는 웹 콘텐츠, 이메일, 문서와 사내 데이터의 출처를 식별하고, 외부의 악성 지시가 정상적인 업무 명령처럼 컨텍스트에 섞이는 경로를 차단하는가.
• 도구 호출 통제: 스킬·플러그인·MCP 서버마다 허용된 작업과 접근 가능한 시스템을 제한하고, 실제 호출 순간에 미승인 구성요소나 정책 위반을 중단할 수 있는가.
• 변경 관리: 승인된 구성요소와 의존성이 바뀌면 자동으로 재평가하고, 영향을 받는 에이전트와 업무 흐름을 추적해 기존 승인을 회수할 수 있는가.

이 세 통제에 앞서 에이전트 인벤토리가 필요하다. 구성요소 평가 체계가 정교해도 개인 계정이나 미승인 도구에서 실행되는 에이전트를 찾지 못하면 정책은 알려진 자산에만 적용된다. 반대로 목록만 만들고 실행 경로에서 차단하지 못하면 보안팀은 위험을 관찰할 수 있을 뿐 행동을 멈추지는 못한다.

허용 목록의 운영 방식도 중요하다. 공급자가 제공하는 공통 목록만 사용할지, 기업이 자체 기준과 예외를 적용할 수 있는지, 판정이 바뀌었을 때 기존 업무를 즉시 중단할지 단계적으로 제한할지에 따라 실제 통제 효과와 업무 영향이 달라진다.

5000만 달러 뒤에 남은 검증 과제

AIR의 공개와 자금 조달은 에이전트가 접촉하는 입력과 도구를 별도의 공급망으로 관리하려는 기업용 보안 제품이 큰 투자를 끌어냈다는 사실을 보여준다. 회사가 제시한 해법은 에이전트 발견, 구성요소의 사전 평가, 실행 시점의 차단, 변경 후 재검증을 하나의 관리 계층으로 연결하는 것이다.

반면 공개된 자료에는 차단 기준의 세부 내용, 오탐·미탐률, 검사로 생기는 처리 지연, 고객별 배포 방식이나 독립적인 성능 평가가 담기지 않았다. AIR가 제시한 차단 비율과 시장 전망 역시 회사 설명의 범위를 벗어나지 않는다.

현재 확인된 것은 AIR가 2026년 9월 1일 스텔스 상태를 끝내고 두 차례 시드 라운드로 총 5000만 달러를 조달했으며, AI 에이전트의 외부 구성요소와 컨텍스트를 계속 검사하는 플랫폼을 공개했다는 데까지다. 앞으로 판단해야 할 핵심은 투자금의 크기보다 서로 다른 에이전트와 MCP 구현에서 구성요소의 변화를 얼마나 빠르고 정확하게 찾아내며, 정상 업무를 과도하게 막지 않고 위험한 상호작용을 차단할 수 있는지다.