ThreatBook RedAgents 출시, 단일 에이전트 모델에 복수의 AI 침투 테스트 도전장을 내밀다

ThreatBook은 최소 4개의 AI 침투 테스트 에이전트를 갖춘 RedAgents를 출시하며, 하나의 자율형 테스터가 완전한 보안 평가를 제공할 수 있다는 통념에 도전했다. ThreatBook RedAgents 출시는 경쟁 관계의 공격 시스템들을 조율된 테스트 풀로 전환한다. 다만 회사는 이 결합형 접근 방식이 더 적은 오탐으로 더 많은 취약점을 찾아낸다는 점을 입증하는 독립 비교 결과를 아직 공개하지 않았다.

RedAgents는 XBOW 및 Horizon3.ai 같은 자율 보안 플랫폼이 이미 형성한 시장에 진입한다. 이들 경쟁사는 대체로 하나의 플랫폼과 그 테스트 시스템의 성능을 판매한다. ThreatBook은 다른 선택을 했다. 보안팀이 하나의 인터페이스를 통해 여러 에이전트를 구성하고 결과를 비교해야 한다는 것이다.

이 차이가 핵심이다. 더 많은 에이전트는 서로 다른 공격 경로를 탐색할 수 있지만, 운영자가 관리해야 할 도구, 권한, 의사결정의 수도 늘어난다. RedAgents는 운영 위험을 증폭시키지 않으면서 적용 범위를 넓힌다는 점을 증명해야 한다.

ThreatBook RedAgents 출시는 경쟁의 단위를 바꾼다

ThreatBook은 또 하나의 자율형 스캐너를 내세우는 것이 아니다. 에이전트 집합 자체를 제품으로 포지셔닝하고 있다.

ThreatBook은 2026년 10월 16일 RedAgents를 발표했다. 회사는 이를 동일한 승인 대상에 대해 여러 AI 침투 테스트 에이전트를 실행하는 서비스형 소프트웨어 플랫폼이라고 설명한다.

AI 침투 테스트 에이전트는 모델, 보안 도구, 반복적 계획 수립을 활용해 악용 가능한 취약점을 식별하고 때로는 검증한다. RedAgents는 보안팀에 에이전트 선택, 대상 설정, 결과 검토를 위한 통합 인터페이스를 제공한다.

초기 구성에는 Artex Pro, Cyber(YanJi), Yanxun, CyberStrikeAI Enterprise Edition이 포함된다. ThreatBook은 평가 방식에 따라 이 시스템들을 독립적으로 또는 병렬로 실행할 수 있다고 밝혔다.

이 선택은 중요하다. 개별 침투 테스트 에이전트가 반드시 동일한 방식으로 대상을 분석하는 것은 아니기 때문이다. 한 에이전트는 웹 애플리케이션 로직을 우선할 수 있고, 다른 에이전트는 정찰이나 자격 증명 경로에 더 많은 시간을 쓸 수 있다.

ThreatBook CEO Feng Xue는 단일 공급업체 모델이 가시성을 제한하는 원인이라고 설명했다. 그의 주장은 같은 대상을 제공받더라도 두 에이전트가 서로 다른 취약점을 발견할 수 있다는 것이다.

회사는 RedAgents가 테스트 데이터, 로그, 취약점 발견 결과를 하나의 화면에 통합한다고 밝혔다. 이 설계는 별도 제품을 운영하고 보고서를 대조하는 데 필요한 수작업을 줄일 것으로 보인다.

RedAgents 출시는 이 오케스트레이션 계층을 중심으로 여러 안전성 주장을 제시한다. ThreatBook은 고객이 화이트리스트를 통해 테스트 범위를 정의하며, 에이전트는 이러한 승인된 매개변수 안에 머물러야 한다고 설명한다.

