Resumo

  • A Prosimo foi fundada em 2019 e levantou pelo menos 55 milhões de dólares em suas rodadas Série A de 2021 e Série B de 2022; não publicou receita auditada, avaliação nem preço de aquisição
  • O AXI combinava intenção, topologia e análise centrais com nós distribuídos que descobriam ativos de nuvem, conectavam aplicações e inseriam serviços de segurança sem possuir a infraestrutura física
  • A integração com o VM-Series, anunciada em junho de 2024, precedeu a incorporação da Prosimo à Palo Alto Networks por volta de fevereiro de 2025; a data exata, o preço e o mapa atual de produtos não foram divulgados
  • O controle permanece distribuído entre as empresas, o software de orquestração, os provedores de nuvem e a Palo Alto Networks; a portabilidade da topologia, das credenciais, das políticas e da autoridade sobre as rotas é o teste decisivo para os clientes

A marca desapareceu, mas o problema permaneceu

Em 2026, não é mais correto descrever a Prosimo como um fornecedor independente ativo. Os históricos profissionais públicos mostram seus fundadores e vários funcionários se juntando à Palo Alto Networks por volta de fevereiro de 2025. A identidade corporativa da Prosimo aparece marcada como adquirida, e o antigo diretor de tecnologia Nehal Bhau escreveu posteriormente que a tecnologia havia sido integrada aos produtos da Palo Alto Networks. As evidências estabelecem uma mudança de controle e a continuidade do valor técnico. Não estabelecem a data exata de assinatura ou fechamento, a forma jurídica nem o preço da operação.

Esta precisão deve aparecer no início porque altera o tempo verbal de todas as afirmações sobre os produtos. AXI, Network Transit, App Transit, Application-driven Intelligent Results e Nebula foram capacidades documentadas durante a fase independente. Não devem ser apresentados como produtos atuais vendidos separadamente até que a Palo Alto Networks publique uma correspondência contemporânea de produto e suporte. Após uma aquisição, uma arquitetura pode sobreviver como código integrado, serviço compartilhado, módulo ou ativo interno de engenharia; esses resultados não são equivalentes.

O desaparecimento da marca não eliminou o problema subjacente. As empresas continuam distribuindo cargas entre Amazon Web Services, Microsoft Azure, Google Cloud, data centers privados, instalações de colocation, plataformas SaaS e usuários remotos. Cada ambiente tem suas próprias rotas, gateways, endpoints privados, controles de identidade, serviços de segurança, cotas e regras de cobrança. Uma empresa pode ser proprietária de todas as contas e ainda assim carecer de uma visão coerente do percurso de uma solicitação. A importância da Prosimo reside na sua tentativa de reunir essa visão em uma camada de controle comum.

Por isso, a aquisição constitui o eixo narrativo e não um simples epílogo. A Prosimo construiu uma camada de controle transversal capaz de descobrir ativos, interpretar o contexto das aplicações e direcionar tráfego para serviços de segurança. A Palo Alto Networks apareceu primeiro como parceira técnica cujos firewalls VM-Series podiam ser inseridos nessas rotas; depois se tornou proprietária da tecnologia. O limite que separava a orquestração do roteamento da inspeção profunda ficou dentro de uma única plataforma de cibersegurança.

No roteamento multinuvem, o contexto decide

Uma tabela de rotas pode indicar se um prefixo é alcançável através de um próximo salto. Sozinha, não explica qual aplicação o usuário queria alcançar, se o usuário ou a carga são confiáveis, se um serviço de inspeção deve ver o tráfego, se existe um endpoint privado, se uma rota na nuvem custa mais que outra ou se a transação falha após o pacote chegar. As operações multinuvem transformam essas perguntas em um problema de controle compartilhado.

A tese da Prosimo era que a autoridade de roteamento deveria se basear em algo mais do que a conectividade de camada 3. Seu software tentava combinar inventário de nuvem, estado da rede, identidade da aplicação, identidade do usuário, risco, desempenho e telemetria transacional. Esse contexto permitia expressar políticas como conectar uma aplicação específica, separar um segmento, escolher um ponto de entrada ou direcionar tráfego selecionado para um firewall. O valor não vinha de inventar uma nova rota de fibra, mas de decidir como montar rotas e serviços existentes.

Essa diferença explica a expressão «application experience infrastructure». A solicitação da aplicação ficava acima do objeto de rede individual. Um VPC, VNet, sub-rede, hub de trânsito ou link privado passava a ser um componente do percurso de ponta a ponta, não o objeto final de gestão. A proposta também colocava o produto em vários mercados ao mesmo tempo: redes na nuvem, entrega de aplicações, acesso zero trust, verificação operacional da rede, otimização de custos e inserção de serviços de segurança.

Essa amplitude gerava oportunidades e ambiguidade. Um produto que atravessa várias equipes pode resolver falhas de coordenação que não pertencem a um único responsável. Também pode ser difícil de avaliar porque as equipes de rede, segurança, nuvem, aplicações e finanças usam definições distintas de sucesso. A Prosimo tinha que demonstrar que um modelo transversal melhorava a operação sem se tornar outra camada privilegiada cujos erros afetassem todos os ambientes.

O que era a Prosimo e o que restou de sua tecnologia

A Prosimo foi uma empresa privada de software de redes em nuvem fundada em 2019 na área da baía de São Francisco. Ramesh Prabagaran foi cofundador e CEO; Nehal Bhau foi cofundador e CTO durante a fase independente. Os históricos públicos também colocam Linus Aranha e Pradeep Aragonda em funções de fundação ou engenharia sênior, embora seus cargos exatos devam ser vinculados a biografias datadas.

