Summary

  • Founded in 2019, Prosimo raised at least $55 million in its 2021 Series A and 2022 Series B; audited revenue, valuation, and acquisition price remain unknown.
  • AXI combined centralised intent, topology, and analytics with distributed nodes that discovered cloud assets, connected applications, and inserted security without owning the physical network.
  • The VM-Series integration announced in June 2024 preceded Prosimo's move to Palo Alto Networks around February 2025; no source specifies the date, price, or current product mapping.
  • Control remains shared among enterprises, orchestration software, cloud providers, and Palo Alto Networks; portability of topology, credentials, policies, and routes thus becomes the decisive test.

The company disappeared before the problem

It would be inaccurate to present Prosimo as an active independent provider in 2026. Public professional histories show its founders and several employees joining Palo Alto Networks around February 2025. The Prosimo company page is marked as acquired, and former CTO Nehal Bhau later wrote that its technology had been integrated into Palo Alto Networks products. These facts establish a change of control and the continuity of its technical value. They do not determine the exact signing or completion date, legal form, or transaction price.

This correction should open the narrative, because it changes the tense of every statement about the products. AXI, Network Transit, App Transit, Application-driven Intelligent Results, and Nebula were Prosimo capabilities documented during its independence. They should not be presented as current separately sold products until Palo Alto Networks publishes a current product and support mapping. After an acquisition, historic architecture may survive as integrated code, a shared service, a module, or an internal engineering asset; those situations are not equivalent.

The brand's disappearance does not make the problem obsolete. Enterprises still distribute their workloads across Amazon Web Services, Microsoft Azure, Google Cloud, private data centres, colocation sites, SaaS platforms, and remote users. Each environment has its own routes, gateways, private endpoints, identity controls, security services, quotas, and billing rules. An enterprise may own all its accounts without having a single view of the path a request takes. Prosimo's significance lies in its attempt to control that overall picture.

The acquisition thus forms the narrative axis, not a mere footnote. Prosimo had built a cross‑sectional control layer capable of discovering assets, interpreting application context, and directing traffic to security services. Palo Alto Networks first appeared as a technical partner whose VM-Series firewalls could be inserted into those paths, then became the technology owner. The boundary separating orchestration and routing from deep inspection shifted inside a single cybersecurity platform.

Multi‑cloud routing is a battle for context

A routing table can say whether a prefix is reachable via a next hop. Alone, it cannot explain which application the user was trying to reach, whether the requester is trustworthy, whether an inspection service should see the traffic, whether a private endpoint is available, whether one cloud path costs more than another, or whether the transaction fails after the packet arrives. Multi‑cloud operations turn these questions into a shared‑control problem.

Prosimo's thesis was that routing authority should rely on more than layer‑3 reachability. Its software attempted to combine cloud inventory, network state, application identity, user identity, risk, performance, and transactional telemetry. That context enabled policies such as connecting a defined application, isolating a segment, choosing an entry point, or directing selected traffic to a firewall. The value did not come from inventing a new fibre path, but from deciding how to assemble existing paths and services.

That distinction explains the phrase “application experience infrastructure.” It placed the application request above every network entity. A VPC, a VNet, a subnet, a transit hub, or a private link became a component of an end‑to‑end path rather than the ultimate entity of management. The approach also positioned the product at the intersection of several markets: cloud networking, application delivery, zero‑trust access, network assurance, cost optimisation, and security‑service insertion.

This functional breadth created both opportunity and ambiguity. A product used by multiple teams can resolve coordination failures for which no single team is responsible. It can also be hard to evaluate, because network, security, cloud, application, and finance teams do not use the same success criteria. Prosimo had to demonstrate that a cross‑cutting model improved operations without becoming a new privileged layer whose errors would affect all environments.

What Prosimo was — and what remains

Prosimo was a private cloud‑networking software company founded in 2019 in the San Francisco Bay Area. Ramesh Prabagaran was its co‑founder and CEO, while Nehal Bhau served as co‑founder and CTO during its independent period. Public histories also identify Linus Aranha and Pradeep Aragonda in founding or engineering‑leadership roles, but their precise titles should remain tied to dated biographies.

Its core platform was called Application eXperience Infrastructure, usually abbreviated AXI. AXI combined a central software layer for intent, topology, analytics, and orchestration with distributed AXI Edges deployed in cloud regions, colocation environments, or adjacent on‑premises infrastructure. The offering was later organised under the names Full‑Stack Cloud Transit, Network Transit, and App Transit, supporting different classes of connectivity. AIR analysed telemetry and produced operational insights; Nebula added a conversational interface in 2024.