회사는 또한 테스트 데이터가 서드파티 에이전트로 전송되지 않고 자사 환경 안에 머문다고 밝혔다. 고객이 테스트 데이터의 완전한 삭제를 요청할 수 있도록 데이터 무보존 정책도 내세운다.

이러한 내용은 고객이나 독립 평가자가 현실적인 조건에서 검증하기 전까지는 공급업체의 주장에 머문다. 발표문은 에이전트가 예상치 못한 명령을 생성할 때 RedAgents가 어떻게 경계를 강제하는지 설명하지 않는다.

또한 모든 명령이 결정론적 정책 검사를 통과하는지도 명시하지 않는다. 발표 자료에는 긴급 중지, 속도 제한, 권한 격리, 민감한 작업에 대한 사람의 승인에 관한 세부 정보가 없다.

그럼에도 이 제품은 경쟁의 질문을 바꾼다. 구매자는 더 이상 어느 자율형 침투 테스터가 가장 뛰어난지만 묻는 것이 아니다.

하나의 시스템을 선택하는 것 자체가 잘못된 아키텍처인지 묻고 있다. ThreatBook은 오케스트레이션 계층이 연결된 개별 에이전트보다 더 큰 가치를 갖게 하려 한다.

이 제안은 여러 탐지 시스템이 같은 객체를 검사하는 멀티 엔진 악성코드 스캐닝과 닮았다. ThreatBook은 중복되는 결과와 중복되지 않는 결과가 모두 적용 범위를 개선할 수 있는 이유를 설명하기 위해 이 개념을 명시적으로 사용한다.

그러나 침투 테스트는 더 어려운 조정 문제를 만든다. 악성코드 엔진은 하나의 아티팩트를 평가하지만, 침투 테스트 에이전트는 실시간 서비스, 계정, 데이터베이스, 네트워크 제어와 상호작용할 수 있다.

따라서 에이전트를 결합하려면 결과를 수집하는 것 이상이 필요하다. 플랫폼은 작업을 조정하고, 간섭을 방지하며, 증거를 표준화하고, 의미 있는 차이를 숨기지 않으면서 중복 발견 결과를 식별해야 한다.

이러한 요구사항은 RedAgents를 단순한 제품 묶음이 아니라 운영 제어 평면으로 바꾼다. 이 역할을 신뢰성 있게 수행하는지가 애그리게이터 모델이 실질적 가치를 제공하는지를 결정할 것이다.

멀티 에이전트 AI 침투 테스트가 지금 등장하는 이유

이 시점은 정기 보안 평가에서 연속적이고 기계 속도의 검증으로 전환하는 흐름을 반영한다.

전통적인 침투 테스트는 종종 부족한 인력 전문가, 정해진 수행 기간, 수작업으로 작성된 보고서에 의존한다. 이 구조는 상세한 스냅샷을 제공하지만, 테스트가 끝난 직후 환경은 바뀔 수 있다.

오늘날 애플리케이션은 빈번하게 릴리스되고, 클라우드 자산은 동적으로 나타나며, 외부 노출 서비스는 다음 평가를 기다리지 않고 변화한다. 따라서 테스트 사이의 공백은 관리되지 않는 위험 기간이 될 수 있다.

ThreatBook은 AI 에이전트가 더 짧은 테스트 주기를 실현 가능하게 만든다고 주장한다. RedAgents는 보안팀이 침투 테스트를 연례 행사로 취급하는 대신 매일, 매주 또는 매월 평가를 실행하도록 설계됐다.

이 개념은 ThreatBook만의 것은 아니다. 자율형 테스트 공급업체들은 이미 지속적 평가, 재테스트, 공격 경로 검증을 일회성 컨설팅 업무의 대안으로 홍보하고 있다.

XBOW는 시스템이 웹 취약점을 자율적으로 찾아 악용하고, 검증한 취약점에 대한 증거를 생성한다고 설명한다. 회사는 2025년 HackerOne의 미국 리더보드에서 1위에 올랐다고 보고했다.