Sua plataforma principal era a Application eXperience Infrastructure, normalmente abreviada como AXI. O AXI utilizava uma camada central de software para intenção, topologia, análise e orquestração, juntamente com nós AXI Edge distribuídos em regiões de nuvem, ambientes de colocation ou infraestrutura local próxima. Mais tarde, a oferta foi organizada como Full-Stack Cloud Transit, com Network Transit e App Transit para diferentes classes de conectividade. O AIR analisava telemetria e produzia informações operacionais; o Nebula adicionou uma interface conversacional em 2024.

A Prosimo não era uma operadora de nuvem. Não possuía uma rede mundial de fibra conectando todas as regiões. As rotas podiam atravessar backbones dos provedores, internet pública, circuitos diretos, links de colocation e redes empresariais. Também não era um fornecedor de firewall no mesmo sentido que a Palo Alto Networks. Na integração de 2024, a Prosimo descobria, segmentava e direcionava; o VM-Series realizava a inspeção profunda.

Após a aquisição, a descrição mais prudente é «linhagem tecnológica». A declaração posterior de integração destaca a descoberta de ativos multinuvem e a implantação mais rápida de firewalls de software para tráfego de entrada, saída e leste-oeste. É uma evidência de que componentes importantes sobreviveram. Não prova que o catálogo histórico completo do AXI, seu empacotamento comercial ou seu modelo de suporte continuaram sem alterações.

O problema após o SD-WAN

A equipe fundadora tinha experiência em redes em larga escala, entrega de aplicações e infraestrutura de nuvem. A Prosimo também surgiu do ecossistema mais amplo de fundadores e engenheiros associado à Viptela, empresa que ajudou a consolidar o SD-WAN como categoria empresarial. O problema seguinte era distinto. O SD-WAN podia simplificar a relação entre uma filial e a rede, mas não criava um modelo operacional único dentro e através de várias nuvens públicas.

Uma aplicação multinuvem pode depender de um endpoint web em um ambiente, um banco de dados ou serviço gerenciado em outro, um provedor de identidade fora de ambos, conectividade privada para um data center e inspeção de segurança localizada em pontos específicos. Cada dependência pode ser representada por um objeto nativo diferente. A equipe de rede vê prefixos e hubs de trânsito; a equipe de nuvem vê contas e recursos; o proprietário da aplicação vê domínios e transações; a segurança vê zonas e políticas de inspeção.

A Prosimo partia da solicitação, não da filial. A pergunta era como um usuário ou uma carga deveria alcançar uma aplicação com segurança, desempenho, disponibilidade e custo aceitáveis. Esse enfoque ampliava o objeto do roteamento do prefixo de destino para uma transação com identidade e contexto de aplicação. Também obrigava a coletar e manter muito mais informações do que um roteador convencional.

O momento era favorável. AWS, Azure e Google Cloud estavam expandindo seus sistemas nativos de trânsito e conectividade privada. As empresas podiam construir redes sofisticadas dentro de cada provedor, mas as APIs, os objetos e os modelos de política continuavam sendo específicos. A oportunidade da Prosimo consistia em coordenar esses serviços, não em obrigar cada cliente a substituí-los por uma rede backbone proprietária.

Da fundação em 2019 ao lançamento público de 2021

A Prosimo foi fundada em 2019, mas não anunciou seu lançamento público até 6 de abril de 2021. A General Catalyst liderou uma Série A de 25 milhões de dólares no lançamento. O investidor descreveu a oportunidade em termos de entrega de experiência de aplicação entre nuvens, alinhada com a intenção de definir uma categoria mais ampla do que a conectividade tradicional de filiais.

O lançamento colocou a empresa em um mercado concorrido e ainda instável. Os provedores de nuvem facilitavam o consumo de seus serviços de rede. Os vendedores de SD-WAN e SASE estendiam a política para a nuvem. Os fornecedores de entrega de aplicações podiam otimizar solicitações e as empresas de segurança podiam inspecioná-las. O caso da Prosimo dependia de unir essas funções em uma arquitetura orientada à nuvem sem afirmar que substituía tudo ao seu redor.

O financiamento permitiu construir integrações, nós de borda de software, análises, uma organização comercial e relações com parceiros. Não provava encaixe de produto, escala de receita ou diferenciação duradoura. As evidências fornecidas não contêm receita auditada, ARR, número de clientes ou avaliação. O registro de financiamento mostra apoio do investidor a uma tese, não um relatório completo de desempenho operacional.

Em 2022, a Prosimo concluiu uma Série B de 30 milhões de dólares, descrita como sobrescrita. Somando as duas rodadas claramente identificadas, obtém-se um total verificado de pelo menos 55 milhões. Algumas bases de dados podem mostrar mais se duplicarem anúncios ou registros relacionados; não devem ser usadas sem resolver os eventos subjacentes.

O AXI colocava as políticas acima das nuvens e a execução perto das cargas de trabalho

A arquitetura AXI dividia o trabalho entre uma camada central de controle e análise e nós de borda distribuídos. A camada central mantinha a intenção de rede e aplicação, descobria ativos, montava a topologia, integrava identidade, analisava telemetria e orquestrava mudanças. Os nós AXI Edge eram implantados perto das cargas de trabalho ou dos usuários para aplicar política sem forçar todas as rotas a passarem por um hub físico distante.

A separação se assemelha a outros sistemas definidos por software, mas os objetos eram específicos da nuvem e conscientes da aplicação. O controlador precisava de acesso a contas e APIs, enquanto o nó de borda precisava de conectividade com trânsito nativo, redes de trabalho, endpoints privados ou rotas externas. A autoridade nascia da combinação de ambas as visões: intenção global acima das nuvens e execução local perto do tráfego.

A arquitetura também criava um limite operacional. Cada nó de borda consumia recursos de nuvem, precisava de alta disponibilidade e devia ser atualizado, monitorado e protegido. A camada central exigia credenciais com privilégio suficiente para descobrir ativos e alterar o estado da rede. A empresa ganhava um fluxo comum, mas adicionava um sistema de gestão cuja disponibilidade e correção afetavam a conectividade de produção.

