Plataforma CNAPP da OX Security reúne postura de nuvem e defesa em tempo de execução para agentes de IA

A OX Security lançou, em 16 de setembro, uma plataforma CNAPP que combina controles de nuvem já consolidados com monitoramento em tempo real para agentes de IA. A plataforma CNAPP da OX Security, chamada OX Cloud, mira uma lacuna de segurança criada quando softwares autônomos passam a ter identidades, permissões e acesso a ferramentas corporativas.

O lançamento não é apenas mais uma expansão de uma lista de recursos de segurança em nuvem. A OX argumenta que as equipes de segurança precisam de um único grafo que conecte código, configuração de nuvem, identidades, dados, prompts e ações de agentes em produção. Essa alegação desafia tanto os produtos CNAPP convencionais quanto as ferramentas separadas de segurança para IA.

Palo Alto Networks e outros grandes fornecedores de segurança já oferecem proteção em tempo de execução, gestão de postura de IA e controles para agentes. Portanto, a OX precisa provar que seu contexto do prompt ao tempo de execução cria decisões melhores, e não apenas um painel mais abrangente.

A questão central é se a combinação desses sinais ajuda os defensores a isolar riscos alcançáveis e comportamentos inseguros de agentes. Se ajudar, o OX Cloud poderá reduzir a distância entre descobrir uma fraqueza na nuvem e entender como um sistema autônomo poderia explorá-la.

A plataforma CNAPP da OX Security amplia a visibilidade sobre a atividade de agentes em produção

OX Cloud adiciona o comportamento dos agentes aos sinais de infraestrutura, identidade, vulnerabilidade e dados que as plataformas de segurança em nuvem já coletam.

Uma plataforma de proteção de aplicações nativas da nuvem, ou CNAPP, combina diversas funções de segurança em nuvem em um único sistema. Essas funções costumam incluir monitoramento de configurações, proteção de cargas de trabalho, análise de permissões, gestão de vulnerabilidades e mapeamento de caminhos de ataque.

OX Cloud inclui gestão de postura de segurança em nuvem, gestão de postura do Kubernetes, gestão de postura de segurança de dados, detecção de vulnerabilidades em tempo de execução, inventário de nuvem e análise de caminhos de ataque baseada em grafos. A empresa também está adicionando AI Detection and Response, abreviado como AIDR.

A diferença está no que a OX quer que a plataforma observe. Ferramentas convencionais de postura examinam recursos como buckets de armazenamento, contêineres, identidades, caminhos de rede e políticas de acesso. O OX Cloud também busca identificar agentes, modelos, prompts e servidores Model Context Protocol que operam nesse ambiente.

MCP é uma interface padrão que permite que sistemas de IA se conectem a ferramentas e dados externos. Um servidor MCP pode expor a um agente um banco de dados, sistema de arquivos, serviço de tickets, repositório de código ou API interna.

Essa conexão dá mais utilidade a um agente, mas também transforma a saída do modelo em ações. Um agente manipulado pode recuperar registros restritos, invocar uma ferramenta não aprovada ou usar uma credencial válida fora do fluxo de trabalho pretendido.

A OX afirma que sua plataforma conecta essas ações ao contexto de nuvem ao redor. Segundo o anúncio do OX Cloud da empresa, o produto pode inventariar cargas de trabalho, identidades, repositórios de dados, clusters Kubernetes e agentes de IA ativos.

A plataforma então usa análise de alcançabilidade para priorizar descobertas. A alcançabilidade determina se um componente exposto, pacote vulnerável ou permissão excessiva pode realmente se conectar a um recurso valioso ou caminho de execução.

Essa abordagem importa porque scanners de nuvem podem produzir longas listas de descobertas tecnicamente válidas. Um pacote vulnerável dentro de uma carga de trabalho isolada não apresenta o mesmo risco imediato que esse pacote em um serviço exposto à internet com acesso a registros de clientes.

A OX aplica essa lógica aos agentes. Um prompt questionável ou chamada de ferramenta incomum se torna mais importante quando o agente responsável consegue alcançar dados de produção, APIs administrativas ou sistemas de implantação.

A empresa também afirma que o OX Cloud pode associar a atividade em tempo de execução ao prompt ou código que a iniciou. Essa conexão pode ajudar investigadores a reconstruir por que um agente realizou uma ação, em vez de apenas registrar que a ação ocorreu.