회사가 공개한 설명에 따르면 이 시스템은 그 과정에서 약 1,060건의 취약점을 제출했다. 사람 검토자는 보고서의 프로그램 준수 여부를 확인했지만, XBOW는 이들이 발견이나 악용 과정에는 참여하지 않았다고 밝혔다.

이 수치는 XBOW가 제공한 것이므로 RedAgents의 직접적인 벤치마크로 사용해서는 안 된다. 그럼에도 자율형 침투 테스트가 실험실 시연을 넘어섰다는 이유를 보여준다.

XBOW 벤치마크 이력은 진척도를 측정하는 일이 얼마나 어려운지도 보여준다. 회사는 처음에 기존 훈련 과제를 사용한 뒤 새로운 시나리오를 만들고 운영 중인 버그 바운티 대상으로 옮겨갔다.

ThreatBook은 완전한 RedAgents 플랫폼에 대한 비교 가능한 평가를 공개하지 않았다. 대신 구성 에이전트 개별 성과와 관련된 업적을 제시한다.

회사는 Cyber(YanJi)가 Tencent Cloud 해커톤에서 목표 문제 54개 중 54개를 해결했다고 밝혔다. 또한 Artex의 오픈소스 버전이 2026년 9월 Baidu의 Agent+ 공방 챌린지에서 우승했다고 설명했다.

CyberStrikeAI는 ThreatBook이 2026년 9월 인수하기 전에 GitHub 스타를 7,800개 이상 모은 것으로 알려졌다. 인기는 개발자 관심을 나타낼 수 있지만, 기업 테스트의 정확성이나 안전한 실행을 측정하지는 않는다.

이러한 에이전트 수준의 신호는 집계가 매력적으로 보이는 이유를 설명한다. 구매자는 어떤 에이전트가 모든 애플리케이션, 취약점 유형, 인프라 환경에서 우세할지 예측하지 않고도 여러 접근 방식을 이용할 수 있다.

이 모델은 또한 ThreatBook이 향후 시스템을 흡수할 수 있는 방식을 제공한다. 제품 페이지는 플랫폼이 상용, 학술, 오픈소스 에이전트를 계속 추가할 것이라고 밝힌다.

이는 새로운 기술마다 하나의 독점 에이전트를 다시 구축하는 것보다 잠재적으로 더 빠른 업데이트 경로를 만든다. 특정 전문 에이전트가 뚜렷한 역량을 제공할 때 플랫폼에 추가할 수 있다.

하지만 같은 설계는 평가와 거버넌스의 책임을 더 크게 만든다. ThreatBook은 어떤 에이전트가 자격을 갖추는지, 어떤 권한을 받는지, 고객이 어떻게 행동을 비교할 수 있는지를 결정해야 한다.

보안팀은 또한 두 에이전트가 실제로 독립적인 관점을 제공하는지 알아야 한다. 여러 제품이 동일한 모델 약점, 훈련 데이터, 도구, 계획 패턴을 공유할 수도 있다.

멀티 에이전트 가설은 다양성이 유용한 적용 범위를 낳을 때만 가치를 가진다. 비슷한 에이전트를 여러 번 실행하면 통찰을 늘리지 않은 채 활동만 늘릴 수 있다.

따라서 가장 중요한 RedAgents 지표는 연결된 도구의 수가 아니다. 강력한 단일 에이전트 기준선을 넘어, 해당 도구들이 안전하게 발견하는 검증된 비중복 발견 결과의 수다.

RedAgents와 단일 에이전트 침투 테스트 모델의 비교

핵심 경쟁은 포트폴리오 적용 범위와 하나의 엄격히 통제된 테스트 시스템이 제공하는 일관성 사이에 있다.

단일 플랫폼 공급업체는 하나의 아키텍처를 중심으로 평가의 모든 부분을 최적화할 수 있다. 계획 수립, 도구 접근, 증거 기준, 안전 규칙, 보고, 재테스트를 모두 통제한다.