A Prosimo às vezes usava a linguagem de rede autônoma na nuvem. As evidências apoiam automação, recomendações e orquestração por API. Não descrevem uma rede que opere sem política humana, serviços de nuvem ou transporte subjacente. Os operadores continuavam definindo intenção, aprovando acesso, resolvendo exceções e respondendo pelo resultado.

O AXI Edge era uma decisão de localização, não um dispositivo genérico

Um AXI Edge podia ser implantado em um VPC ou VNet, em uma instalação de colocation ou em infraestrutura adjacente. O percurso técnico da AWS mostrava um VPC de borda conectado a VPCs de carga via Transit Gateway, com encadeamento opcional de firewall e acesso de sedes ou usuários remotos. O ponto de execução ficava dentro da topologia de nuvem, não em um perímetro corporativo distante.

A localização determinava mais do que a latência. Definia onde o tráfego entrava no domínio de política, qual backbone de nuvem ou rota de internet utilizava, onde era criptografado ou inspecionado e qual telemetria estava disponível. Um nó de borda mal localizado podia gerar desvios ou custos; um bem localizado podia encurtar a rota ou manter o tráfego perto da carga.

A distribuição aumentava os domínios de falha. A capacidade, as versões, o design de zonas, a convergência de rotas e as permissões podiam variar entre regiões. A alta disponibilidade exigia mais do que duas instâncias: o controlador, as tabelas de rotas de nuvem, os serviços de segurança e as rotas de retorno tinham que coincidir no estado de comutação.

Portanto, o nó de borda fazia parte de um sistema operacional mais amplo. Seu valor dependia de que descoberta, topologia, política e análise permanecessem coerentes com o ambiente. Tratá-lo como um dispositivo virtual autônomo perderia a arquitetura que a Prosimo tentava vender.

A infraestrutura subjacente permaneceu em mãos de terceiros

A Prosimo coordenava o transporte, mas não era dona da rota física. Uma conexão podia utilizar o backbone da AWS ou de outro provedor, internet pública, Direct Connect ou ExpressRoute, um serviço de colocation, um circuito de operadora ou uma rede empresarial. A plataforma podia selecionar e orquestrar opções disponíveis; não podia eliminar a latência, a perda de pacotes, os domínios de falha ou as regras de preços criadas por esses provedores.

Esse limite importa ao avaliar promessas de desempenho. Um controlador pode escolher uma rota observada melhor ou aproximar o ingresso do usuário. Não pode garantir que uma operadora não falhe, que uma região de nuvem permaneça disponível ou que uma dependência externa responda rapidamente. A experiência de aplicação também inclui DNS, processamento do servidor, armazenamento, navegador e serviços externos fora da autoridade total do controlador.

Não dispor de uma rede backbone própria não era apenas uma desvantagem. Permitia utilizar infraestrutura que as empresas já haviam comprado e beneficiar-se do investimento dos provedores de nuvem. A Prosimo podia alcançar regiões sem construir fibra e coordenar sistemas nativos como o AWS Cloud WAN. Em troca, dependia da estabilidade das APIs, das cotas, das condições comerciais e da semântica de cada provedor.

A proposta tratava de controle operacional, não de propriedade física. A plataforma tentava fazer com que infraestruturas heterogêneas funcionassem como um único sistema gerenciado, conservando suas vantagens nativas. Se essa abstração reduzia o aprisionamento ou simplesmente o transferia, dependia da portabilidade das políticas, da topologia e dos nós de borda.

O Network Transit geria a conectividade entre objetos de rede

O Network Transit focava em VPC, VNet, sub-redes, regiões, sedes e segmentos. Coordenava serviços nativos de trânsito e objetos de rota para que as equipes construíssem conectividade através de um fluxo comum, em vez de configurar cada provedor separadamente. Respondia à necessidade clássica: uma fonte ou um segmento deve alcançar um destino por uma rota permitida.

Não pretendia que as diferenças entre nuvens tivessem desaparecido. AWS, Azure e Google Cloud expõem objetos, cotas e comportamentos distintos. As sobreposições de endereços, as rotas assimétricas, os endpoints privados e os limites de serviço ainda precisavam de engenharia. A Prosimo podia normalizar operações comuns e mostrar relações, mas os sistemas subjacentes mantinham suas restrições.

O Network Transit também fornecia segmentação. Os domínios de rota e as políticas podiam separar ambientes ou limitar conectividade. O controlador precisava entender onde existia um segmento entre nuvens e como ele se materializava com objetos nativos. Uma política expressa uma única vez podia gerar várias mudanças específicas do provedor.

A vantagem era uma superfície unificada de intenção. O risco era a tradução. Se a política comum e a configuração real divergissem, a empresa podia acreditar que um segmento estava protegido quando o estado do provedor indicava o contrário. A reconciliação, a auditoria e os erros explícitos eram tão importantes quanto o provisionamento inicial.

O App Transit convertia a aplicação em objeto de roteamento

O App Transit ampliava o modelo além das sub-redes. Podia utilizar o domínio da aplicação, identidade, tipo de solicitação, estado da transação, risco e desempenho para decidir como um usuário ou uma carga de trabalho alcançava um serviço. Era a tentativa mais clara de se diferenciar de um roteador de nuvem convencional.

A visão de aplicação era útil porque os serviços modernos nem sempre têm endereços fixos. As plataformas gerenciadas, endpoints SaaS e componentes distribuídos podem mudar enquanto a identidade do serviço continua sendo significativa. Uma política que se refere à aplicação ou ao usuário pode durar mais do que outra baseada apenas em endereços e portas.