Prosimo was not a cloud operator. The company did not own a global fibre backbone linking every region. Paths could use cloud‑provider backbones, the public internet, direct circuits, colocation links, and the enterprise's own networks. Nor was it a firewall provider in the same sense as Palo Alto Networks. In the 2024 integration, its role was to discover, segment, and steer; VM‑Series provided deep security inspection.

After the acquisition, the most prudent description is “technology legacy.” The later integration statement emphasises multi‑cloud asset discovery and faster software firewall deployment for inbound, outbound, and east‑west traffic. It proves that important Prosimo components survived. It does not prove that the whole historic AXI catalogue, its go‑to‑market model, or its support model continued unchanged.

The problem that appeared after SD‑WAN

The founding team had experience in large‑scale networking, application delivery, and cloud infrastructure. Prosimo also came from the wider ecosystem of founders and engineers associated with Viptela, a company that had helped establish SD‑WAN as an enterprise category. The next problem was different. SD‑WAN could simplify the relationship between branch sites and networks or applications, but it did not create a single operating model inside and across multiple public clouds.

A multi‑cloud application may depend on a web endpoint in one environment, a database or managed service in another, an identity provider outside both, private connectivity to a data centre, and security inspection placed at certain boundaries. Every dependency can be represented by a different native entity. The network team sees prefixes and transit hubs; the cloud team sees accounts and resources; the application owner sees domains and transactions; the security team sees zones and inspection policies.

Prosimo started from the request rather than the branch. The useful question was how a user or workload ought to reach an application with an acceptable level of security, performance, availability, and cost. That framing shifted the entity of routing: from the destination prefix alone to a transaction carrying identity and application context. It also required the platform to collect and maintain far more information than a traditional router.

The timing was favourable. AWS, Azure, and Google Cloud were enriching their native transit and private connectivity services. Enterprises could build sophisticated networks with each provider, but the APIs, entities, and policy models remained provider‑specific. Prosimo's opportunity was to coordinate those services without forcing every customer to replace them with a separate proprietary backbone.

From founding in 2019 to public launch in 2021

Prosimo was founded in 2019, but its public launch was only announced on 6 April 2021. General Catalyst led a $25 million Series A at launch. The investor framed the opportunity as delivering application experience across multiple clouds, aligning with the founders' ambition to define a category that went beyond traditional branch connectivity.

The launch placed the company in a crowded and still poorly defined market. Cloud providers made it easy to consume their own networking services. SD‑WAN and SASE vendors were extending their policies to cloud environments. Application‑delivery providers could optimise requests, while cybersecurity firms could inspect them. Prosimo's proposition rested on bringing those functions together in a cloud‑oriented architecture, without claiming to replace the entire surrounding system.

The funding enabled development of integrations, software edges, analytics, a sales organisation, and partner relationships. It did not prove market fit, revenue scale, or durable differentiation. No audited revenue, annual recurring revenue, customer count, or valuation is published in the provided materials. Funding shows investors' commitment to a thesis, not a complete account of operational performance.

In 2022, Prosimo completed a $30 million Series B, described as oversubscribed. Adding the two clearly identified rounds gives a verified total of at least $55 million. Some databases may show more when they duplicate related announcements or filings; those totals should not be used without resolving the underlying events.

AXI placed policy above clouds and execution near workloads

The AXI architecture split work between a central control and analytics layer and distributed software edges. The central layer held application and network intent, discovered assets, assembled topology, integrated identity, analysed telemetry, and orchestrated changes. AXI Edges were deployed close to workloads or users, enforcing policies without forcing every path to traverse a distant physical hub.

This separation recalls other software‑defined systems, but the entities were cloud‑native and application‑aware. The controller needed access to cloud accounts and their APIs, while the edge had to connect to native transit services, workload networks, private endpoints, or external paths. The platform's authority came from combining those views: global intent above the clouds and local execution near the affected traffic.

The architecture also created a concrete deployment boundary. Every edge consumed cloud resources, required high‑availability design, and had to be updated, monitored, and secured. The control layer demanded credentials with sufficient privilege to discover assets and modify network state. The enterprise gained a common workflow but added a management system whose availability and reliability became critical for production reachability.

Prosimo sometimes used the vocabulary of “autonomous cloud networking.” The evidence supports automation, recommendations, and API‑driven orchestration. It does not describe a network independent of human policies, cloud‑provider services, or underlying transport. Operators still defined intent, approved access, handled exceptions, and remained accountable for the outcome.