이러한 수직 통합은 책임 소재를 단순화할 수 있다. 테스트가 비정상적으로 작동하거나 발견 결과의 신뢰성이 낮은 것으로 판명되면 고객은 검토할 하나의 시스템과 하나의 공급업체를 갖는다.

ThreatBook은 다양성을 얻기 위해 이 단순성의 일부를 포기한다. RedAgents는 서로 다른 강점과 기술 경로를 지닌 여러 팀이 만든 에이전트를 한데 모을 수 있다.

multi-agent platform은 선택을 고객의 결정으로 제시한다. 팀은 집중된 작업에 하나의 에이전트를 배포하거나 더 광범위한 교차 검증을 위해 여러 에이전트를 배포할 수 있다.

이는 서로 다른 공격 표면의 전문가들로 구성된 사람 기반 레드팀을 꾸리는 것과 닮았다. 웹 애플리케이션 전문가, 아이덴티티 전문가, 클라우드 테스터는 같은 환경에서 서로 다른 경로를 볼 수 있다.

하지만 사람 팀원들은 서로 소통하고, 충돌을 해결하며, 가정을 함께 재검토한다. 소프트웨어 에이전트가 같은 수준의 조정을 이루려면 명시적 오케스트레이션이 필요하다.

병렬 실행은 간섭도 일으킬 수 있다. 한 에이전트가 애플리케이션 상태를 바꾸거나, 토큰을 소비하거나, 잠금을 유발하거나, 다른 에이전트가 같은 경로에 도달하기 전에 증거를 변경할 수 있다.

출시 자료는 RedAgents가 이러한 충돌을 어떻게 처리하는지 설명하지 않는다. 또한 플랫폼이 위험한 작업을 순차화하는지, 각 에이전트를 별도의 테스트 환경에 격리하는지도 밝히지 않는다.

결과 집계는 또 다른 과제를 제기한다. 두 에이전트가 서로 다른 설명, 심각도 등급, 익스플로잇 증거를 사용해 동일한 근본 취약점을 보고할 수 있다.

유용한 플랫폼은 서로 다른 공격 경로를 병합하지 않으면서 그러한 중복을 인식해야 한다. 또한 사람 테스터가 각 발견 결과를 재현하고 우선순위를 정할 수 있도록 충분한 증거를 보존해야 한다.

ThreatBook은 RedAgents가 발견 결과를 자동으로 중복 제거하고 등급화한다고 밝혔다. 초기 에이전트 구성 전반에서 이 과정이 얼마나 정확히 작동하는지를 보여주는 데이터는 공개하지 않았다.

오탐 감소 역시 핵심 주장이다. 여러 에이전트를 실행한다고 해서 잘못된 결과가 자동으로 사라지는 것은 아니다.

특히 동일한 기반 모델이나 보안 도구를 공유할 경우, 에이전트들은 같은 잘못된 가정을 반복할 수 있다. 반대로 한 전문 에이전트가 찾아낸 올바른 발견 결과는 한 번만 나타날 수도 있다.

따라서 투표 시스템은 다른 에이전트가 재현하지 못했다는 이유로 가치 있는 결과를 거부할 수 있다. 모든 발견 결과를 합치는 방식은 반대의 문제를 일으켜 검토자를 압도할 수 있다.

RedAgents에는 단순한 합의보다 나은 의사결정 메커니즘이 필요하다. 재현된 발견 결과, 독립적으로 발견된 결과, 수동 검증이 필요한 전문 에이전트의 발견 결과를 구분해야 한다.

기존의 자율 침투 테스트 서비스도 경쟁자로 자리하고 있다. Horizon3.ai의 NodeZero는 자율적인 공격 경로 탐색에 집중하며, XBOW는 검증된 웹 취약점과 프로덕션 환경의 증거를 강조한다.