O modelo exigia descoberta correta. O controlador devia saber quais domínios e endpoints pertenciam a uma aplicação, quais dependências eram necessárias e quais afirmações de identidade eram confiáveis. Um mapa desatualizado podia direcionar uma solicitação pela rota errada ou aplicar uma política incorreta. A abstração de aplicação não eliminava a necessidade de conhecer o estado da rede; adicionava uma camada semântica.

A combinação de Network Transit e App Transit reconhecia que as empresas contêm ambos os mundos. Sistemas legados, sub-redes privadas e controles IP persistem, enquanto novas aplicações dependem de domínios, identidade e serviços gerenciados. Full-Stack Cloud Transit era o nome para operar ambos os modelos juntos sem forçar que um substituísse o outro.

A identidade ampliava a decisão de rota e o limite de confiança

O acesso consciente da aplicação precisava de integração de identidade. A plataforma podia usar o contexto de um usuário ou carga para decidir se devia estabelecer uma conexão e por qual caminho. Isso respaldava um enfoque zero trust no qual a localização não bastava como prova de autoridade.

A identidade melhorava a precisão, mas adicionava dependência. A política passava a confiar no provedor de identidade, seus atributos, a sessão e os grupos. Uma rota podia falhar porque a autenticação não estava disponível ou porque um atributo mudava, embora os roteadores e os nós de borda funcionassem. O diagnóstico precisava cruzar a fronteira entre redes e identidade.

O controlador se tornava, além disso, um ponto de concentração de contexto sensível. Podia reunir topologia, relações de aplicação, atributos de usuário, sinais de risco e resultados de política. Esse conjunto melhorava o diagnóstico e a otimização, ao mesmo tempo em que aumentava o impacto de um acesso não autorizado. Privilégio mínimo, retenção, auditoria e separação de funções eram requisitos arquitetônicos.

O enfoque da Prosimo mostra uma tendência ampla: o roteamento e o acesso dependem cada vez mais de identidade e semântica de aplicação. Quanto mais contexto uma plataforma vê, mais úteis podem ser suas decisões e mais rigorosa deve ser a governança de sua autoridade.

A descoberta de ativos criou o grafo do qual dependia cada decisão posterior

Um controlador transversal não pode governar o que não vê. A Prosimo desenvolveu funções de descoberta de ativos e mapas de VPC, VNet, sub-redes, aplicações, conectividade e relações de segurança. Essas visões apoiavam a incorporação de ambientes, o design, a resolução de problemas e a aplicação de políticas.

A descoberta era estratégica porque os ambientes mudam fora dos fluxos centrais de rede. As equipes de aplicações podem criar contas, redes, endpoints e serviços com sua própria automação. Um diagrama manual fica desatualizado. Um inventário por API pode ser mais recente, embora sua integridade dependa da cobertura de contas, das permissões, da lógica dos analisadores e das APIs.

O grafo não era apenas documentação. Era a estrutura a partir da qual se calculavam rotas, segmentação, inserção de serviços e otimização. Se faltasse um ativo ou uma dependência, as conclusões construídas sobre esse modelo podiam ser errôneas. A topologia precisava de rastreabilidade: data de coleta, conta de origem, regiões cobertas e qualquer falha de coleta.

O grafo ajuda a explicar a aquisição. A Palo Alto Networks obtém valor quando sabe onde estão as cargas e as rotas. Um sistema que descobre ativos e muda rotas encurta a distância entre comprar um firewall de software e colocá-lo corretamente. A declaração posterior de Bhau destacou precisamente a descoberta de ativos e a implantação acelerada de firewalls.

O AIR convertia a telemetria dos nós AXI Edge em recomendações

Application-driven Intelligent Results, ou AIR, analisava telemetria coletada pelos nós AXI Edge. O percurso da AWS descrevia visibilidade de tempo de ida e volta, processamento, resposta da aplicação, tipo de transação, risco e resultados de política. A plataforma podia correlacionar usuário, rede e aplicação em vez de mostrar contadores isolados.

Essa correlação abordava um problema comum. Uma transação lenta pode se originar no caminho do usuário, no nó de borda, no backbone de nuvem, em um serviço de segurança ou na aplicação. Uma visão transversal pode delimitar a busca mais rápido do que vários consoles. Também pode apoiar recomendações de rota, localização, risco ou custo.

A qualidade dependia da cobertura de telemetria e do modelo utilizado para interpretá-la. Um nó de borda só observava o tráfego que o atravessava, enquanto as dependências externas e certas condições internas do provedor podiam ficar de fora. Por isso, uma recomendação podia ser útil para orientar a investigação sem provar por si só a causa raiz.

A telemetria também tinha valor de governança. Os registros históricos podiam explicar por que uma política mudou, mas também podiam expor o uso de aplicações e o comportamento dos usuários. Os materiais públicos não oferecem uma explicação completa sobre retenção e governança de dados após a aquisição, portanto essas questões continuam fazendo parte da diligência devida do cliente.

AWS ofereceu a implementação pública mais bem documentada

O trabalho com a AWS produziu as evidências técnicas públicas mais sólidas. A Prosimo se integrou com Transit Gateway, Cloud WAN, PrivateLink e Marketplace for Containers Anywhere. A AWS publicou um percurso sobre localização do AXI Edge, incorporação de aplicações, identidade, segurança e otimização.

O AWS Cloud WAN era especialmente importante. Fornecia uma rede backbone nativa e segmentação que a Prosimo podia orquestrar sem substituir. O acordo mostrava o modelo cooperativo: a AWS possuía rede e infraestrutura mundial; a Prosimo fornecia intenção multinuvem, contexto de aplicação, nós de borda e análises.

O Marketplace simplificava a implantação inicial através de um canal aprovado, mas não eliminava o trabalho posterior sobre permissões, design de rotas, alta disponibilidade, capacidade e operação. A automação da fase inicial reduzia a fricção sem resolver o problema de controle de longo prazo.