AXI Edge was a placement decision, not a generic appliance

An AXI Edge could be deployed in a cloud VPC or VNet, a colocation environment, or adjacent infrastructure. The AWS technical guide showed an edge VPC linked to workload VPCs through Transit Gateway, with optional firewall chaining and access from remote users or on‑premises sites. Prosimo's execution thus sat inside the cloud topology rather than at a distant corporate perimeter.

Placement affected more than latency. It determined where traffic entered the policy domain, which cloud backbone or internet path was used, where encryption and inspection happened, and what telemetry was accessible. A badly placed edge could create a detour or cost; appropriate placement could shorten the path or keep traffic near the workload.

Distribution multiplied failure domains. Capacity, software versions, cloud‑zone design, route convergence, and permissions could vary across regions. High availability was not just two instances: the controller, cloud routing tables, security services, and return paths all had to agree on failover state.

The edge was therefore part of a larger operating system. Its value depended on consistency among asset discovery, topology, policies, analytics, and the cloud environment. Treating it as a stand‑alone virtual appliance would miss the architecture Prosimo aimed to sell.

The underlying transport always belonged to someone else

Prosimo coordinated transport without owning the physical path. An application connection could use an AWS or other cloud backbone, the public internet, Direct Connect or ExpressRoute, a colocation service, a carrier circuit, or the enterprise network. The platform could select and orchestrate available options; it could not remove latency, packet loss, failure domains, or pricing rules created by those providers.

That boundary is critical for evaluating performance promises. A controller can choose a better observed path or bring the entry point closer to the user. It cannot guarantee that a carrier will not fail, that a cloud region will stay available, or that an external dependency will respond quickly. Application experience also includes DNS, server processing, storage, browser behaviour, and third‑party services — all outside the network controller's full authority.

The absence of a proprietary backbone was not only a weakness. It allowed Prosimo to use infrastructure enterprises had already bought and to benefit from cloud‑provider investment. The company could reach new regions without laying fibre and coordinate native systems such as AWS Cloud WAN. In exchange, it depended on the stability of APIs, quotas, commercial terms, and provider‑specific semantics.

The proposition was therefore about operational control, not physical ownership. Prosimo sought to make heterogeneous underlays operate as a single managed system while retaining their native advantages. Whether that abstraction reduced lock‑in or merely moved it depended on the portability of policies, topology, and edge deployment.

Network Transit handled reachability of network entities

Network Transit focused on VPCs, VNets, subnets, regions, sites, and segments. It coordinated native transit services and routing entities so that teams could build connectivity through a common workflow, rather than configuring each provider separately. The product addressed the classic network need: a source or segment must reach a destination through an authorised path.

It did not claim that cloud differences had disappeared. AWS, Azure, and Google Cloud expose different entities, quotas, and routing behaviours. Overlapping address spaces, asymmetric paths, private endpoints, and service limits still required engineering. Prosimo could standardise common operations and display relationships, but the underlying systems retained their constraints.

Network Transit also carried segmentation. Routing domains and policies could separate environments or limit reachability. The controller had to understand where a segment existed across clouds and how native entities materialised that boundary. A policy written once could still produce several provider‑specific changes.

The benefit was a unified intent surface. The risk lay in translation. If common policy and cloud configuration diverged, the enterprise might believe a segment was protected while actual state said otherwise. Reconciliation, audit, and explicit failure reporting were therefore as important as initial provisioning.

App Transit made the application a routing entity

App Transit extended the model beyond subnets. It could consider application domain, identity, request type, transactional health, risk, and performance to decide how a user or workload reached a service. This was Prosimo's clearest attempt to distinguish itself from a conventional cloud router.

The application view was useful because modern services are not always represented by fixed addresses. Managed platforms, SaaS endpoints, and distributed components can change while the service identity stays stable. A policy referencing application or user can last longer than a rule built only from addresses and ports.

The model required accurate discovery. The controller needed to know which domains and endpoints belonged to an application, which dependencies were needed, and which identity‑provider claims were reliable. Stale mapping could direct a request down the wrong path or apply the wrong security rule. The application abstraction did not remove the need to understand network state; it added a semantic layer on top.

Pairing Network Transit and App Transit acknowledged that both worlds coexist inside the enterprise. Legacy systems, private subnets, and IP controls remain, while newer applications depend on domains, identity, and managed services. Full‑Stack Cloud Transit was the name given to operating those models together, without forcing one to replace the other.

Identity broadened the routing decision and trust perimeter

Application‑aware access required identity integration. The platform could use user or workload context to decide whether a connection should be established and through which path. This supported a zero‑trust‑style policy in which location alone did not prove authorisation.