이러한 시스템은 구매자가 기대하는 기준점이 된다. 고객은 재현 가능한 익스플로잇, 명확한 영향 자산, 대응 가이드, 그리고 수정 후 신뢰할 수 있는 확인을 원할 것이다.

동일한 평가 과정에서 여러 에이전트가 실질적으로 다른 취약점을 발견한다면 RedAgents는 차별화할 수 있다. 여러 개별 계약보다 하나의 제어 플레인이 이러한 결과를 더 쉽게 관리하게 해준다면 경쟁 우위를 확보할 수도 있다.

고객이 상충하는 출력을 수작업으로 조사해야 한다면 애그리게이터는 장점을 잃는다. 연결된 에이전트가 전문 플랫폼 수준의 깊이를 제공하지 못해도 마찬가지다.

따라서 첫 번째 유의미한 비교는 동일한 대상, 범위, 테스트 기간을 사용해야 한다. 검증된 고유 발견 사항, 오탐, 운영 사고, 사람의 검토 시간을 측정해야 한다.

그런 증거가 없다면 RedAgents는 검증된 대체재가 아니라 그럴듯한 아키텍처에 머문다. 이번 출시는 제품의 방향성을 제시할 뿐, 우수성을 입증하지는 않는다.

오케스트레이션이 신호를 더할 때에만 메커니즘은 작동한다

더 많은 에이전트가 범위를 개선하려면 RedAgents가 그들의 행동을 제어하고 출력을 방어 가능한 증거로 전환해야 한다.

플랫폼의 첫 번째 역할은 범위 강제다. 침투 테스트에는 정의된 평가 범위를 벗어나면 권한이 없는 행위가 포함된다.

미국 국립표준기술연구소(NIST)는 교전 규칙을 테스트 시작 전에 설정되는 제약 조건으로 정의한다. 이러한 규칙은 무제한적인 권한을 부여하지 않으면서 특정 활동에 대한 권한을 제공한다.

NIST 가이드는 대상, 제한된 시스템, 허용되는 기법, 테스트 기간, 소스 주소를 중요한 평가 세부 사항으로 지목한다. 소프트웨어가 작업을 수행하더라도 테스트 규칙은 여전히 중요하다.

ThreatBook은 RedAgents가 테스트 범위를 정의하기 위해 화이트리스트를 사용한다고 말한다. 화이트리스트는 대상 주소를 제한할 수 있지만, 안전한 운영에는 더 세분화된 제어가 필요하다.

팀은 서비스 거부 기법, 파괴적인 데이터베이스 작업, 비밀번호 변경, 또는 프로덕션 고객 기록 접근을 금지해야 할 수 있다. 유지보수 기간과 요청률 제한도 필요할 수 있다.

멀티 에이전트 플랫폼은 연결된 모든 시스템에 이러한 제약을 일관되게 적용해야 한다. 각 에이전트가 서면 지침을 동일한 방식으로 해석한다고 가정할 수는 없다.

권한 부여는 모델의 추론 루프 외부에서 강제되어야 한다. 네트워크 제어, 격리된 자격 증명, 명령 정책, 대상 수준 권한은 프롬프트만으로 설정한 경계보다 더 강력하다.

이는 언어 모델 에이전트가 도구를 선택하고 행동 시퀀스를 동적으로 생성할 수 있기 때문이다. 이러한 유연성은 낯선 환경을 탐색하는 데 도움이 되지만, 이후의 모든 행동을 예측하기 어렵게 만든다.

OWASP는 이 문제의 한 형태를 과도한 에이전시라고 부른다. 이는 AI 시스템이 작업에 필요한 수준을 넘어선 기능, 권한 또는 자율성을 받을 때 발생한다.