Essas continuam sendo alegações do fornecedor. A OX descreveu recursos e arquitetura do produto, mas não publicou taxas comparativas de detecção, medições de falsos positivos, sobrecarga de implantação ou avaliações independentes para este lançamento.

Essa lacuna de evidências não torna o produto irrelevante. Ela define o que compradores corporativos precisam validar antes de tratar a nova plataforma como um plano de controle consolidado.

Por que os agentes de IA pressionam a segurança tradicional em nuvem

Os agentes concentram vários problemas de segurança conhecidos em uma única identidade dinâmica, capaz de raciocinar, escolher ferramentas e iniciar mudanças.

Uma carga de trabalho tradicional normalmente segue um código que engenheiros podem revisar antes da implantação. Suas permissões ainda podem ser excessivas, e suas dependências ainda podem conter vulnerabilidades. No entanto, o caminho de execução esperado é relativamente estável.

Um agente se comporta de outra forma. Ele interpreta instruções, recupera contexto, seleciona ferramentas e constrói uma sequência de ações em tempo de execução. Pequenas alterações em prompts, documentos recuperados, versões de modelos ou descrições de ferramentas podem modificar essa sequência.

Essa variabilidade não significa que o comportamento dos agentes seja impossível de conhecer. Significa que os defensores precisam de telemetria tanto sobre o caminho de decisão quanto sobre as chamadas de sistema resultantes.

A identidade é parte central desse problema. Um agente que atua por meio de uma conta de serviço compartilhada pode tornar os logs difíceis de interpretar. Investigadores podem ver uma consulta ao banco de dados ou alteração de arquivo sem saber qual agente a iniciou, por que ele agiu ou quem autorizou o fluxo de trabalho.

As orientações de menor privilégio da Microsoft recomendam tratar cada agente como um principal distinto. Cada agente deve ter uma identidade gerenciada, um proprietário explícito, funções de escopo restrito e um manifesto de ferramentas aprovado.

Esse modelo cria uma fronteira mensurável. As equipes podem determinar quais ferramentas um agente deve chamar, quais recursos ele pode acessar e se sua atividade em tempo de execução permanece dentro de sua finalidade atribuída.

O problema se torna mais grave quando servidores MCP herdam credenciais amplas. O MCP oferece suporte a mecanismos de autorização, incluindo OAuth, mas o protocolo não impõe automaticamente uma política segura para todas as implantações.

A Microsoft relatou que 15 por cento dos servidores MCP remotos observados por meio de sinais do Defender for Cloud permitiam acesso não autenticado a dados confidenciais ou capacidades operacionais. Suas descobertas sobre exposição de MCP incluíram conexões a sistemas de tickets, repositórios privados e ferramentas de recursos humanos.

Esse número não descreve todas as implantações de MCP. Ele demonstra, porém, que a conectividade dos agentes pode expor sistemas empresariais reais quando os limites de autenticação e execução são configurados incorretamente.

Uma varredura de postura pode identificar o servidor exposto. Um produto de identidade pode encontrar sua credencial. Uma ferramenta de execução pode registrar uma chamada suspeita. A OX aposta que um grafo compartilhado pode conectar os três antes que um analista monte manualmente a cadeia.

Esse é o argumento mais forte para combinar dados de CNAPP com defesa em tempo de execução para agentes de IA. A ameaça não é inteiramente um problema de aplicação nem inteiramente um problema de nuvem.

Considere um agente encarregado de resolver solicitações de suporte. Ele pode ler tickets, pesquisar documentação interna e atualizar registros de clientes. Um prompt indireto oculto dentro de um ticket poderia instruir o agente a recuperar registros não relacionados ou enviar dados a um endpoint externo.

Um filtro de prompts pode sinalizar a instrução. Contudo, a gravidade depende de qual identidade o agente usa, quais ferramentas ele pode invocar e quais registros essas ferramentas podem acessar.

Por outro lado, uma chamada de API incomum nem sempre indica um ataque. O agente pode estar concluindo uma tarefa legítima após encontrar uma solicitação pouco comum. Os defensores precisam de contexto suficiente para distinguir comportamento inesperado de comportamento não autorizado.

O OX Cloud foi projetado em torno dessa distinção. Sua promessa não é simplesmente detectar prompts estranhos. É conectar o comportamento em produção a ativos alcançáveis, permissões efetivas e ao caminho de software que o originou.