Uma referência da Flexport apoiava o caso de uso em materiais corporativos. Mostrava que um cliente empresarial estava disposto a respaldar a arquitetura, mas não constituía uma auditoria independente sobre escala, economia ou disponibilidade. As referências de clientes devem ser tratadas como exemplos de adoção, não como prova universal de desempenho.

Azure e Google Cloud completavam a afirmação multinuvem

A Prosimo também oferecia suporte ao Microsoft Azure e ao Google Cloud. Seus materiais descreviam orquestração em torno do Azure Virtual WAN e objetos de rede e serviço privado do Google Cloud. O objetivo era um modelo único conservando as redes nativas.

A existência de suporte não prova paridade. As APIs evoluem em ritmos diferentes e nomes semelhantes escondem semânticas distintas. Uma rota, segmento, endpoint privado ou inserção pode exigir tratamento específico. As evidências não permitem reconstruir uma matriz completa por região e versão.

A abstração deve ser entendida como um sistema de tradução. Pode normalizar a intenção e o fluxo de trabalho, mas deve conservar os detalhes que afetam a segurança, o custo e os modos de falha. Uma interface uniforme se torna perigosa quando oculta diferenças relevantes de implementação.

O mesmo ocorre após a aquisição. A Palo Alto Networks pode usar o grafo comum para posicionar segurança, mas os provedores continuam controlando os objetos nativos. Ser dono da orquestração não significa ser dono da infraestrutura de nuvem.

O produto evoluiu da conectividade para um modelo de ciclo de vida

Em 2023, a Prosimo descrevia fluxos de trabalho para projetar, construir, diagnosticar e gerenciar redes multinuvem. A plataforma já não se apresentava como um simples túnel ou gateway: a descoberta apoiava o design, a orquestração criava conectividade, os mapas e a telemetria ajudavam no diagnóstico, e as políticas e o histórico respaldavam a gestão contínua.

Esse enquadramento ampliava o número de compradores potenciais. A equipe de rede podia utilizar a topologia e a análise; a equipe de nuvem, incorporar contas e serviços; a segurança, revisar a segmentação; a migração, planejar mudanças; e FinOps, estudar os custos de saída de dados e as rotas. O valor da plataforma aumentava quando vários grupos trabalhavam sobre a mesma evidência.

A evidência compartilhada também pode gerar conflitos de governança. Uma plataforma central pode revelar que a configuração nativa difere da política empresarial, mas a organização deve decidir qual sistema é autoritativo e quem pode aprovar a correção. O software pode expor a divergência; não pode resolver sozinho essa questão institucional.

O enfoque de ciclo de vida também aumentava os custos de mudança. Quando um controlador conserva o grafo, as políticas, a telemetria, os nós de borda e as integrações, substituí-lo exige reconstruir grande parte do modelo operacional. A Prosimo vendia uma redução da fragmentação entre nuvens, mas podia criar uma nova dependência em relação ao controlador.

A segmentação ia da conectividade de rede à política de aplicação

A Prosimo apresentava uma segmentação que abrangia da camada 3 à camada 7. Na rede, os domínios e segmentos controlavam a conectividade; nas camadas superiores, a identidade da aplicação, o usuário e as propriedades da transação podiam precisar a regra.

O modelo podia reduzir a distância entre zona de rede e política de aplicação. Um serviço podia ser permitido enquanto a conectividade geral entre sub-redes permanecia bloqueada. Inversamente, uma rota alcançável podia ser negada por identidade ou contexto.

A Prosimo não se tornava por isso um firewall completo. A integração separava responsabilidades: a Prosimo orquestrava rotas, segmentação e inserção de serviços, enquanto o VM-Series realizava a inspeção profunda. A distinção importa porque a direção do tráfego e a aplicação de controles podem falhar de maneiras diferentes.

Um segmento só é eficaz se todas as rotas relevantes forem representadas. Uma rota desconhecida, uma exceção nativa ou uma inserção falha pode contorná-lo. A verificação operacional requer comparar política declarada, estado do provedor e tráfego observado.

A inserção de serviços vinculava rotas e economia de firewall

O design de segurança na nuvem deve decidir onde a inspeção é realizada. Os firewalls centralizados podem simplificar as políticas e reduzir o número de instâncias, mas também criar tráfego de retorno, concentração e pressão de escala. Os firewalls distribuídos permanecem mais próximos das cargas de trabalho, embora multipliquem a implantação, as licenças, as atualizações e as operações.

A Prosimo permitia ambos os padrões com o VM-Series. A política podia direcionar tráfego a um ponto central ou a firewalls distribuídos em VPCs de aplicação. O controlador atualizava rotas e a Palo Alto fornecia inspeção.

Isso tornava a orquestração valiosa para um provedor de segurança. Um firewall não pode proteger tráfego que nunca o alcança; por isso, a descoberta, a colocação e a atualização de rotas reduzem a fricção entre comprar capacidade de segurança e inseri-la em uma rota de produção. Essa é uma razão estratégica plausível para a aquisição.

Também ampliava o raio de impacto dos erros. Uma política equivocada podia contornar a inspeção, criar loops, provocar rotas assimétricas ou deixar uma aplicação fora de serviço. Por isso, eram necessárias verificações prévias, implantações graduais, simulação, auditoria e mecanismos de reversão, já que a falha afetava ao mesmo tempo a rede e a segurança.

A parceria de 2024 não deve ser reinterpretada retroativamente como uma aquisição

A Prosimo e a Palo Alto Networks anunciaram a integração em 12 de junho de 2024. O comunicado descrevia uma solução conjunta e não afirmava que a Palo Alto Networks havia adquirido a Prosimo. Utilizá-lo como prova de propriedade confundiria dois acontecimentos distintos.