Identity improved precision but added a dependency. The route or application policy now relied on the identity provider, its claims, session state, and group data. A path could fail because authentication was unavailable or an attribute had changed, even while routers and edges remained healthy. Diagnosis had to cross the network‑identity boundary.

The controller also became a concentration point for sensitive information. It could hold topology, application relationships, user attributes, risk signals, and policy results. That dataset improved diagnosis and optimisation while raising the consequences of unauthorised access. Least privilege, retention, audit, and separation of duties were therefore architectural concerns, not mere administration.

Prosimo's approach illustrates a broader evolution: routing and access increasingly depend on identity and application semantics. The more context a platform sees, the more useful its decisions can be — and the more carefully its authority must be governed.

Asset discovery created the graph on which decisions depended

A cross‑cutting controller cannot govern what it cannot see. Prosimo developed cloud‑asset discovery and maps representing VPCs, VNets, subnets, applications, connectivity, and security relationships. Those views supported onboarding, design, diagnosis, and policy.

Discovery was strategic because cloud environments evolve outside central network processes. Application teams can create accounts, networks, endpoints, and managed services through their own automation. A hand‑drawn diagram goes stale. An API‑driven inventory can provide a fresher graph, but its completeness still depends on covered accounts, permissions, parsers, and provider APIs.

The graph was not merely documentary. It was the structure from which routing, segmentation, service insertion, and optimisation could be computed. If an asset or dependency was missing, all conclusions built on top could be wrong. Topology therefore needed provenance: collection date, source account, covered regions, and any query failures.

This graph also helps explain the acquisition. Palo Alto Networks creates security value when it knows where workloads and traffic paths are. A system that can discover assets and change routes reduces the distance between buying a software firewall and placing it correctly. Nehal Bhau's later integration statement highlighted precisely asset discovery and faster software‑firewall deployment.

AIR turned edge telemetry into recommendations

Application‑driven Intelligent Results, or AIR, analysed telemetry collected by AXI Edges. The AWS guide described visibility into round‑trip time, processing time, application response time, transaction type, risk, and policy outcomes. The platform could correlate user, network, and application observations instead of presenting isolated counters.

This correlation addressed a common operational problem. A slow transaction may be caused by the user path, the edge, the cloud backbone, a security service, or the application. A cross‑cutting view can reduce time‑to‑diagnosis compared with separate consoles. It can also support recommendations on path, placement, risk, or cost.

The quality of a recommendation depended on telemetry coverage and the interpretation model. An edge saw only traffic that passed through it. External application dependencies and some provider‑internal conditions could remain invisible. A recommendation could be useful without demonstrating root cause.

Telemetry also had governance value. Historical observations could explain why a route or policy changed. They could also expose sensitive application usage and user behaviour. Public information does not describe post‑acquisition data retention or governance in full; those questions therefore remain within customer due diligence.

AWS provided the best‑documented public implementation

Prosimo's work with AWS constitutes the strongest public technical evidence. The company integrated with AWS Transit Gateway, Cloud WAN, PrivateLink, and the Marketplace for Containers Anywhere workflow. AWS published a guide on AXI Edge placement, application integration, identity, security, and optimisation.

AWS Cloud WAN was particularly important. It provided a native backbone and segmentation service that Prosimo could orchestrate rather than replace. The architecture showed the cooperative model: AWS owned the native network and global infrastructure; Prosimo brought multi‑cloud intent, application context, edge software, and analytics.

The Marketplace workflow simplified the first step by delivering AXI Edge through an approved channel. It did not remove the later work on account permissions, route design, high availability, capacity, and operations. Day‑zero automation can reduce setup friction while leaving the long‑term control problem intact.

A named reference to Flexport supported the AWS Cloud WAN case in company documents. It shows that an enterprise customer agreed to recommend the architecture but does not constitute an independent audit of scale, savings, or availability. Customer citations should be used as adoption examples, not universal performance proof.

Azure and Google Cloud completed the multi‑cloud promise

Prosimo also supported Microsoft Azure and Google Cloud. Its documents mentioned orchestration around Azure Virtual WAN and Google Cloud's private network and service entities. The aim was to present a single operating model while leaving each provider's native network in place.

Support does not prove feature parity. Cloud APIs mature at different rates, and similar product names can hide distinct semantics. A route, a segment, a private endpoint, or a service insertion may need provider‑specific handling. The supplied sources do not reconstruct a feature‑by‑feature parity matrix for every region and version.