O OX Cloud torna a alcançabilidade seu principal diferencial

O mecanismo central da plataforma é a priorização vinculada a evidências, na qual o comportamento em tempo de execução e os caminhos de ataque determinam quais descobertas merecem atenção.

As equipes de segurança em nuvem já enfrentam dificuldades com o volume de alertas. Scanners de postura detectam configurações incorretas, ferramentas de vulnerabilidade enumeram pacotes, sistemas de identidade identificam permissões excessivas e ferramentas de dados classificam repositórios sensíveis.

Adicionar agentes pode criar mais um inventário sem resolver essa fragmentação. Uma equipe de segurança pode descobrir que um agente existe, usa determinado modelo e se conecta a diversas ferramentas. Esses fatos ainda não mostram se seu comportamento cria um caminho explorável.

A OX descreve um fluxo de trabalho de quatro etapas: identificar, priorizar, investigar e governar. As etapas usam os mesmos dados contextuais, em vez de operar como módulos desconectados de produto.

A identificação abrange cargas de trabalho, identidades, agentes, repositórios de dados e ativos de nuvem. A OX afirma que isso inclui recursos descobertos a partir de atividade observada, e não apenas recursos declarados em arquivos de configuração.

A priorização aplica alcançabilidade a vulnerabilidades, permissões, configurações incorretas e exposição na cadeia de suprimentos. Descobertas que não podem se conectar a uma carga de trabalho ativa ou ativo valioso recebem menos urgência.

A investigação usa um grafo de nuvem para reconstruir as relações em torno de um evento. Um analista deve conseguir ver qual identidade atuou, qual recurso ela acessou e quais sistemas adicionais eram alcançáveis.

A governança aplica restrições à atividade dos agentes e ao uso de IA. É aqui que as funções de AIDR e superfície de ataque agêntica da OX se tornam mais do que recursos de descoberta.

O mecanismo parece coerente, mas sua qualidade depende da fidelidade dos dados. A OX precisa descobrir ativos de forma confiável, interpretar permissões, rastrear chamadas de agentes e preservar contexto suficiente para a investigação.

Lacunas de cobertura podem criar falsa confiança. Uma chamada de ferramenta não observada, credencial não gerenciada, caminho de tráfego criptografado ou framework de agentes não compatível pode romper a cadeia que conecta prompt e resultado.

A correlação de dados também pode produzir conclusões ambíguas. Um prompt que aparece pouco antes de uma chamada de API não prova automaticamente que causou a chamada. Fluxos de trabalho de longa duração, agentes paralelos, novas tentativas e subtarefas delegadas complicam a atribuição.

Portanto, a OX precisa distinguir correlação de causalidade em sua interface. Os analistas precisam de registros de horário, cadeias de invocação, registros de identidade, decisões de política e rastros de aplicação que sustentem a relação proposta.

A arquitetura de implantação também importa. A inspeção em tempo de execução pode ocorrer por interceptação de rede, sensores de carga de trabalho, bibliotecas de aplicação, gateways de API, logs de nuvem ou integrações com frameworks de agentes.

Cada método oferece uma visibilidade diferente. Controles de rede podem observar destinos e cargas úteis, mas deixar de captar o raciocínio interno. A instrumentação de frameworks pode registrar a seleção de ferramentas, mas fornecer cobertura incompleta em aplicações personalizadas.

A OX afirma que a plataforma AINAPP mais ampla conecta as etapas de prompt, código, compilação, implantação e tempo de execução. AINAPP é o termo da empresa para uma plataforma de proteção de aplicações nativas de IA.

O conceito dá à OX uma posição potencialmente útil. Seus produtos de segurança de aplicações já analisam código-fonte e cadeias de suprimentos de software. O OX Cloud estende essa proposta para a infraestrutura implantada e a atividade de agentes em tempo real.

No entanto, os compradores devem perguntar como essa conexão funciona para códigos e agentes que ainda não são gerenciados por produtos da OX. Uma plataforma unificada tem valor limitado se o contexto mais rico só aparece dentro de uma cadeia de ferramentas rigidamente controlada.

O teste prático é um incidente real. Uma equipe de segurança deve inserir uma descrição suspeita de ferramenta, acionar uma tentativa de acesso não autorizado e verificar se a OX reconstrói todo o percurso.