A parceria criou uma ponte. A Prosimo podia demonstrar que sua camada de controle facilitava a implantação do VM-Series, enquanto a Palo Alto Networks avaliava a tecnologia dentro de uma integração real antes da transição corporativa. As fontes não descrevem o processo de compra, portanto afirmar que a parceria foi uma fase formal prévia à aquisição seria especulativo.

No início de 2025, os históricos profissionais de fundadores e funcionários mudaram, e a página corporativa apareceu posteriormente marcada como adquirida. No final desse ano, Bhau afirmou que a tecnologia estava plenamente integrada aos produtos da Palo Alto Networks. Em conjunto, esses sinais respaldam a conclusão de que houve uma aquisição, embora deixem sem resolver seus mecanismos jurídicos.

A sequência importa para os clientes. Uma parceria implica dois fornecedores, duas estruturas de suporte e uma fronteira de integração definida; uma aquisição pode transferir roadmaps, dados, contratos e autoridade para uma única empresa. A mudança vai além da marca, embora o percurso técnico pareça inicialmente similar.

O Nebula tornou o grafo topológico acessível através de uma interface conversacional

A Prosimo apresentou o Nebula em fevereiro de 2024 dentro de uma AI Suite. O assistente devia responder perguntas em linguagem natural sobre sobreposições, custos, saúde das rotas, violações de segurança e outras condições representadas no grafo e na telemetria.

O ativo importante não era apenas a interface, mas o contexto estruturado. Um modelo geral não diagnostica uma rota privada que não vê. O Nebula se apoiava no inventário, topologia, política e observações já coletadas. O investimento prévio em um grafo comum se convertia em base para AIOps.

O acesso conversacional podia abrir dados complexos para mais operadores. Também podia criar falsa confiança se omitisse ativos, entendesse mal a consulta ou tratasse uma recomendação como ação autorizada. As mudanças de alto risco continuavam necessitando controles deterministas, permissões e revisão humana.

A Prosimo afirmou reduções potenciais de 60–80% do MTTR e mais de 60% do custo das redes na nuvem. Eram números do fornecedor em uma nota de produto. Não existe metodologia independente nem base de clientes que demonstre aplicação geral. Podem ser citados como benefícios propostos, não como fatos medidos.

As cargas de IA foram um novo caso de uso, não a prova de um novo mercado

A mesma nota apresentou a arquitetura para IA. Os sistemas distribuídos podem precisar de acesso privado a dados, links entre nuvens e centros, conformidade e rotas conscientes da aplicação. Esses requisitos se encaixavam no modelo existente de ativos, política e rotas.

O rótulo não mudava a infraestrutura subjacente. A Prosimo continuava dependendo de redes de nuvem, operadoras e infraestrutura do cliente. Também não fornecia GPU nem ferramentas de desenvolvimento de modelos. Sua possível função era a conectividade e segurança em torno de dados e serviços distribuídos.

A posição era estrategicamente lógica porque o valor da topologia aumenta com a distribuição. Também era uma categoria de marketing introduzida pouco antes do fim independente. As evidências não estabelecem receita de IA, implantações nomeadas ou resultados auditados.

A conclusão duradoura é que a telemetria multinuvem pode alimentar operações assistidas por sistemas automatizados. A pergunta atual é se a Palo Alto conservou esse contexto e como o expõe. As fontes não oferecem uma resposta completa.

O modelo de negócio vendia software para uma infraestrutura que a Prosimo não possuía

A Prosimo era uma proposta de software por assinatura e serviços, não uma operadora. Os clientes implantavam nós AXI Edge e conectavam contas à camada central. As receitas teriam dependido de licenças, suporte, serviços profissionais e canal, embora preços e métricas não tenham sido publicados nas evidências.

Podia escalar sem fibra própria. Uma plataforma podia coordenar muitas regiões. No entanto, a arquitetura não permite inferir margens. Manter APIs, nós de borda, integrações e implantação empresarial pode ser custoso; os recursos de nuvem consumidos por cada nó de borda podem ser pagos pelos clientes.

A Prosimo utilizou marketplaces, integradores, canais e referências de clientes para alcançar o mercado empresarial. Essas relações não são equivalentes: uma presença no marketplace demonstra um canal de compra e implantação; uma integração técnica demonstra compatibilidade sob determinadas condições; e um testemunho fornece uma referência comercial. Nenhum desses elementos revela por si só o número de clientes pagantes nem as receitas recorrentes.

A amplitude podia complicar a venda. As equipes de rede, segurança, nuvem e aplicações se beneficiavam, mas o orçamento podia não ter um dono. O produto precisava de um comprador disposto a financiar uma camada comum de controle.

Parceiros, clientes e investidores ocupavam posições diferentes

A AWS era ao mesmo tempo provedor de infraestrutura e parceiro de integração, enquanto Azure e Google Cloud figuravam como ambientes compatíveis. Os provedores de identidade forneciam contexto de autenticação; os firewalls, capacidade de inspeção; e os serviços de colocation e as operadoras podiam hospedar ou conectar nós de borda. Os parceiros de canal podiam projetar, implantar e gerenciar as soluções.

A Flexport aparecia como referência em material do AWS Cloud WAN. Demonstra interesse empresarial, mas não revela alcance, duração ou valor. Não deve ser convertida em substituto do número de clientes.

A General Catalyst liderou a Série A e participou como investidora. Os materiais também citavam a WRVI ou Celesta e, mais tarde, uma participação vinculada à BlackRock cujo veículo exato não foi esclarecido. Isso demonstra uma base de financiamento bem conectada, não uma tabela de capitalização completa.

A Palo Alto Networks foi a relação decisiva: de parceira em 2024 a compradora em 2025. A sequência mostra como uma dependência de ecossistema se converte em controle quando um participante compra a camada que coordena a rota até seu produto.

Foram verificados pelo menos 55 milhões; os termos econômicos da saída permanecem desconhecidos