A multi‑cloud abstraction is therefore a translation system. It can standardise common intent and workflows but must preserve details that affect security, cost, and failures. A platform becomes dangerous when the interface appears uniform while implementation differences are hidden from operators.

The same principle applies after the acquisition. Palo Alto Networks can use the common graph to place security across multiple clouds, but providers retain control of the native entities that materialise the path. Owning the orchestration does not mean owning the cloud underlay.

The product expanded from connection to lifecycle

In 2023, Prosimo described workflows for designing, building, troubleshooting, and managing multi‑cloud networks. The product went beyond a tunnel or a gateway. Asset discovery supported design; orchestration created connectivity; maps and telemetry aided diagnosis; policies and history supported ongoing management.

This framing broadened the potential buyer. A network engineer could use topology and path analysis; a cloud platform team could integrate accounts and services; a security team could review segmentation and inspection; a migration team could plan changes; a FinOps team could examine routing and egress consequences. Value increased when multiple groups used the same evidence.

Common evidence can also cause governance conflicts. A central platform may reveal that a cloud team's native configuration differs from enterprise policy. The organisation must decide which system is authoritative and who can approve correction. The software does not solve that institutional question alone.

The lifecycle narrative also increased switching costs. When a controller holds the asset graph, policies, telemetry, edge placements, and automation integrations, replacing it requires more than moving a circuit. The customer must export or rebuild its operating model. Prosimo sold a reduction in cloud fragmentation while creating the potential for controller dependency.

Segmentation moved from network reachability to application policy

Prosimo presented segmentation from layers 3 to 7. At the network level, routing domains and segments determined which subnets or sites could communicate. At higher levels, application identity, user context, and transaction properties could refine the rule.

This model could narrow the gap between network zone and application policy. A business service could be allowed while broad subnet‑to‑subnet reachability remained blocked. Conversely, a valid network path could be denied because identity or application context failed.

That did not turn Prosimo into a full next‑generation firewall. The integration with Palo Alto Networks separated responsibilities: Prosimo orchestrated routes, segmentation, and service insertion; VM‑Series performed deep inspection. The distinction matters because policy steering and security enforcement fail in different ways.

A segment is effective only if all relevant paths are represented. An unknown route, a native exception, or a failed insertion can bypass the control. Assurance therefore requires comparing declared policy, provider state, and observed traffic — not trusting the controller screen alone.

Service insertion tied route control to firewall economics

Cloud security must decide where inspection happens. Centralised firewalls sometimes simplify policy and reduce instance count, but can create detours, concentration, and capacity pressure. Distributed firewalls stay close to workloads and reduce some distortions, but multiply deployment, licensing, updates, and policy operations.

Prosimo supported both models in the VM‑Series integration. Policy could direct selected traffic to a central point or to distributed firewalls inside application VPCs. The controller updated surrounding routes while Palo Alto Networks provided inspection.

The architecture made routing orchestration valuable to a security vendor. A software firewall does not protect traffic that never passes through it. Discovery, placement, and route changes reduce friction between buying security capacity and inserting it into an active path. This is a plausible strategic reason for Palo Alto Networks absorbing Prosimo technology.

It also widened the controller's blast radius. A bad policy could bypass inspection, create a loop, produce asymmetric routing, or break the application. Health checks, staged changes, simulation, audit, and rollback are necessary because an insertion mistake is both a network incident and a security incident.

The 2024 partnership must not be retroactively turned into an acquisition

Prosimo and Palo Alto Networks announced the VM‑Series integration on 12 June 2024. The release described a joint technical and commercial solution. It did not say Palo Alto Networks had acquired Prosimo. Using that announcement as proof of ownership would conflate two distinct events.

The partnership nevertheless created a bridge. Prosimo could show how its route and policy system made VM‑Series easier to deploy across multiple clouds. Palo Alto Networks could evaluate the technology in a real integration before the later transition. Public sources do not describe the acquisition process; claiming the partnership was formally a preparatory step would be speculative.

By early 2025, founder and employee histories had changed. The company page later displayed an acquired status. By late 2025, Bhau stated that the technology was fully integrated into Palo Alto Networks products. Together, these items support the conclusion that an acquisition occurred, while leaving legal mechanics unresolved.

This sequence matters for editorial accuracy and for customers. A partnership means two vendors, two support structures, and a defined integration boundary. An acquisition can shift roadmaps, data, contracts, and authority into a single company. The transition changes more than the brand, even if the technical path initially looks similar.

Nebula turned the topological graph into a conversational interface