Esse exercício deve mostrar o conteúdo iniciador, a identidade do agente, a ferramenta selecionada, os parâmetros, o destino, a permissão efetiva, os dados afetados e o resultado da aplicação da política. Qualquer coisa menos que isso deixa os analistas montando evidências entre sistemas.

OX Security Enfrenta Plataformas CNAPP e de Segurança de IA Consolidadas

A OX está competindo contra a consolidação de plataformas liderada por fornecedores maiores, e não contra scanners estáticos de nuvem que ignoraram totalmente a IA.

O mercado já avançou em direção à cobertura de todo o ciclo de vida. Grandes fornecedores agora combinam descoberta de IA, análise de postura, red teaming, inspeção em tempo de execução, controles de identidade e aplicação de políticas.

A Palo Alto Networks apresenta o Prisma AIRS como uma plataforma que abrange aplicações, modelos, dados e agentes de IA. A documentação do Prisma AIRS descreve firewalls de runtime, APIs, red teaming, segurança de modelos, gestão de postura e proteção de agentes.

A Palo Alto também integra a descoberta de IA ao Cortex Cloud. Essa conexão pode identificar modelos, endpoints, conjuntos de dados, agentes e relações de dependência na Amazon Web Services, Microsoft Azure e Google Cloud.

Isso torna a principal disputa mais ampla do que OX contra uma CNAPP convencional. Trata-se da integração centrada em contexto da OX contra plataformas de segurança estabelecidas que reúnem controles semelhantes em seus portfólios de produtos existentes.

Os fornecedores consolidados trazem bases instaladas, telemetria de nuvem, inteligência de ameaças, integrações de identidade e relações de aquisição já estabelecidas. Os compradores podem preferir ampliar um contrato existente em vez de introduzir outra plataforma de segurança.

A OX pode responder com foco. Um fornecedor menor pode projetar seus produtos em torno de fluxos de trabalho de agentes sem precisar preservar todas as premissas arquiteturais de uma suíte mais antiga.

Sua narrativa de código ao runtime também pode atrair equipes de segurança de aplicações. Essas equipes querem saber se uma descoberta introduzida durante o desenvolvimento continua acessível após a implantação e se um agente pode ativar o caminho vulnerável.

Essa conexão pode reduzir divergências entre desenvolvedores e analistas de segurança. Desenvolvedores frequentemente recebem achados de scanners sem evidências de que o código afetado esteja exposto. O contexto de runtime pode estabelecer quais problemas têm relevância operacional imediata.

Ainda assim, fornecedores maiores defendem o mesmo argumento de consolidação. A Palo Alto reportou aproximadamente US$ 120 milhões em receita recorrente anual para o Prisma AIRS após um ano de disponibilidade geral.

A empresa também informou ter mais de 800 clientes do Prisma AIRS em sua apresentação do quarto trimestre fiscal de 2026. Esses números usam as próprias definições da Palo Alto para alocação de receita e cotações contratadas, mas indicam uma demanda comercial significativa.

Essa pressão competitiva obriga a OX a demonstrar vantagens específicas. Uma lista mais longa de recursos não será suficiente, pois as plataformas de nuvem já abrangem muitas das mesmas categorias.

A OX pode se diferenciar por meio de investigações mais rápidas, priorização mais clara, suporte mais amplo a frameworks ou atribuição mais transparente entre prompts e runtime. Ela também pode competir por flexibilidade de implantação e menor complexidade operacional.

Os clientes devem comparar fluxos de trabalho, não rótulos de categorias. Ambos os produtos podem alegar descoberta de agentes, defesa em runtime e gestão de postura, enquanto coletam telemetria diferente ou aplicam políticas em pontos distintos.

Uma plataforma pode bloquear prompts maliciosos antes do processamento pelo modelo. Outra pode interceptar chamadas de ferramentas, restringir permissões de identidade ou isolar a carga de trabalho após detectar atividade suspeita.

Esses controles são complementares, mas seu posicionamento afeta a latência, a cobertura e os modos de falha. Um produto posicionado fora do caminho de execução pode observar com mais segurança, mas sem autoridade imediata para bloquear.

Um controle inline pode interromper uma ação, mas também passa a fazer parte do caminho de disponibilidade da aplicação. Os compradores precisam entender o que acontece quando o serviço de segurança fica lento, perde conectividade ou não consegue classificar uma solicitação.