O registro verificado inclui uma Série A de 25 milhões de dólares em abril de 2021 e uma Série B de 30 milhões em 2022. Não há uma tabela de capitalização auditada nem dados públicos sobre avaliação, dívida ou rodadas posteriores.

O preço de aquisição não foi divulgado nem verificado de forma independente. Sem esse número, não é possível classificar responsavelmente a operação como uma compra com prêmio estratégico, uma aquisição tecnológica modesta, um acqui-hire ou uma venda sob pressão. A continuidade da integração demonstra valor tecnológico, mas não revela o retorno obtido por investidores ou fundadores.

Não se deve atribuir à Prosimo a escala financeira da Palo Alto Networks. Ao deixar de ser observável, não existe um segmento autônomo de receita, lucro ou clientes. Um proprietário maior pode ampliar o alcance e tornar menos visíveis os números individuais.

A ausência de um anúncio formal de aquisição também é relevante. Esse tipo de documento costuma esclarecer o cronograma, o suporte e a lógica estratégica; neste caso, o status deve ser reconstruído a partir de históricos profissionais, da etiqueta da página corporativa e de uma declaração posterior do cofundador. Essa evidência basta para corrigir a condição corporativa, mas não para inventar termos da transação.

A concorrência vinha de plataformas, nuvens e engenharia interna

A Prosimo competia com plataformas especializadas como Aviatrix e Alkira, com provedores de redes empresariais e SASE, com os serviços nativos da AWS, Azure e Google Cloud, e com enfoques internos baseados em infraestrutura como código, serviços de trânsito, tabelas de rotas e firewalls. Cada alternativa resolvia uma parte diferente do mesmo problema.

Um controlador especializado podia oferecer uma topologia e políticas comuns entre provedores. Uma solução nativa reduzia a dependência externa dentro de uma única nuvem; uma operadora fornecia transporte físico; uma plataforma de segurança combinava conectividade e inspeção; e o desenvolvimento interno preservava o controle em troca de mais pessoal e integração.

A diferenciação da Prosimo era a combinação de trânsito de rede e aplicação, nós de borda, orquestração nativa, grafo, telemetria e inserção de serviços. Essa amplitude dificultava as comparações. Os compradores deviam testar serviços, rotas, identidades e segurança específicos.

A aquisição muda o quadro competitivo. A Prosimo já não compete como empresa independente; sua tecnologia deve justificar seu lugar dentro da Palo Alto Networks. A questão passa a ser quanto melhora a implantação de segurança e quanta dependência adicional os clientes estão dispostos a aceitar.

Os serviços nativos eram fundamento e substituto

AWS Cloud WAN, Transit Gateway, Azure Virtual WAN e Google Cloud ofereciam opções poderosas. A Prosimo dependia deles e competia com a operação direta por parte do cliente.

A fronteira era móvel. As novas funções nativas podiam reproduzir partes da proposta da Prosimo e, ao mesmo tempo, adicionar mais objetos que um controlador transversal devia coordenar. A evolução dos serviços de nuvem podia reduzir o valor de algumas funções e aumentar a necessidade de tradução entre provedores.

A decisão era organizacional, além de técnica. Uma empresa de uma única nuvem com forte engenharia podia preferir o nativo. Uma empresa multinuvem fragmentada podia valorizar um plano comum. Uma organização regulada podia apreciar evidência independente e temer concentração de credenciais.

Nenhum enfoque eliminava a dependência tecnológica. As ferramentas nativas vinculavam o cliente a APIs e semânticas específicas de um provedor; o controlador transversal o vinculava com seu grafo, suas políticas e seus nós de borda. A questão relevante era se essa dependência era visível, portátil e adequada ao modelo operacional da organização.

As falhas podiam se originar no controlador, nos nós de borda, nas APIs de nuvem, no sistema de identidade ou na infraestrutura subjacente

A arquitetura distribuída reduzia a dependência de um único concentrador, mas criava vários domínios de falha. O serviço central podia ficar desatualizado; um nó de borda, isolado; uma API, rejeitar parte da mudança; o sistema de identidade, parar de responder; a infraestrutura subjacente, degradar-se; ou um firewall, esgotar seus recursos.

As falhas parciais são especialmente difíceis de gerenciar. Um provedor pode aceitar uma atualização enquanto outro a rejeita, de modo que o estado desejado se separa do estado real e podem aparecer rotas assimétricas ou vias que contornam a inspeção. O sistema precisa de reconciliação, operações idempotentes, implantações graduais, estados de erro explícitos e mecanismos de reversão adaptados a cada provedor.

A evidência pública não contém provas independentes de injeção de falhas, um registro completo de incidentes nem resultados universais de nível de serviço. Por isso, qualquer afirmação sobre resiliência deve ser vinculada à arquitetura documentada ou a evidências concretas de clientes.

A aquisição adiciona outro risco: a continuidade do produto. Os clientes precisam saber qual console, API, imagem de nó, modelo de políticas e organização de suporte substituem o sistema histórico. Uma integração técnica satisfatória pode, ainda assim, produzir uma migração deficiente se as fronteiras comerciais e operacionais ficarem opacas.

As credenciais de nuvem convertiam o controlador em infraestrutura crítica

A descoberta e a orquestração exigiam acesso às contas de nuvem. O inventário podia utilizar permissões de somente leitura, enquanto as mudanças em rotas, segmentos e inserção de serviços requeriam uma autoridade maior. O controlador fazia parte do plano de gestão privilegiado, embora não fosse proprietário das cargas de trabalho.

Uma credencial comprometida podia expor topologia ou permitir mudanças amplas. Um defeito ou erro podia se propagar por várias nuvens. O raio de impacto aumentava com a utilidade da plataforma.

As empresas precisavam aplicar privilégio mínimo, credenciais separadas, aprovações múltiplas, auditoria, rotação, revogação de emergência e uma via de recuperação independente do mesmo controlador. Os materiais públicos não incluem uma avaliação de segurança independente e completa, portanto esses elementos devem ser tratados como controles necessários, não como garantias verificadas.