OWASP는 사용 가능한 도구를 줄이고, 권한을 제한하며, 중요한 행동에는 사람의 승인을 요구하고, 다운스트림 시스템에서 권한 부여를 강제할 것을 권고한다. 해당 과도한 에이전시 가이드는 멀티 에이전트 환경에서 손상된 동료 에이전트에 대해서도 경고한다.

이 경고는 RedAgents에 직접 적용된다. 애그리게이터는 연결된 각 에이전트를 보안 역량의 원천이자 실패할 수 있는 구성 요소로 다뤄야 한다.

중앙화된 로깅이 도움이 될 수 있다. RedAgents는 참여 에이전트의 로그와 결과를 한곳에 기록하여 검토자에게 공통 감사 추적을 제공한다고 말한다.

공유 추적 기록은 어떤 에이전트가 각 명령을 실행했는지, 어떤 ID를 사용했는지, 어떤 대상이 응답했는지, 제어 장치가 요청된 행동을 변경했는지를 보여줘야 한다. 또한 검증된 모든 발견 사항에 대한 증거를 보존해야 한다.

데이터를 전혀 보존하지 않는 방식은 또 다른 운영상 절충점을 만든다. 민감한 테스트 데이터를 삭제하면 노출을 줄일 수 있지만, 고객은 대응, 감사, 사고 검토를 위해 선별된 증거가 필요할 수 있다.

따라서 플랫폼은 보존 정책을 명확하게 정의해야 한다. 구매자는 “완전한 삭제”의 범위, 삭제 시점, 백업이나 진단 로그에도 동일한 정책이 적용되는지 알아야 한다.

타사 에이전트가 플랫폼에 참여하면 데이터 격리는 더 복잡해진다. ThreatBook은 고객 테스트 데이터가 해당 제공업체에 전달되지 않고 자사 환경 내에 머문다고 말한다.

이 주장은 아키텍처 차원의 설명이 필요하다. 고객은 에이전트 코드가 ThreatBook이 관리하는 격리 환경에서 실행되는지, 외부 모델이 프롬프트를 받는지, 비밀 정보가 어떻게 필터링되는지 이해해야 한다.

플랫폼의 가치는 궁극적으로 증거 파이프라인에서 나온다. 보안 팀이 발견 사항을 신뢰하고, 재현하고, 우선순위를 정할 수 없다면 탐지 자체만으로는 충분하지 않다.

신뢰할 수 있는 멀티 에이전트 워크플로는 개별 증거를 보존하면서 통합 평가 결과를 생성할 것이다. 에이전트들이 언제 동의하고 언제 이견을 보이는지, 그리고 플랫폼이 최종 심각도를 선택한 이유를 보여줘야 한다.

RedAgents는 상위 수준의 설계를 설명했지만, 그 정도의 구현 세부 사항은 공개하지 않았다. 기술 문서와 통제된 고객 평가가 오케스트레이션이 실제로 신호를 더하는지 결정할 것이다.

안전성 문제는 제품의 일부다

RedAgents는 방어자에게 유용해야 하지만 통제되지 않는 공격 인프라가 되어서는 안 되는 공격 역량을 결합한다.

모든 자율 침투 테스트 제품은 이중 용도 문제에 직면한다. 기업의 방어 체계를 검증하는 데 도움이 되는 동일한 역량이 공격자의 정찰과 익스플로잇 자동화에도 쓰일 수 있다.

ThreatBook의 초기 구성은 이러한 긴장을 유난히 뚜렷하게 보여준다. 회사는 공격에서의 악용 의혹 이후 Artex가 2026년 10월 8일 오픈 소스에서 클로즈드 소스로 전환했다고 말한다.

ThreatBook의 발표는 이 결정을 한국 금융기관에 영향을 준 사고와 연결한다. 그러나 해당 발표는 모든 세부 사항을 뒷받침하는 완전한 독립 사고 보고서를 제공하지는 않는다.

그럼에도 이 사례는 직접적인 거버넌스 문제를 제기한다. 어떤 에이전트가 악용과 연관될 경우, RedAgents는 배포 전에 해당 코드, 모델, 종속성, 운영 동작을 어떻게 평가하는가?