Prosimo introduced Nebula in February 2024 within an AI Suite for multi‑cloud networking. The assistant was designed to answer natural‑language questions about overlapping networks, costs, route health, security‑policy violations, and other conditions represented in the graph and telemetry.

The valuable asset was not the language interface alone, but the underlying structured multi‑cloud context. A general model cannot diagnose a private route or segment it cannot see. Nebula could draw on inventory, topology, policies, and observations already collected. The prior investment in a common graph thus became relevant to AIOps.

Conversational access could make complex data accessible to more operators. It could also create false trust if the response omitted an unsupported asset, misunderstood the question, or treated a recommendation as an approved action. High‑risk changes still required deterministic controls, permission boundaries, and human review.

Prosimo claimed potential improvements including a 60–80% reduction in mean time to resolution and over 60% reduction in cloud network cost. Those figures were company claims in a product announcement. No independent methodology or provided customer base demonstrates they apply generally. They may be cited as benefits proposed by Prosimo, not as measured market facts.

AI workloads were a use case, not proof of a new market

The same 2024 announcement presented the architecture as useful for artificial intelligence workloads. Distributed AI systems may require private data access, connections between clouds and data centres, compliance controls, and application‑behaviour‑aware routing. Those needs matched the asset, policy, and path model already developed.

The label did not change the underlay. Prosimo still depended on cloud networks, carriers, and customer infrastructure. The company provided neither GPU compute nor model‑development software. Its potential role was connectivity and security around distributed data and services.

The AI positioning was logical because the value of a cross‑cutting topology increases with data and service distribution. It was also a marketing category introduced shortly before independence ended. The supplied materials establish neither separate AI‑related revenue, named production deployments, nor audited outcomes.

The durable point is that multi‑cloud telemetry can feed machine‑assisted operations. The current question is whether Palo Alto Networks retained that context and how it exposes the capability. Public sources available at the cut‑off date do not give the full answer.

The business model sold software on top of third‑party infrastructure

Prosimo operated as a subscription‑software and services company, not as an operator. Customers deployed AXI Edges in their own environments and connected their cloud accounts to the control layer. Revenue would have depended on licences or subscriptions, support, professional services, and channels, but exact pricing and contract metrics are not published in the provided materials.

The model could grow without owning fibre. A software platform could coordinate many regions and environments. Nevertheless, gross economics cannot be inferred. Supporting provider APIs, the edge lifecycle, security integrations, and enterprise deployment can be expensive, while cloud resources consumed by the edges may be paid directly by the customer.

Prosimo used marketplaces, integration partners, channels, and customer references to reach enterprises. These relationships are not equivalent. A marketplace presence proves a purchase and deployment channel. A technical integration proves two systems can work together under defined conditions. A customer citation provides a reference. None alone reveals paying customer count or recurring revenue.

The breadth of the offering could complicate sales. Network, security, cloud, and application teams could all benefit, but budget ownership might remain unclear. The product needed a buyer willing to fund a shared control layer rather than let each cloud and each team operate separately.

Partners, customers, and investors held distinct positions

Amazon Web Services was both an underlying infrastructure supplier and a commercial integration partner. Azure and Google Cloud were supported environments. Identity providers supplied authentication context. Firewalls supplied inspection. Colocation and carrier services could host or link edges. Channel partners could design and operate deployments.

Flexport appeared as a customer reference in AWS Cloud WAN documents. The reference shows enterprise interest in the architecture, but the materials do not provide the deployment's full scope, duration, or commercial value. It should not substitute for total customer count.

General Catalyst led the Series A and participated in governance as an investor. WRVI‑ or Celesta‑linked investors appeared in documents, while later messages mentioned other known stakes, including a BlackRock‑related name whose exact vehicle was unresolved. These items indicate a well‑connected funding base, not a complete cap table.

Palo Alto Networks held the most important relationship. The firm moved from security partner in 2024 to acquirer in early 2025. The sequence shows how an ecosystem dependency can become a control relationship when one entity buys the software layer that coordinates the path to its product.

At least $55 million was raised; exit economics remain unknown

Verified funding includes a $25 million Series A in April 2021 and a $30 million Series B in 2022, totalling at least $55 million. No audited cap table, valuation, debt, or later round is available in the provided materials.

The acquisition consideration was not disclosed or independently verified. Without a price, the transaction cannot properly be called a strategic premium, a modest technology buy, an acqui‑hire, or a distressed sale. The continued integration supports technology value but does not reveal investor or founder returns.