A OX ainda não forneceu evidências públicas específicas do lançamento suficientes para resolver essas comparações. Seu desafio imediato é converter uma arquitetura crível em resultados repetíveis para os clientes.

A Defesa em Runtime Não Pode Substituir o Design de Agentes e o Controle de Acesso

Nenhuma CNAPP pode compensar agentes que compartilham identidades, recebem permissões excessivas ou executam ações de alto impacto sem autorização independente.

O monitoramento em runtime frequentemente recebe atenção porque pode detectar comportamentos que análises estáticas deixam passar. Essa força também pode incentivar equipes a tratar a observação como substituta de uma arquitetura mais segura.

Um agente não deve obter acesso amplo apenas porque um produto de monitoramento registra suas ações. Registrar uma transferência não autorizada de dados não desfaz a transferência.

A taxonomia de riscos agênticos da OWASP inclui uso indevido de ferramentas, abuso de identidade e privilégios, envenenamento de memória, falhas em cascata e comportamento de agentes rebeldes. Esses riscos atravessam os limites entre modelo, aplicação, identidade e infraestrutura.

Os defensores devem começar com identidades distintas para agentes. Credenciais compartilhadas obscurecem a responsabilidade e dificultam a revogação. Cada agente de produção precisa de um responsável identificado, uma finalidade documentada e um conjunto limitado de recursos permitidos.

O acesso a ferramentas também deve ser explícito. Um agente criado para resumir tickets de suporte não deve herdar acesso administrativo à plataforma de tickets. Ele deve receber apenas as operações de leitura necessárias para essa tarefa.

O acesso de escrita merece uma decisão separada. Se o fluxo de trabalho for ampliado para modificar registros, a equipe deve criar novas permissões e regras de aprovação, em vez de ampliar uma função existente sem revisão.

Ações de alto impacto exigem aplicação determinística. Excluir dados, alterar infraestrutura de produção, emitir pagamentos ou publicar conteúdo externo não devem depender apenas da interpretação de um modelo sobre instruções em linguagem natural.

A aprovação humana continua apropriada para ações com grandes consequências financeiras, operacionais ou legais. A aprovação automatizada pode funcionar para tarefas de menor impacto quando as condições de política são restritas e aplicadas de forma independente.

A memória introduz outro risco. Um agente pode armazenar histórico de conversas, preferências, fatos recuperados ou planos intermediários entre sessões. Conteúdo malicioso pode persistir nessa memória e influenciar decisões posteriores.

Um produto de runtime deve expor leituras e gravações de memória quando possível. Também deve mostrar se um agente usou conteúdo recuperado ao selecionar uma ferramenta ou construir parâmetros.

No entanto, o acesso à memória pode ocorrer dentro de um framework ou serviço de modelo que fornece telemetria limitada. Os compradores devem testar se o OX Cloud captura essas interações em sua pilha real de implantação.

Falsos positivos representam um desafio separado. Fluxos de trabalho de agentes naturalmente produzem sequências incomuns de ações porque se adaptam às solicitações dos usuários. Uma detecção simples de anomalias pode sinalizar variações legítimas e sobrecarregar os analistas.

A OX afirma que a alcançabilidade ajuda a reduzir esse ruído. A alegação é plausível, mas a alcançabilidade não comprova intenção maliciosa. Um caminho acessível pode sustentar um fluxo de trabalho legítimo, enquanto uma falha de software inacessível pode se tornar relevante após uma mudança de configuração.

As empresas devem medir a precisão durante uma implantação controlada. Métricas úteis incluem incidentes confirmados, falsos positivos, tempo de investigação, tarefas legítimas bloqueadas, fluxos de trabalho sem suporte e lacunas de telemetria.

Elas também devem medir o impacto no desempenho. A inspeção em runtime pode adicionar latência quando avalia prompts, chamadas de ferramentas, fluxos de dados ou políticas de identidade de forma síncrona.

A OX não publicou números gerais de latência ou sobrecarga para o OX Cloud. Os resultados provavelmente dependerão do método de implantação, do volume de tráfego, da complexidade das políticas e da quantidade de contexto coletado.

Outra incerteza é a consistência da aplicação. Uma organização pode operar agentes criados com diversos frameworks em várias nuvens e plataformas SaaS. Uma política precisa sobreviver a essas diferenças arquiteturais.