회사는 Artex Pro가 오픈 소스 버전을 넘어 제어성, 안정성, 추적성을 제공한다고 말한다. 이러한 설명은 출시 자료에서 독립적인 검증을 받지 않았다.

도구를 인수하거나 상용화하면 책임성이 생길 수 있지만, 그것만으로 도구가 안전해지는 것은 아니다. 제어 장치는 실패, 악성 지침, 손상된 종속성, 예기치 않은 대상 응답에 대해 테스트되어야 한다.

에이전트 다양성은 테스트 플랫폼 내부의 공격 표면을 넓힐 수 있다. 모든 커넥터, 도구 통합, 모델 엔드포인트, 자격 증명 저장소, 보고 경로는 또 다른 잠재적 취약점을 만든다.

애그리게이터는 프롬프트 인젝션도 방어해야 한다. 악의적인 대상은 에이전트가 제한을 무시하거나 민감한 정보를 노출하도록 조작하기 위해 설계된 콘텐츠를 제시할 수 있다.

멀티 에이전트 통신은 또 다른 경로를 만든다. 손상된 에이전트는 오케스트레이터나 동료 에이전트의 선택에 영향을 주는 오해의 소지가 있는 컨텍스트를 생성할 수 있다.

OWASP는 에이전트 입력과 출력을 신뢰할 수 없는 것으로 취급할 것을 권고한다. 모든 권한 부여 결정을 모델에 위임하는 대신 결정론적 제어가 중요한 요청을 중재해야 한다.

ThreatBook의 화이트리스트와 중앙화된 데이터 모델은 이 문제의 일부를 해결한다. 하지만 개별 명령이 실행 전에 정책 집행을 받는지는 답하지 않는다.

회사는 또한 RedAgents를 위한 외부 감사, 명명된 설계 파트너, 또는 프로덕션 고객을 밝히지 않았다. 제한된 테스트는 그러한 증거를 생성할 수 있지만, 초기 도입자는 명확한 경계를 요구해야 한다.

구매자는 어떤 시스템이 지원되는지, 어떤 행동에 승인이 필요한지, 자격 증명이 어떻게 범위가 제한되는지 물어야 한다. 에이전트가 할당된 워크플로를 벗어날 때 어떤 일이 일어나는지도 물어야 한다.

롤백과 긴급 종료도 동등한 관심을 받을 만하다. 보안 운영자는 비정상적인 테스트 중에 모든 활성 에이전트를 중지하고, 자격 증명을 철회하며, 증거를 보존할 신뢰할 수 있는 방법이 필요하다.

독립 벤치마크는 취약점 수뿐 아니라 안전성 결과도 포함해야 한다. 더 많은 문제를 찾지만 장애를 일으키거나 비밀 정보를 부적절하게 처리하는 시스템은 더 나은 평가를 제공하지 않는다.

테스트는 교육 환경과 프로덕션 시스템도 분리해야 한다. 성숙한 자율 플랫폼조차 자동화된 보안 평가가 영향 제로를 보장할 수는 없다고 인정한다.

여러 에이전트가 동시에 작동하면 부담은 커진다. 더 많은 활동은 방어 제어를 작동시키거나 계정을 잠그거나 요청률에 민감한 서비스에 영향을 줄 수 있다.

RedAgents는 동시성을 가시화하고 구성 가능하게 해야 한다. 고객은 테스트 기간, 요청률, 보호된 엔드포인트, 동시 행동의 최대 수를 제어할 필요가 있다.

신중한 도입은 격리된 애플리케이션, 비프로덕션 복제본, 엄격히 범위가 제한된 외부 자산으로 시작할 것이다. 이후 팀은 접근 권한을 확대하기 전에 사람의 검증과 결과를 비교할 수 있다.