Palo Alto Networks' revenue and scale must not be attributed to Prosimo after the acquisition. The startup ceased to be separately observable, so there is no stand‑alone revenue, profit, or customer segment to analyse. A larger owner can deploy the technology more widely while making its individual economics less visible.

The absence of a formal acquisition announcement is itself relevant. Customers, employees, and researchers normally use such releases to determine timing, support, and strategic logic. Here, status must be reconstructed from career histories, a company‑page label, and a later founder statement. That is enough to correct status, limited public evidence to invent transaction detail.

Competition came from platforms, clouds, and in‑house engineering

Prosimo competed against specialist platforms such as Aviatrix and Alkira, enterprise‑networking and SASE vendors, and the native services of AWS, Azure, and Google Cloud. It also faced an in‑house model in which the enterprise directly uses infrastructure‑as‑code, transit services, routing tables, and provider firewalls. Those alternatives solved different portions of the same problem.

A specialist controller could provide a single topology and policy model. A cloud‑native design could reduce third‑party dependency and align tightly with one provider. A carrier‑led service could supply physical transport. A SASE or security platform could combine connectivity and enforcement. In‑house engineering could preserve control at the cost of staffing and integration effort.

Prosimo's differentiation brought together application and network transit, distributed edges, native orchestration, topology, telemetry, and service insertion. That breadth also made comparisons hard. Buyers had to test the specific clouds, routes, identities, and security models they actually expected to use, rather than comparing category labels.

The acquisition changes the competitive framework. Prosimo no longer has to win as an independent company; its technology must prove its worth inside Palo Alto Networks. The relevant comparison becomes whether the integrated discovery and orchestration capability improves deployment of Palo Alto security products, and whether customers accept the resulting dependency.

Native cloud services were both foundation and substitute

AWS Cloud WAN, Transit Gateway, Azure Virtual WAN, and Google Cloud's networking services gave enterprises powerful native options. Prosimo depended on those services and faced the possibility that customers would exploit them directly.

This relationship created a moving boundary. When a provider added global routing, segmentation, private services, or central policy, some third‑party functions became easier to replicate. At the same time, each new native service added an entity the cross‑cutting controller could discover and coordinate. Cloud advances could reduce some of Prosimo's value while increasing the need for cross‑provider translation.

The decisive factor was organisational as much as technical. A single‑cloud enterprise with strong internal engineering might prefer native tools. A multi‑cloud enterprise with fragmented teams might value a single control plane. A regulated organisation might welcome an independent evidence layer while worrying about credential and data concentration.

No architecture eliminated lock‑in. Native tools increased dependency on a single cloud's APIs and semantics. A cross‑cutting controller increased dependency on its graph, policies, and edges. The useful question was whether the dependency remained visible, portable, and suited to the operating model.

Failure could lie in the controller, the edge, the cloud API, identity, or underlay

The distributed architecture reduced reliance on a single traffic hub but created multiple interacting failure domains. The central service could be unavailable or hold stale intent. An edge could fail or become isolated. A cloud API could reject part of a change. The identity provider could be unavailable. The underlay could lose capacity or take an unexpected route. An inserted firewall could exhaust resources.

Partial failures are especially hard. One provider may accept a route change while another rejects it. The controller's desired state then diverges from actual state. Traffic can become asymmetric or bypass inspection. A reliable system needs reconciliation, idempotent operations, staged changes, explicit error states, and provider‑specific rollback.

Public sources describe the availability architecture and optimisation, but include neither independent fault‑injection study, full incident record, nor universal service‑level outcome. Resilience claims must remain tied to documented architecture or a named customer example.

The acquisition adds another failure domain: product continuity. Customers need to know which console, API, edge image, policy, and support organisation replaces the historic system. A technically successful code integration can create migration risk when commercial and operational boundaries remain unclear.

Cloud credentials made the controller critical management infrastructure

Discovery and orchestration required access to cloud accounts. A read‑only inventory could use limited rights, while changes to routes, segments, and services demanded stronger authority. The controller thus sat in the privileged management plane even though it did not own the workloads.

Credential compromise could expose topology or allow widespread changes. A software defect or operator error could propagate a policy across multiple clouds. Risk grew with utility: the more accounts and services the platform governed, the larger the potential blast radius.

Enterprises needed least‑privilege roles, separate credentials for discovery and write, multi‑party approval, full audit, rotation, emergency revocation, and a recovery path independent of the controller. Public documents do not provide a full independent security assessment; these requirements therefore remain necessary deployment controls, not verified guarantees.

The telemetry graph was equally sensitive. It could reveal application names, network structure, policies, user relationships, route health, and costs. Post‑acquisition governance should clarify where that data is stored, which Palo Alto Networks products can use it, and how historic customer permissions were migrated. Public sources do not answer those questions.