Um painel que descobre todos os agentes, mas governa apenas um subconjunto, cria proteção desigual. As equipes de segurança precisam de uma matriz clara de compatibilidade e de evidências de que caminhos sem suporte continuem visíveis.

A conclusão apropriada não é que a defesa em runtime não tenha valor. É que o monitoramento em runtime funciona melhor como uma camada dentro de um sistema de controles mais amplo.

O design seguro de agentes começa com autoridade limitada. A defesa em runtime então verifica se o comportamento permanece dentro desses limites e ajuda os investigadores a entender os desvios.

Três Sinais Mostrarão se o OX Cloud Cumpre o que Promete

O próximo teste é a evidência operacional, incluindo validação de clientes, redução mensurável de ruído e aplicação ampla em pilhas reais de agentes.

O primeiro sinal é a evidência independente de clientes. A OX deve mostrar como a plataforma se comporta em ambientes de produção que contêm várias nuvens, frameworks de agentes, provedores de identidade e servidores MCP.

Estudos de caso úteis quantificariam quantos agentes e identidades não humanas foram descobertos. Eles também deveriam informar quais caminhos arriscados foram confirmados, quantos alertas foram suprimidos e como o tempo de investigação mudou.

O segundo sinal é o desempenho comparativo. Os compradores precisam de testes de detecção e aplicação que cubram injeção de prompt, descrições de ferramentas envenenadas, permissões excessivas, sequências incomuns de APIs e tentativas de exfiltração de dados.

Esses testes devem incluir variações benignas para medir falsos positivos. Um sistema que bloqueia toda ação incomum oferece pouco valor para fluxos de trabalho adaptativos.

A OX também deve divulgar onde ocorre a aplicação. Os clientes precisam saber se os controles operam dentro das cargas de trabalho, por inspeção de rede, dentro de frameworks de agentes ou por meio de APIs de nuvem.

O terceiro sinal é a resposta competitiva. Palo Alto Networks, Microsoft e outros fornecedores de segurança estão integrando identidade de agentes, postura, inspeção em runtime e governança em plataformas maiores.

Se esses fornecedores conectarem código, prompts, identidades, recursos de nuvem e chamadas de ferramentas com precisão semelhante, a distinção arquitetural da OX diminuirá. A OX então competirá pela qualidade da implantação, velocidade de investigação, cobertura e atendimento ao cliente.

Se os fornecedores consolidados mantiverem esses controles fragmentados, a OX poderá argumentar que um único grafo contextual produz decisões mais rápidas e defensáveis. As avaliações dos clientes determinarão qual resultado reflete a realidade de produção.

Líderes de segurança que avaliam a plataforma CNAPP da OX Security devem começar com um fluxo de trabalho de agente restrito. Eles podem mapear sua identidade, ferramentas aprovadas, dados acessíveis, ações esperadas e regras de escalonamento antes de habilitar uma cobertura mais ampla.

A avaliação deve então introduzir falhas controladas. Teste um servidor MCP exposto, uma identidade com privilégios excessivos, um documento envenenado, uma chamada de ferramenta não autorizada e uma carga de trabalho vulnerável e acessível.

A plataforma não deve mostrar apenas que algo incomum ocorreu, mas por que isso importava. Ela deve conectar a instrução de origem à identidade atuante, à ferramenta selecionada, ao ativo acessível, à decisão de política e ao resultado final.

Esse padrão se aplica além da OX. Produtos de segurança para agentes precisam transformar telemetria complexa em aplicação confiável e investigações explicáveis.

O lançamento reflete uma mudança real na segurança em nuvem. Os agentes estão se tornando participantes ativos da nuvem, em vez de apenas mais uma classe de ativos a ser inventariada.

O OX Cloud responde a isso ao colocar o comportamento em tempo de execução dentro do mesmo grafo que código, cargas de trabalho, identidades e dados. O projeto é crível, mas as afirmações mais contundentes ainda exigem validação independente.

As equipes que consideram o OX Cloud devem solicitar um teste com características de produção, não uma demonstração polida de recursos. A plataforma consegue identificar todos os agentes, distinguir variações legítimas de uso indevido e reconstruir uma cadeia completa de ações? Ela consegue impor limites sem atrasar o trabalho normal ou criar outra fila de alertas? Esses resultados determinarão se a plataforma CNAPP da OX Security se tornará um plano de controle relevante ou apenas outra camada que as equipes de segurança precisarão conciliar.