그 접근 방식은 제품의 가치를 약화시키지 않는다. 보안 팀에 어떤 에이전트가 자신의 환경에서 잘 작동하는지에 관한 증거를 제공할 것이다.

따라서 이번 출시는 역량과 위험을 분리할 수 없는 하나의 문제로 제시한다. RedAgents는 조율하는 공격 시스템만큼 제어 플레인이 정교할 때에만 성공한다.

RedAgents의 성과를 보여줄 세 가지 신호

다음 단계는 비교 증거, 강제 가능한 안전 제어, 실제 고객 도입을 통해 평가되어야 한다.

첫 번째 신호는 강력한 단일 에이전트 기준선과의 통제된 벤치마크다. ThreatBook은 동일한 대상, 자격 증명, 범위, 시간 제한을 사용한 테스트를 공개해야 한다.

유용한 결과는 전체 경고 수가 아닐 것이다. 검증된 고유 취약점, 중복 발견 사항, 오탐, 심각도 분포, 사람의 검증 시간을 보여줘야 한다.

RedAgents가 각 개별 참여자가 놓친 중요한 문제를 일관되게 발견한다면 그 벤치마크는 멀티 에이전트 주장을 강화할 것이다. 운영 작업이 더 많으면서 결과가 비슷하다면 그 주장은 약화될 것이다.

두 번째 신호는 상세한 안전성 문서다. ThreatBook은 명령 중재, 에이전트 격리, 자격 증명 제어, 승인 게이트, 보존 동작, 긴급 중지를 설명해야 한다.

독립 테스트는 기능 체크리스트보다 더 큰 비중을 가질 것이다. 구매자는 프롬프트 인젝션, 모델 오류, 손상된 동료 출력 때문에 에이전트가 범위를 벗어날 수 없다는 증거가 필요하다.

세 번째 신호는 제한된 시험을 넘어선 반복 도입이다. 명명된 사례 연구는 조직이 얼마나 자주 테스트를 실행하는지, 어떤 에이전트를 선택하는지, 발견 사항이 검증된 수정으로 이어지는지를 보여줘야 한다.

도입 데이터는 고객이 에이전트 선택권을 중시하는지, 아니면 단순히 하나의 기본 시스템을 선택하는지도 보여줄 것이다. 대부분의 사용자가 더 폭넓은 구성 목록을 무시한다면 애그리게이터 논지는 약화된다.

RedAgents는 실제 한계에 대한 일관된 해답과 함께 시장에 진입한다. 단일 테스트 접근 방식만으로는 모든 취약점을 발견할 수 없으며, 빈번한 소프트웨어 변경으로 정기적인 평가만으로는 충분하지 않게 된다.

그러나 에이전트를 추가한다고 보안이 더 좋아지는 것은 아니다. 플랫폼은 동등하게 다양한 위험을 만들지 않으면서 오케스트레이션이 다양하고 검증된 발견 사항을 생성한다는 점을 입증해야 한다.

ThreatBook RedAgents 출시를 평가하는 보안 리더는 좁은 비교부터 시작해야 한다. RedAgents와 기존 대안에 동일한 승인된 대상을 제공한 뒤, 확인된 발견 사항과 운영자 작업량을 측정해야 한다.

중요한 행동에 대해서는 사람의 검토를 유지하고 명시적인 교전 규칙을 요구해야 한다. 결과는 재현성, 대응 가치, 안전한 실행을 기준으로 평가해야 한다.

다음 분기의 핵심 질문은 분명하다. ThreatBook이 여러 개의 거버넌스 적용 에이전트가 성숙한 자율형 침투 테스트 에이전트 하나보다 더 뛰어난 성과를 낸다는 증거를 제시할 수 있을까? 에이전트 규모가 아니라 바로 그 결과가 멀티 에이전트 AI 침투 테스트가 지속 가능한 카테고리로 자리 잡을지를 결정할 것이다.