OX Security CNAPP 플랫폼, 클라우드 보안 태세와 AI 에이전트 런타임 방어를 통합
OX Security는 9월 16일 기존 클라우드 제어 기능과 AI 에이전트 실시간 모니터링을 결합한 CNAPP 플랫폼을 출시했다. OX Cloud라는 이름의 OX Security CNAPP 플랫폼은 자율 소프트웨어가 기업 도구에 대한 ID, 권한 및 접근 권한을 확보하면서 생겨난 보안 공백을 겨냥한다.
이번 출시는 단순히 클라우드 보안 기능 목록을 확장한 것이 아니다. OX는 보안팀에 코드, 클라우드 구성, ID, 데이터, 프롬프트, 그리고 실행 중인 에이전트의 활동을 연결하는 단일 그래프가 필요하다고 주장한다. 이는 기존 CNAPP 제품과 독립형 AI 보안 도구 모두에 도전하는 주장이다.
Palo Alto Networks를 비롯한 대형 보안 벤더들은 이미 런타임 보호, AI 보안 태세 관리, 에이전트 제어 기능을 제공하고 있다. 따라서 OX는 프롬프트부터 런타임까지의 맥락이 단지 더 넓은 대시보드가 아니라 더 나은 의사결정으로 이어진다는 점을 입증해야 한다.
핵심 질문은 이러한 신호를 결합하는 것이 방어팀이 실제로 도달 가능한 위험과 안전하지 않은 에이전트 행동을 분리하는 데 도움이 되는지다. 그렇다면 OX Cloud는 클라우드 취약점을 발견하는 단계와 자율 시스템이 이를 어떻게 악용할 수 있는지 이해하는 단계 사이의 격차를 줄일 수 있다.
OX Security CNAPP 플랫폼, 실행 중인 에이전트 활동까지 가시성 확장
OX Cloud는 클라우드 보안 플랫폼이 이미 수집하는 인프라, ID, 취약점, 데이터 신호에 에이전트 행동을 추가한다.
클라우드 네이티브 애플리케이션 보호 플랫폼(CNAPP)은 여러 클라우드 보안 기능을 하나의 시스템에 통합한다. 이러한 기능에는 일반적으로 구성 모니터링, 워크로드 보호, 권한 분석, 취약점 관리, 공격 경로 매핑이 포함된다.
OX Cloud는 클라우드 보안 태세 관리, Kubernetes 보안 태세 관리, 데이터 보안 태세 관리, 런타임 취약점 탐지, 클라우드 인벤토리, 그래프 기반 공격 경로 분석을 포함한다. 회사는 AIDR로 약칭하는 AI Detection and Response도 추가하고 있다.
차이는 OX가 플랫폼으로 관찰하려는 대상에 있다. 기존 보안 태세 도구는 스토리지 버킷, 컨테이너, ID, 네트워크 경로, 액세스 정책과 같은 리소스를 살펴본다. OX Cloud는 이 환경에서 작동하는 에이전트, 모델, 프롬프트, Model Context Protocol 서버도 식별하려 한다.
MCP는 AI 시스템이 외부 도구 및 데이터에 연결할 수 있게 하는 표준 인터페이스다. MCP 서버는 데이터베이스, 파일 시스템, 티켓 서비스, 코드 저장소 또는 내부 API를 에이전트에 노출할 수 있다.
이러한 연결은 에이전트의 활용도를 높이지만, 동시에 모델 출력을 실제 행동으로 전환한다. 조작된 에이전트는 제한된 기록을 조회하거나, 승인되지 않은 도구를 호출하거나, 의도된 워크플로 외부에서 유효한 자격 증명을 사용할 수 있다.
OX는 자사 플랫폼이 이러한 행동을 주변 클라우드 맥락과 연결한다고 말한다. 회사의 OX Cloud 발표에 따르면, 이 제품은 워크로드, ID, 데이터 저장소, Kubernetes 클러스터 및 활성 AI 에이전트의 인벤토리를 작성할 수 있다.
그런 다음 플랫폼은 도달 가능성 분석을 사용해 결과의 우선순위를 정한다. 도달 가능성은 노출된 구성 요소, 취약한 패키지 또는 과도한 권한이 실제로 가치 있는 리소스나 실행 경로에 연결될 수 있는지를 판단한다.
이 접근 방식이 중요한 이유는 클라우드 스캐너가 기술적으로 유효한 결과를 긴 목록으로 생성할 수 있기 때문이다. 격리된 워크로드 내부의 취약한 패키지는 고객 기록에 접근 가능한 인터넷 노출 서비스 내부의 동일한 패키지와 즉각적인 위험 수준이 다르다.
OX는 이 논리를 에이전트에 적용한다. 문제 소지가 있는 프롬프트나 비정상적인 도구 호출은 해당 에이전트가 프로덕션 데이터, 관리 API 또는 배포 시스템에 도달할 수 있을 때 더 중요해진다.
회사는 또한 OX Cloud가 런타임 활동을 이를 시작한 프롬프트 또는 코드와 연계할 수 있다고 말한다. 이 연결은 조사자가 에이전트가 행동을 취한 사실만 기록하는 것이 아니라 그 이유를 재구성하는 데 도움이 될 수 있다.
이는 여전히 벤더의 주장이다. OX는 기능과 제품 아키텍처를 설명했지만, 이번 출시와 관련한 비교 탐지율, 오탐 측정치, 배포 오버헤드 또는 독립 평가 결과는 공개하지 않았다.
이러한 증거 공백이 제품의 의미를 없애는 것은 아니다. 다만 기업 구매자가 새 플랫폼을 통합 제어 평면으로 간주하기 전에 검증해야 할 사항을 규정한다.
AI 에이전트가 기존 클라우드 보안을 압박하는 이유
에이전트는 추론하고, 도구를 선택하며, 변경을 시작할 수 있는 하나의 빠르게 움직이는 ID에 여러 익숙한 보안 문제를 압축한다.
기존 워크로드는 일반적으로 엔지니어가 배포 전에 검토할 수 있는 코드를 따른다. 권한이 여전히 과도할 수 있고 종속성에 취약점이 포함될 수도 있다. 그러나 예상되는 실행 경로는 비교적 안정적이다.
에이전트는 다르게 행동한다. 런타임에 지시를 해석하고, 맥락을 검색하며, 도구를 선택하고, 일련의 행동을 구성한다. 프롬프트, 검색된 문서, 모델 버전 또는 도구 설명의 작은 변화도 이 순서를 바꿀 수 있다.
이러한 가변성이 에이전트의 행동을 알 수 없게 만든다는 뜻은 아니다. 방어자에게는 의사결정 경로와 그에 따른 시스템 호출 양쪽에 관한 텔레메트리가 필요하다는 의미다.
ID는 이 문제의 핵심 요소다. 공유 서비스 계정을 통해 작동하는 에이전트는 로그 해석을 어렵게 만들 수 있다. 조사자는 어떤 에이전트가 이를 시작했는지, 왜 행동했는지, 누가 워크플로를 승인했는지 알지 못한 채 데이터베이스 쿼리나 파일 변경만 볼 수 있다.
Microsoft의 최소 권한 가이드라인은 모든 에이전트를 별도의 주체로 취급할 것을 권고한다. 각 에이전트에는 관리형 ID, 명시적인 소유자, 제한적으로 범위가 설정된 역할, 승인된 도구 매니페스트가 있어야 한다.
이 모델은 측정 가능한 경계를 만든다. 팀은 에이전트가 호출해야 하는 도구, 접근할 수 있는 리소스, 그리고 런타임 활동이 할당된 목적 범위 안에 머무르는지를 판단할 수 있다.
MCP 서버가 광범위한 자격 증명을 상속받을 때 문제는 더 심각해진다. MCP는 OAuth를 포함한 인증 메커니즘을 지원하지만, 프로토콜이 모든 배포 환경에 대해 안전한 정책을 자동으로 강제하지는 않는다.
Microsoft는 Defender for Cloud 신호를 통해 관찰한 원격 MCP 서버 중 15%가 민감한 데이터 또는 운영 기능에 대한 인증되지 않은 접근을 허용했다고 보고했다. 해당 MCP 노출 조사 결과에는 티켓 시스템, 비공개 저장소, 인사 도구에 대한 연결이 포함됐다.
이 수치는 모든 MCP 배포를 설명하지는 않는다. 다만 인증 및 실행 경계가 잘못 구성될 경우 에이전트 연결성이 실제 기업 시스템을 노출할 수 있음을 보여준다.
보안 태세 스캔은 노출된 서버를 식별할 수 있다. ID 제품은 해당 자격 증명을 찾아낼 수 있다. 런타임 도구는 의심스러운 호출을 기록할 수 있다. OX는 분석가가 체인을 수동으로 조립하기 전에 공유 그래프가 이 세 요소를 연결할 수 있다는 데 베팅하고 있다.
이것이 CNAPP 데이터와 AI 에이전트 런타임 방어를 결합해야 한다는 가장 강력한 논거다. 위협은 전적으로 애플리케이션 문제도, 전적으로 클라우드 문제도 아니다.
지원 요청을 처리하도록 할당된 에이전트를 생각해 보자. 이 에이전트는 티켓을 읽고, 내부 문서를 검색하며, 고객 기록을 업데이트할 수 있다. 티켓 안에 숨겨진 간접 프롬프트는 에이전트에게 관련 없는 기록을 가져오거나 외부 엔드포인트로 데이터를 전송하도록 지시할 수 있다.
프롬프트 필터는 해당 지시를 표시할 수 있다. 하지만 심각도는 에이전트가 사용하는 ID, 호출할 수 있는 도구, 그리고 그 도구가 접근할 수 있는 기록에 달려 있다.
반대로 비정상적인 API 호출이 항상 공격을 뜻하는 것은 아니다. 에이전트가 이례적인 요청을 받은 후 정당한 작업을 완료하고 있을 수 있다. 방어자는 예상치 못한 행동과 승인되지 않은 행동을 구분할 수 있을 만큼 충분한 맥락이 필요하다.
OX Cloud는 이러한 구분을 중심으로 설계됐다. 그 약속은 단순히 이상한 프롬프트를 탐지하는 데 있지 않다. 실행 중인 행동을 도달 가능한 자산, 실효 권한, 그리고 이를 시작한 소프트웨어 경로와 연결하는 데 있다.
OX Cloud, 도달 가능성을 핵심 차별화 요소로 전환
이 플랫폼의 핵심 메커니즘은 런타임 행동과 공격 경로를 통해 어떤 결과가 주의를 받을 가치가 있는지 결정하는 증거 연계형 우선순위 지정이다.
클라우드 보안팀은 이미 경보량 문제에 시달리고 있다. 보안 태세 스캐너는 잘못된 구성을 탐지하고, 취약점 도구는 패키지를 열거하며, ID 시스템은 과도한 권한을 식별하고, 데이터 도구는 민감한 저장소를 분류한다.
에이전트를 추가하면 이러한 단편화를 해결하지 못한 채 또 하나의 인벤토리가 만들어질 수 있다. 보안팀은 에이전트가 존재하고 특정 모델을 사용하며 여러 도구에 연결된다는 사실을 알 수 있다. 그러나 이 사실만으로는 그 행동이 악용 가능한 경로를 만드는지 보여주지 못한다.
OX는 식별, 우선순위 지정, 조사, 거버넌스의 4단계 워크플로를 설명한다. 이 단계들은 분리된 제품 모듈처럼 작동하는 대신 동일한 맥락 데이터를 사용한다.
식별은 워크로드, ID, 에이전트, 데이터 저장소 및 클라우드 자산을 다룬다. OX는 여기에는 구성 파일에 선언된 리소스뿐 아니라 관찰된 활동을 통해 발견된 리소스도 포함된다고 말한다.
우선순위 지정은 취약점, 권한, 잘못된 구성 및 공급망 노출에 도달 가능성을 적용한다. 활성 워크로드 또는 가치 있는 자산과 연결될 수 없는 결과는 긴급성이 낮게 부여된다.
조사는 클라우드 그래프를 사용해 이벤트를 둘러싼 관계를 재구성한다. 분석가는 어떤 ID가 행동했고, 어떤 리소스를 건드렸으며, 어떤 추가 시스템에 도달할 수 있었는지 확인할 수 있어야 한다.
거버넌스는 에이전트 활동 및 AI 사용에 제한을 적용한다. 이 지점에서 OX의 AIDR 및 에이전트형 공격 표면 기능은 단순한 탐색 기능을 넘어선다.
이 메커니즘은 일관성 있게 들리지만, 그 품질은 데이터 충실도에 달려 있다. OX는 자산을 안정적으로 발견하고, 권한을 해석하며, 에이전트 호출을 추적하고, 조사에 충분한 맥락을 보존해야 한다.
적용 범위의 공백은 잘못된 확신을 만들 수 있다. 관찰되지 않은 도구 호출, 관리되지 않는 자격 증명, 암호화된 트래픽 경로 또는 지원되지 않는 에이전트 프레임워크는 프롬프트와 결과를 연결하는 사슬을 끊을 수 있다.
데이터 상관관계 역시 모호한 결론을 낳을 수 있다. API 호출 직전에 프롬프트가 나타났다고 해서 그 프롬프트가 호출을 유발했다는 것이 자동으로 증명되는 것은 아니다. 장기 실행 워크플로, 병렬 에이전트, 재시도 및 위임된 하위 작업은 귀속을 복잡하게 만든다.
따라서 OX는 인터페이스 안에서 상관관계와 인과관계를 구분해야 한다. 분석가에게는 제안된 관계를 뒷받침하는 타임스탬프, 호출 체인, ID 기록, 정책 결정 및 애플리케이션 추적 정보가 필요하다.
배포 아키텍처도 중요하다. 런타임 검사는 네트워크 가로채기, 워크로드 센서, 애플리케이션 라이브러리, API 게이트웨이, 클라우드 로그 또는 에이전트 프레임워크와의 통합을 통해 이뤄질 수 있다.
각 방식은 서로 다른 가시성을 제공한다. 네트워크 제어 기능은 대상과 페이로드를 관찰할 수 있지만 내부 추론을 놓칠 수 있다. 프레임워크 계측은 도구 선택을 포착할 수 있지만 사용자 지정 애플리케이션 전반에서 불완전한 적용 범위를 제공할 수 있다.
OX는 더 광범위한 AINAPP 플랫폼이 프롬프트, 코드, 빌드, 배포 및 런타임 단계를 연결한다고 말한다. AINAPP는 AI-native application protection platform을 가리키는 회사의 용어다.
이 개념은 OX에 잠재적으로 유용한 입지를 제공한다. OX의 애플리케이션 보안 제품은 이미 소스 코드와 소프트웨어 공급망을 점검한다. OX Cloud는 이 범위를 배포된 인프라와 실시간 에이전트 활동으로 확장한다.
그러나 구매자는 아직 OX 제품을 통해 관리되지 않는 코드와 에이전트에서 이 연결이 어떻게 작동하는지 물어야 한다. 가장 풍부한 컨텍스트가 엄격히 통제된 도구 체인 내부에서만 나타난다면 통합 플랫폼의 가치는 제한적이다.
실질적인 검증은 실제 사고 상황이다. 보안 팀은 의심스러운 도구 설명을 주입하고, 무단 액세스 시도를 유발한 뒤, OX가 전체 경로를 재구성하는지 점검해야 한다.
이 과정에서는 시작 콘텐츠, 에이전트 ID, 선택된 도구, 매개변수, 대상 위치, 실효 권한, 영향을 받은 데이터, 집행 결과가 표시되어야 한다. 이보다 부족하다면 분석가는 여러 시스템에 걸쳐 증거를 짜맞춰야 한다.
OX Security, 기존 CNAPP 및 AI 보안 플랫폼과 경쟁
OX는 AI를 완전히 무시한 정적 클라우드 스캐너가 아니라, 더 큰 벤더가 주도하는 플랫폼 통합과 경쟁하고 있다.
시장은 이미 라이프사이클 전반을 아우르는 보안으로 이동했다. 주요 벤더들은 이제 AI 탐지, 보안 태세 분석, 레드팀 테스트, 런타임 검사, ID 제어, 정책 집행을 결합하고 있다.
Palo Alto Networks는 AI 애플리케이션, 모델, 데이터, 에이전트를 포괄하는 플랫폼으로 Prisma AIRS를 제시한다. Prisma AIRS documentation은 런타임 방화벽, API, 레드팀 테스트, 모델 보안, 태세 관리, 에이전트 보호를 설명한다.
Palo Alto는 또한 AI 탐지를 Cortex Cloud와 통합한다. 이 연결은 Amazon Web Services, Microsoft Azure, Google Cloud 전반에서 모델, 엔드포인트, 데이터세트, 에이전트, 종속성 관계를 식별할 수 있다.
이로 인해 핵심 경쟁 구도는 OX와 기존 CNAPP의 대결보다 더 넓어진다. 기존 제품 포트폴리오 전반에서 유사한 제어 기능을 조합하는 기존 보안 플랫폼에 맞선 OX의 컨텍스트 우선 통합 전략이다.
기존 업체는 설치 기반, 클라우드 텔레메트리, 위협 인텔리전스, ID 통합, 확립된 조달 관계를 보유한다. 구매자는 또 다른 보안 플랫폼을 도입하기보다 기존 계약을 확장하는 쪽을 선호할 수 있다.
OX는 집중도를 강점으로 내세울 수 있다. 규모가 작은 벤더는 오래된 제품군의 모든 아키텍처 가정을 유지하지 않고도 에이전트 워크플로를 중심으로 설계할 수 있다.
코드에서 런타임까지 이어지는 OX의 서사는 애플리케이션 보안 팀에도 매력적으로 다가갈 수 있다. 이들 팀은 개발 중 도입된 취약점이 배포 이후에도 도달 가능한지, 그리고 에이전트가 취약한 경로를 활성화할 수 있는지를 알고자 한다.
이 연결은 개발자와 보안 분석가 간의 이견을 줄일 수 있다. 개발자는 영향을 받는 코드가 실제로 노출되었다는 증거 없이 스캐너 결과를 받는 경우가 많다. 런타임 컨텍스트는 어떤 문제가 즉각적인 운영상 관련성을 갖는지 보여줄 수 있다.
다만 대형 벤더 역시 동일한 통합 논리를 제시하고 있다. Palo Alto는 Prisma AIRS가 정식 출시 후 1년 만에 약 1억2,000만 달러의 연간 반복 매출을 기록했다고 밝혔다.
회사는 또한 2026 회계연도 4분기 발표에서 Prisma AIRS 고객이 800곳을 넘었다고 보고했다. 이 수치는 Palo Alto 자체의 매출 배분 및 수주 견적 정의를 사용하지만, 의미 있는 상업적 수요를 시사한다.
이 경쟁 압력은 OX가 구체적인 이점을 입증하도록 요구한다. 클라우드 플랫폼은 이미 같은 범주의 다수를 포괄하므로, 더 긴 기능 목록만으로는 충분하지 않다.
OX는 더 빠른 조사, 더 명확한 우선순위 지정, 폭넓은 프레임워크 지원 또는 더 명료한 프롬프트-런타임 귀속을 통해 차별화할 수 있다. 배포 유연성과 낮은 운영 복잡성으로도 경쟁할 수 있다.
고객은 범주 명칭보다 워크플로를 비교해야 한다. 두 제품 모두 에이전트 탐지, 런타임 방어, 태세 관리를 표방할 수 있지만, 서로 다른 텔레메트리를 수집하거나 서로 다른 지점에서 정책을 집행할 수 있다.
한 플랫폼은 모델 처리 전에 악성 프롬프트를 차단할 수 있다. 다른 플랫폼은 도구 호출을 가로채거나, ID 권한을 제한하거나, 의심스러운 활동을 감지한 뒤 워크로드를 격리할 수 있다.
이러한 제어 기능은 상호 보완적이지만, 배치 위치는 지연 시간, 적용 범위, 장애 모드에 영향을 미친다. 실행 경로 밖에 배치된 제품은 즉각적인 차단 권한이 부족한 대신 더 안전하게 관찰할 수 있다.
인라인 제어는 작업을 멈출 수 있지만, 동시에 애플리케이션의 가용성 경로 일부가 된다. 구매자는 보안 서비스가 느려지거나 연결이 끊기거나 요청을 분류하지 못할 때 어떤 일이 발생하는지 이해해야 한다.
OX는 이러한 비교를 결론낼 만큼 출시 관련 증거를 공개적으로 충분히 제공하지 않았다. 당면 과제는 신뢰할 만한 아키텍처를 반복 가능한 고객 성과로 전환하는 일이다.
런타임 방어는 에이전트 설계와 액세스 제어를 대체할 수 없다
어떤 CNAPP도 ID를 공유하거나 과도한 권한을 받거나 독립적인 승인 없이 영향력이 큰 작업을 실행하는 에이전트를 보완할 수는 없다.
런타임 모니터링은 정적 검토가 놓치는 행동을 탐지할 수 있기 때문에 흔히 주목받는다. 그러나 이러한 강점은 팀이 관찰을 더 안전한 아키텍처의 대체재로 여기게 만들 수도 있다.
모니터링 제품이 에이전트의 작업을 기록한다는 이유만으로 광범위한 액세스 권한을 부여해서는 안 된다. 무단 데이터 전송을 기록한다고 해서 이미 발생한 전송이 되돌려지는 것은 아니다.
OWASP의 agentic risk taxonomy에는 도구 오용, ID 및 권한 남용, 메모리 오염, 연쇄 장애, 악성 에이전트 행동이 포함된다. 이러한 위험은 모델, 애플리케이션, ID, 인프라의 경계를 가로지른다.
방어자는 구분된 에이전트 ID부터 시작해야 한다. 공유 자격 증명은 소유권을 불분명하게 하고 권한 철회를 어렵게 만든다. 각 프로덕션 에이전트에는 명시된 소유자, 문서화된 목적, 제한된 허용 리소스 집합이 필요하다.
도구 액세스도 명시적이어야 한다. 지원 티켓을 요약하도록 설계된 에이전트가 티켓 관리 플랫폼에 대한 관리 권한을 상속받아서는 안 된다. 해당 작업에 필요한 읽기 작업만 부여받아야 한다.
쓰기 권한은 별도의 결정이 필요하다. 워크플로가 레코드 수정으로 확장된다면 팀은 검토 없이 기존 역할을 넓히는 대신 새 권한과 승인 규칙을 만들어야 한다.
영향력이 큰 작업에는 결정론적 집행이 필요하다. 데이터 삭제, 프로덕션 인프라 변경, 지급 실행, 외부 콘텐츠 게시를 자연어 지시에 대한 모델의 해석에만 의존해서는 안 된다.
재무적·운영상·법적 영향이 큰 작업에는 사람의 승인이 여전히 적절하다. 정책 조건이 좁고 독립적으로 집행될 경우 영향이 더 작은 작업에는 자동 승인이 작동할 수 있다.
메모리는 또 다른 위험을 야기한다. 에이전트는 세션 전반에 걸쳐 대화 기록, 선호도, 검색된 사실 또는 중간 계획을 저장할 수 있다. 악성 콘텐츠가 이 메모리에 지속되어 이후의 결정에 영향을 줄 수 있다.
런타임 제품은 가능한 경우 메모리 읽기와 쓰기를 드러내야 한다. 또한 에이전트가 도구 선택이나 매개변수 구성 시 검색된 콘텐츠를 사용했는지도 보여줘야 한다.
그러나 메모리 액세스는 제한된 텔레메트리만 제공하는 프레임워크 또는 모델 서비스 내부에서 발생할 수 있다. 구매자는 OX Cloud가 실제 배포 스택 전반에서 이러한 상호작용을 포착하는지 검증해야 한다.
오탐은 별도의 과제다. 에이전트 워크플로는 사용자 요청에 적응하기 때문에 자연스럽게 이례적인 작업 순서를 만들어 낸다. 단순한 이상 탐지는 정상적인 변화를 경고로 표시해 분석가를 압도할 수 있다.
OX는 도달 가능성 분석이 이러한 잡음을 줄이는 데 도움이 된다고 말한다. 이 주장은 그럴듯하지만, 도달 가능성이 악의적 의도를 증명하지는 않는다. 도달 가능한 경로는 정당한 워크플로를 지원할 수 있으며, 도달 불가능한 소프트웨어 결함도 구성 변경 이후에는 관련성을 가질 수 있다.
기업은 통제된 배포 환경에서 정밀도를 측정해야 한다. 유용한 지표에는 확인된 사고, 오탐, 조사 시간, 차단된 정상 작업, 지원되지 않는 워크플로, 텔레메트리 공백이 포함된다.
성능 영향도 측정해야 한다. 런타임 검사는 프롬프트, 도구 호출, 데이터 흐름 또는 ID 정책을 동기적으로 평가할 때 지연 시간을 추가할 수 있다.
OX는 OX Cloud의 일반적인 지연 시간 또는 오버헤드 수치를 공개하지 않았다. 결과는 배포 방식, 트래픽 규모, 정책 복잡성, 수집되는 컨텍스트의 양에 따라 달라질 가능성이 크다.
또 다른 불확실성은 집행의 일관성이다. 조직은 여러 클라우드와 SaaS 플랫폼 전반에서 여러 프레임워크로 구축된 에이전트를 운영할 수 있다. 정책은 이러한 아키텍처 차이를 견뎌야 한다.
모든 에이전트를 발견하지만 일부만 관리하는 대시보드는 불균일한 보호를 만든다. 보안 팀에는 명확한 호환성 매트릭스와 지원되지 않는 경로도 계속 가시성을 유지한다는 증거가 필요하다.
적절한 결론은 런타임 방어에 가치가 없다는 것이 아니다. 런타임 모니터링은 더 큰 제어 시스템 안에서 하나의 계층으로 작동할 때 가장 효과적이라는 것이다.
안전한 에이전트 설계는 제한된 권한에서 시작한다. 이후 런타임 방어는 행동이 이러한 한계 안에 머무르는지 검증하고 조사자가 일탈을 이해하도록 돕는다.
OX Cloud의 성과를 보여줄 세 가지 신호
다음 검증은 고객 검증, 측정 가능한 잡음 감소, 실제 에이전트 스택 전반의 폭넓은 집행을 포함한 운영 증거다.
첫 번째 신호는 독립적인 고객 증거다. OX는 여러 클라우드, 에이전트 프레임워크, ID 공급자, MCP 서버를 포함한 프로덕션 환경에서 플랫폼이 어떻게 작동하는지 보여줘야 한다.
유용한 사례 연구는 발견된 에이전트와 비인간 ID의 수를 정량화해야 한다. 또한 확인된 위험 경로, 억제된 경고 수, 조사 시간의 변화도 보고해야 한다.
두 번째 신호는 비교 성능이다. 구매자에게는 프롬프트 인젝션, 오염된 도구 설명, 과도한 권한, 비정상적인 API 순서, 시도된 데이터 유출을 포괄하는 탐지 및 집행 테스트가 필요하다.
이러한 테스트에는 오탐을 측정하기 위한 정상적인 변형도 포함되어야 한다. 모든 드문 작업을 차단하는 시스템은 적응형 워크플로에 거의 가치를 제공하지 못한다.
OX는 집행이 어디에서 이루어지는지도 공개해야 한다. 고객은 제어 기능이 워크로드 내부, 네트워크 검사 경유, 에이전트 프레임워크 내부 또는 클라우드 API를 통해 작동하는지 알아야 한다.
세 번째 신호는 경쟁사의 대응이다. Palo Alto Networks, Microsoft 및 기타 보안 벤더는 에이전트 ID, 태세, 런타임 검사, 거버넌스를 더 큰 플랫폼에 통합하고 있다.
이들 벤더가 코드, 프롬프트, ID, 클라우드 리소스, 도구 호출을 유사한 정밀도로 연결한다면 OX의 아키텍처상 차별성은 좁아질 것이다. 그러면 OX는 배포 품질, 조사 속도, 적용 범위, 고객 서비스로 경쟁하게 된다.
기존 업체가 이 제어 기능을 계속 분절된 상태로 둔다면, OX는 하나의 컨텍스트 그래프가 더 빠르고 방어 가능한 의사결정을 만든다고 주장할 수 있다. 고객 평가는 어느 결과가 프로덕션 현실을 반영하는지 결정할 것이다.
OX Security CNAPP 플랫폼을 평가하는 보안 책임자는 제한된 하나의 에이전트 워크플로부터 시작해야 한다. 더 광범위한 적용 범위를 활성화하기 전에 해당 워크플로의 ID, 승인된 도구, 도달 가능한 데이터, 예상 작업, 에스컬레이션 규칙을 매핑할 수 있다.
그런 다음 평가는 통제된 실패 상황을 도입해야 한다. 노출된 MCP 서버, 과도한 권한을 가진 ID, 오염된 문서, 무단 도구 호출, 취약하지만 도달 가능한 워크로드를 테스트해야 한다.
플랫폼은 단지 이례적인 일이 발생했다는 사실뿐 아니라 그것이 왜 중요한지도 보여줘야 한다. 시작 지시문을 행동한 ID, 선택된 도구, 도달 가능한 자산, 정책 결정, 최종 결과와 연결해야 한다.
이 기준은 OX를 넘어 적용된다. 에이전트 보안 제품은 복잡한 텔레메트리를 신뢰할 수 있는 집행과 설명 가능한 조사로 전환해야 한다.
이번 출시 는 클라우드 보안의 실제 변화를 반영한다. 에이전트는 이제 단순히 목록화해야 할 자산 범주가 아니라, 클라우드에서 능동적으로 활동하는 참여자가 되고 있다.
OX Cloud는 런타임 동작을 코드, 워크로드, ID, 데이터와 동일한 그래프 안에 배치함으로써 이에 대응한다. 설계는 신뢰할 만하지만, 가장 강력한 주장은 여전히 독립적인 검증이 필요하다.
OX Cloud를 검토하는 팀은 다듬어진 기능 시연이 아니라 실제 프로덕션 환경에 가까운 파일럿을 요구해야 한다. 플랫폼은 모든 에이전트를 식별하고, 정상적인 변형과 오용을 구분하며, 완전한 작업 체인을 재구성할 수 있는가? 정상 업무를 지연시키거나 또 하나의 알림 큐를 만들지 않으면서 제한을 적용할 수 있는가? 이러한 결과가 OX Security CNAPP 플랫폼이 의미 있는 제어 평면이 될지, 아니면 보안 팀이 다시 조정해야 하는 또 하나의 계층이 될지를 결정할 것이다.