O grafo de telemetria era igualmente sensível. Podia revelar aplicações, estrutura de rede, políticas, relações de usuários, estado das rotas e padrões de custos. A governança posterior à aquisição deve esclarecer onde esses dados são armazenados, que produtos podem utilizá-los e como as permissões foram migradas; as fontes públicas não resolvem essas questões.

A aquisição transferiu uma camada neutra em relação à nuvem para uma plataforma de segurança

Como empresa independente, a Prosimo podia se apresentar como uma camada comum entre nuvens e serviços de segurança. Com a Palo Alto Networks como proprietária, os incentivos mudaram: a tecnologia podia facilitar a implantação do VM-Series e de outros produtos do grupo, melhorando a integração e levantando dúvidas sobre o tratamento de serviços de terceiros.

A propriedade não prova por si só que a neutralidade desapareceu, mas também não foi publicada uma matriz atualizada de compatibilidade. A pergunta para os clientes passa a ser se o suporte a terceiros é mantido, se as políticas e a telemetria podem ser exportadas e se a otimização favorece o portfólio do proprietário.

A declaração destacou a inspeção de entrada, saída e leste-oeste. Isso sugere que a topologia e a orquestração passaram a fazer parte de um sistema de implantação de segurança, mas não prova que o App Transit, o acesso de usuários, a otimização de custos ou todos os fluxos históricos continuaram como capacidades separadas.

É um padrão habitual de infraestrutura: uma startup abstrai um problema complexo de coordenação e uma plataforma maior compra essa abstração para aumentar o uso de seus produtos principais. O cliente pode ganhar integração e, ao mesmo tempo, perder parte de sua independência frente a fornecedores.

O mapa atual do produto é o maior dado ausente

A evidência confirma a aquisição e a integração, mas não oferece um mapa completo que relacione AXI, Network Transit, App Transit, AIR e Nebula com produtos ou SKUs atuais. Também não foram publicadas datas de suporte, procedimentos de migração nem uma tabela de continuidade funcional.

Essa ausência impede uma avaliação do produto no tempo presente. A história explica o que foi construído, mas não o que se vende ou se mantém hoje. Qualquer recomendação atual de implantação deve se basear na documentação vigente da Palo Alto Networks.

Também limita a estratégia. Uma absorção completa do grafo seria diferente de utilizar apenas a descoberta de ativos e a colocação de firewalls. A declaração confirma continuidade técnica e deixa o limite sem resolver.

Um documento de produto, guia ou caso futuro poderia esclarecer. Até lá, a formulação precisa é que, segundo um cofundador, a tecnologia foi integrada aos produtos da Palo Alto Networks, embora o alcance e o empacotamento não estejam verificados.

Quem controla o roteamento multinuvem?

Nenhum ator controla toda a rota. A empresa controla a propriedade das contas, a intenção de negócio, o design das aplicações e as credenciais que concede. O controlador descobre a topologia, traduz as políticas e modifica o estado das rotas; os provedores de nuvem controlam suas APIs, serviços de trânsito, endpoints privados, backbones e muitos domínios de falha; e as operadoras e provedores de colocation controlam outros trechos do transporte. Os serviços de segurança, por sua vez, decidem se o tráfego inspecionado é permitido ou bloqueado.

A Prosimo buscava a posição intermediária. Sem possuir a infraestrutura subjacente, queria possuir o grafo e a tradução. Quem controla essa camada decide o que se vê, como se representam segmentos, onde se colocam os nós de borda, que serviço inspeciona e que telemetria envia. Isso constitui poder prático sobre o roteamento.

Após a aquisição, a Palo Alto Networks controla a tecnologia e seu desenvolvimento. Os provedores de nuvem conservam a autoridade dentro de seus próprios ambientes, e a empresa pode revogar credenciais ou escolher outra arquitetura; ainda assim, a saída pode ser custosa se a topologia, as políticas e os fluxos operacionais dependerem do controlador.

A resposta é, portanto, estratificada: a empresa autoriza; o controlador coordena; os provedores de nuvem e as operadoras transportam; e a plataforma de segurança aplica os controles. A história da Prosimo mostra que o proprietário da camada de coordenação pode mudar sem que mudem de mãos as contas de nuvem ou a fibra física.

Registro principal de fontes

Por que a Prosimo continua sendo relevante após a aquisição

A Prosimo identificou uma mudança real na infraestrutura. A unidade de operação se desloca do dispositivo e do prefixo para a aplicação, a identidade, as dependências de serviço e o grafo de políticas. As APIs tornam o estado da rede programável, enquanto os nós de borda permitem mover os pontos de aplicação de controles. Um controlador com visibilidade sobre várias nuvens pode coordenar ações que nenhum console individual completa sozinho.

Também mostrou o custo dessa coordenação: credenciais privilegiadas, manutenção contínua de APIs, descoberta precisa, tradução semântica, telemetria e disciplina operacional. Uma camada comum pode reduzir o trabalho fragmentado e, ao mesmo tempo, criar um novo ponto de concentração. O mesmo sistema que simplifica as rotas pode ampliar o impacto de uma má decisão.

A aquisição torna mais visível a convergência entre redes e segurança. Uma empresa de segurança que conhece a topologia e pode mudar rotas não se limita a inspecionar o tráfego que recebe; também ajuda a decidir que tráfego chega à inspeção e onde ela ocorre.

A Prosimo não deve ser lembrada apenas como uma marca desaparecida nem como prova de que uma plataforma resolveu o problema multinuvem. Sua contribuição duradoura foi converter o grafo transversal em uma forma de infraestrutura. A pergunta pendente é se esse grafo, agora dentro de uma empresa maior, continuará sendo transparente, portátil e governável.