The acquisition moved a purportedly neutral layer into a security platform

Prosimo's independent stance had let it present itself as a common layer between clouds and security services. When Palo Alto Networks became the owner, incentives changed. The acquired technology could ease deployment of VM‑Series and other Palo Alto products. That may produce better integration while raising questions about support for third‑party inspection.

Ownership does not prove neutrality disappeared. The provided materials contain no current partner or architecture matrix. They do, however, change the question to ask. Customers need to know whether the controller remains open to multiple vendors, whether policies and telemetry are exportable, and whether optimisation favours the owner's portfolio.

The integration statement emphasised inspection of inbound, outbound, and east‑west traffic. That suggests topology and orchestration became part of a security‑deployment system. It does not prove that the historic App Transit, user access, cost‑optimisation, or every network workflow survived separately.

This is a common pattern in infrastructure. A startup abstracts a hard coordination problem; a large vendor buys the abstraction because it increases usage and control of its core product. The acquirer gains a path to deployment. The customer may gain integration and lose vendor independence.

Current product mapping is the main missing fact

The public record confirms acquisition and integration but does not provide a complete mapping between AXI, Network Transit, App Transit, AIR, and Nebula and any current Palo Alto Networks products or offerings. It publishes neither end‑of‑support dates, migration procedures, nor a functional‑continuity table.

This gap prevents a present‑tense product review. Historic descriptions explain what Prosimo built and why it mattered. They do not say which capabilities are currently available, licensed, or supported. Any contemporary deployment advice must rest on current Palo Alto Networks documentation, not old Prosimo announcements.

The mapping absence also limits strategic analysis. Full absorption of the graph and orchestration would differ from selective use of asset discovery and firewall placement. The former would create a broad multi‑cloud control service; the latter would use Prosimo mainly to accelerate security deployment. The co‑founder's statement confirms technology continuity without resolving that boundary.

A future product document, migration guide, or customer case could remove much uncertainty. Until then, the precise wording is that Prosimo technology has been integrated into Palo Alto Networks products according to a co‑founder, while its scope and go‑to‑market status remain unverified.

Who controls multi‑cloud routing?

No single actor controls the complete path. The enterprise controls account ownership, business intent, application design, and the rights it grants. A cross‑cutting controller can discover topology, translate policy, choose paths, and change native route state. Clouds control their APIs, transit services, private endpoints, backbones, and many failure domains. Carriers and colocation sites control other portions. Security services decide whether inspected traffic is allowed.

Prosimo sought the most strategic middle position. Without owning the underlay, it wanted to own the graph and policy translation above it. Whoever controls that layer decides which assets are visible, how segments are represented, where edges are placed, which service inspects traffic, and which telemetry is authoritative. That is practical routing power even when fibre belongs to a third party.

After the acquisition, Palo Alto Networks owns the surviving technology and determines its integration, go‑to‑market, and development. Clouds remain sovereign in their environments, and the enterprise can revoke credentials or choose another architecture. Exit may, however, be costly if topology, policies, and workflows have become controller‑dependent.

The answer is therefore distributed: the enterprise authorises; the controller coordinates; the underlying cloud and carrier infrastructures transport; the security platform enforces. The Prosimo story shows that ownership of the coordination layer can change without any cloud account or physical path changing hands.

Principal source register

Why Prosimo remains relevant after the acquisition

Prosimo captured a real infrastructure shift. The unit of network operations is moving from device and prefix to application, identity, service dependency, and policy graph. Native APIs make network state programmable, while distributed software edges enable moving policy enforcement points. A controller that sees multiple clouds can coordinate actions that no single console can achieve alone.

The company also revealed the cost of that coordination. A common layer demands privileged credentials, ongoing API maintenance, accurate discovery, semantic translation, telemetry, and operational discipline. It can reduce fragmented effort while creating a new concentration point. The same system that simplifies routing can widen the blast radius of a mistake.

The acquisition by Palo Alto Networks makes the control question more visible. Networking and security converge around service insertion, workload discovery, and policy. A vendor that knows the topology and can change routes does not merely inspect traffic presented to it; it can help decide which traffic reaches inspection and where.

Prosimo should therefore be remembered neither as a standalone brand that simply failed nor as proof that one platform solved multi‑cloud. Its lasting contribution was to define the cross‑cutting graph as infrastructure. The remaining question is whether that graph, now inside a large security company, stays sufficiently transparent, portable, and governable to warrant trust.