Digital Sovereignty

Your AI gateway should not belong to your AI vendor

In the space of a year, a security company, a hyperscaler, a productivity suite and a chip manufacturer all decided that the layer sitting between an organisation and its models was the one worth owning. Their agreement is the most useful evidence available about why it should not belong to any of them.

P J Laszkowicz

On 24 March 2026 the engineers at Portkey did something generous. They took their production AI gateway, the piece of infrastructure that sat between roughly twenty-four thousand organisations and every model those organisations were calling, and they put the whole thing into a public repository under the Apache licence. Everything that had previously required a subscription went with it: the governance layer, the observability, the authentication, the cost controls, along with a gateway for the Model Context Protocol, the standard by which agents reach tools. At the time the software was carrying more than a trillion tokens and something over a hundred and twenty million requests a day.1

Five weeks later, Palo Alto Networks announced it was buying the company. The deal closed on 29 May, and on 16 July the same software reappeared as the Prisma AIRS AI Gateway, generally available and described by its new owner as the AI control plane for the enterprise, a single enforcement layer sitting inline across model calls, tool calls and agent-to-agent traffic.

There is nothing improper in that sequence and no reason to think badly of anyone in it. Portkey's engineers built something good enough that the largest pure-play security company in the world wanted to own it, which is a compliment, and open-sourcing it first was a real act of generosity that nobody was obliged to perform. But something changed in those five weeks and it was not the software, which continued to do exactly what it had done in March. What changed was whose interests it now served: the most widely deployed independent AI gateway had become the front door of a security platform.

Nor was it an isolated event. Over roughly the same twelve months, three other companies arrived at the same layer from entirely unrelated directions, and it is the pattern rather than any individual deal that ought to give an enterprise architect pause.

Before going further I should say that we build an AI gateway ourselves, and that ours is one of the independent ones, so the argument below is not disinterested. What I can offer instead is the reasoning in full, and a set of tests at the end that apply to us as readily as to anybody else.

A security company, a cloud, a suite and a chipmaker

Palo Alto came to the gateway through security, and Portkey was the fourth acquisition in a deliberate sequence. Protect AI arrived in July 2025 to handle model scanning, then CyberArk for identity and Chronosphere for observability in February 2026, with the CyberArk stack relaunched under the name Idira that May. Each of those addresses a different part of the problem, and the gateway is the place where all four of them finally touch live traffic, which is presumably why it was worth buying.

Google came through the cloud. At Cloud Next on 22 April 2026 the company folded its scattered agent products into the Gemini Enterprise Agent Platform and retired Vertex AI as a brand, and the result is unusually complete: a development kit, a low-code studio, a managed runtime, a Kubernetes sandbox, agent identity built on the SPIFFE standard, an AI firewall, a gateway, evaluation tooling that is genuinely ahead of the field, and a marketplace to distribute the results. Google is also doing substantial work in the open, driving the Agent2Agent protocol to version 1.0 under the Linux Foundation with more than a hundred and fifty organisations involved, and publishing the Open Knowledge Format. All of which sits inside a platform where identity roots in Google's own access management and the runtime is Google's cloud.

Microsoft came through the productivity suite, which is the route least likely to be noticed by anyone thinking about AI infrastructure. Agent 365 reached general availability on 1 May 2026 at fifteen dollars a month for each person covered, bundled into the Microsoft 365 E7 tier alongside E5, Copilot and Entra. Every agent receives an identity in Entra, with conditional access, audit logging and lifecycle management attached to it, and from March, Copilot Studio began issuing those identities automatically to every new agent anyone created. Agent governance stopped being a procurement decision and became a line item in a licence most large organisations were already paying for.

NVIDIA came through silicon. OpenShell shipped on 16 March 2026 under Apache 2.0, an out-of-process runtime that enforces policy an agent cannot override even when compromised, built from a sandbox, a policy engine covering filesystem, network and process, and a privacy router that decides whether a given inference stays on a local model or travels to a frontier one. It is good engineering, and out-of-process enforcement has become the reference architecture for this problem largely because NVIDIA shipped it that way. It also runs best on NVIDIA hardware, from workstations through DGX units to clusters, and the wider stack pairs it with NVIDIA's own open models.

Four companies, then: a security vendor, a hyperscaler, a productivity suite and a chip manufacturer. They share almost nothing. Not their customers, not their cost structures, not their competitors, not their theories of where value accumulates in this industry. Yet within about a year all four concluded that the layer worth owning was the one sitting between an organisation and the models, tools and agents it uses, and each of them paid or built accordingly.

When four parties with completely different revenue models converge on the same layer, that layer is a control point, and the convergence tells you more than any of the individual transactions do. Gartner appears to have read the situation the same way. In a first take published the day after the Portkey acquisition was announced, its advice was to keep gateway strategy independent of whatever gateway arrives bundled inside a larger platform, and it framed the reason as a limitation inherent in embedding rather than a gap that any particular vendor might eventually get around to closing.2

Everything passes through it

To understand why the layer attracts this much attention it helps to be concrete about what actually crosses it. An AI gateway sees every prompt and every response. It sees which model was selected and what that selection cost. It sees each tool an agent reaches for, the arguments passed to it, and the credential used to make the call. It sees agents talking to other agents. In an organisation of any size it is the only place where all of that is visible at once, because the alternative, which is instrumenting every application, framework and agent separately, does not survive contact with a real estate for very long.

That visibility is exactly why the gateway is the right place to enforce policy. Stopping sensitive material from reaching an external model means redacting it where the traffic is; applying spending caps means applying them where the spending is visible; and proving to an auditor what your agents did means generating that evidence at the point of enforcement, because anywhere else involves reconstructing the story from logs afterwards and hoping the reconstruction holds. Every platform vendor wants the layer for the same reason every architect needs it, which is that governance becomes concrete there and whoever holds it holds the account. When Palo Alto describes the acquired software as a control plane, that is an accurate description of the component rather than marketing inflation.

Nobody has to act in bad faith

The trouble with an embedded gateway has very little to do with anyone intending to mistreat a customer. It has to do with incentives that resolve over a period of years in a direction that is not the customer's, and four of those are specific enough to be worth setting out, since vague warnings about lock-in are easy to wave away.

Routing neutrality goes first. A gateway's most valuable function is deciding where a given request should go, whether because one model is cheaper, another is better at this particular task, or the content in question has to stay on infrastructure the organisation controls. When the company operating that gateway also sells models, cloud capacity or the hardware underneath, the instruction to route to the best available provider and the instruction to route to our own quietly converge. Support for competitors survives, because withdrawing it would be conspicuous and embarrassing, but the incentive to keep those paths as fast, as well tested and as well documented as the house path does not survive with it, and the degradation is gradual enough that nobody has to decide to cause it.

Governance scope narrows next, contracting to whatever the parent platform can see. A hyperscaler's agent identity binds to its own directory, a security platform's enforcement assumes its own sensors, and a productivity suite's agent controls stop at the edge of the suite. Real estates look nothing like that, being a mixture of several clouds, several model vendors, self-hosted systems and a population of agents nobody centrally planned, so an embedded gateway ends up governing the fraction of the estate that falls inside its parent's perimeter. The ungoverned remainder is, predictably, where the interesting problems turn out to live.

Deployment follows the vendor's economics rather than the customer's. Sovereign, on-premises and disconnected operation are expensive to build and expensive to keep working, and they serve customers a platform vendor can often reach through other products anyway, which makes them the first commitments to slip when a roadmap tightens. The environments with the strongest governance requirements, meaning defence, health, critical national infrastructure and anywhere a regulator takes an interest in data residency, are therefore the ones most likely to find themselves underserved, which is precisely the wrong way round.

The fourth is that openness turns out to be revocable, and 2026 supplied an unusually clear demonstration of what that means in practice.

Six thousand pull requests

Gemini CLI was open source in every sense that usually matters. It carried the Apache 2.0 licence, it was written in Node and developed in public, and it was popular enough that Google merged more than six thousand pull requests from contributors outside the company.

At Google I/O on 19 May 2026 the company announced that it was consolidating its developer tooling under the Antigravity brand and retiring the standalone Gemini CLI, and on 18 June, thirty days later, the old tool stopped serving requests. Its replacement, Antigravity CLI, is closed source and written in Go.

It is worth reading that sequence again with the contributors in mind, because six thousand accepted pull requests represents an enormous quantity of donated labour: people fixing bugs in evenings, adding the one integration their team needed, writing the documentation that was missing when they arrived. All of it was given to a repository under a licence that permitted exactly what subsequently happened. Nothing improper occurred, the licence was honoured throughout, and the code remains available to fork just as Apache 2.0 guarantees, though forking a tool whose server side has been switched off is a thinner consolation than it sounds when described that way.

The lesson is not that Google behaved badly, because by any reasonable reading it did not. The lesson is that an open licence on a component controlled by a single company is a statement about the past rather than a commitment about the future. It tells you what you may lawfully do with the code already in your possession. It tells you nothing about whether the thing continues to be built, continues to be served, or continues to be the thing your organisation standardised on two years ago, and openness maintained at one company's discretion is simply a roadmap decision that company remains free to take on your behalf. Thirty days is how much notice you might get when it does.

Anyone selecting infrastructure they intend to hold for a decade should treat that as the central fact of the past year rather than a footnote about one retired command-line tool.

The last time, it was API gateways

None of this is unprecedented, which ought to be reassuring and mostly is not. The industry ran a version of the same experiment with ordinary API gateways, and the results were documented thoroughly enough to learn from.

API gateways began life as independent infrastructure and were steadily absorbed into adjacent platforms, first application servers, then integration suites, cloud provider bundles and API management products. Absorption was attractive for precisely the reasons it is attractive now, in that the bundled option was cheaper, already procured and integrated with things the team was using anyway, and each individual decision to take it looked sensible on the day it was taken.

The cost arrived later and arrived as accumulation rather than as any single event. Proprietary configuration formats, platform-specific plugins and policy written in a vendor's own dialect and stored in a vendor's own database piled up over years, each addition reasonable in isolation and the whole collectively immovable. Teams that eventually needed independent control of their traffic layer, because they had gone multi-cloud or acquired a company or simply outgrown the platform they started on, discovered that the gateway had quietly become the most expensive thing in the estate to replace. The remedies the industry converged on afterwards are the instructive part: open standards for configuration, and a control plane kept deliberately independent of the data plane, so that the layer expressing policy could outlive changes to the layer enforcing it.

The AI gateway is on the same path at roughly the same stage, with the stakes raised, because what passes through it is not request metadata. It is an organisation's confidential context and the actions its agents take on the organisation's behalf.

Structure, not promises

The answer to all of this is not to refuse the platforms, which would be both impractical and slightly silly. Their native tooling is frequently the best available, Google's evaluation and simulation work being a fair example, and an organisation that turns it down on principle has made itself poorer for no corresponding gain. The narrower and more durable answer is to keep the control point independent of every party it governs, which requires building independence out of something more substantial than a promise.

The clearest test is whether the party operating the gateway also sells you what it governs. Where it sells the models, the cloud, the hardware or the security estate that the gateway sits in front of, neutrality is being asked to survive a permanent structural conflict, which is a great deal to ask of anybody's good intentions over a ten-year horizon. An open licence helps here, and governance by a foundation helps considerably more, since it means openness does not rest on one company's continued goodwill, which is the lesson of Gemini CLI applied rather than merely noted.

A second test concerns the seams. Model access, tool calls, agent-to-agent traffic, identity and telemetry all now have open specifications under neutral stewardship, several of them contributed by the very platform vendors whose embedding is at issue, and where a gateway genuinely rides those standards its components can be replaced one at a time. Where it terminates them and substitutes something proprietary underneath, the standard has become a line in a datasheet.

The third is whether the gateway will govern the platforms themselves, including their own agent frameworks, running unmodified. A gateway that governs everything except the stacks its owner happens to sell is expressing a preference rather than performing governance.

The fourth is whether it runs where the data actually lives, meaning self-hosted, at the edge, in hybrid arrangements and disconnected, and then the more searching version of the same question, which is whether enforcement continues to hold when the control plane is unreachable. Governance that evaporates the moment connectivity does was never a guarantee in the first place; it was a feature flag with confident branding.

The fifth is whether the thing produces evidence rather than logs. Regulators do not ask what a gateway could have blocked in principle. They ask an organisation to demonstrate what it did, mapped to a framework and attributable to a particular agent, and evidence generated by the enforcement layer itself is a different artefact from a log somebody interprets afterwards. With the European Union's AI Act obligations arriving through 2026, that distinction has stopped being academic.

We build towards those five tests, so the list is plainly an interested party's account of what matters. The tests themselves can be applied to any vendor, including us, which is the reason for writing them down rather than asserting a conclusion.

When our interests diverge

There is one question worth putting to anybody selling this layer, and its value lies in the shape of the answer rather than its content. What happens when my interests and your platform's interests diverge?

An embedded gateway has no good answer available, and not because the people working on it are cynical. The question simply describes the arrangement accurately: divergence gets resolved in the platform's favour, because the gateway exists in order to make the platform more valuable, and that is what embedding means. The honest reply would be that it will not be resolved in the customer's favour, and no vendor is going to say that out loud in a procurement meeting.

An independent gateway can answer structurally instead. The customer can hold it, read it, fork it, self-host it or leave, and the governance continues to work across all of those outcomes, because none of them depend on the vendor's continued cooperation. That answer does not require trusting anybody, which is the only kind of answer worth having about infrastructure meant to last a decade.

The consolidation of the past year was, in its way, a compliment to the category. The largest companies in security, cloud, productivity and silicon each worked out independently that whoever holds the AI gateway holds the account, and their unanimity on that point is the most useful evidence available about how much the layer matters. It is also the reason it should not belong to any of them.

Footnotes

  1. Throughput figures for this gateway vary considerably depending on who is quoting them and when. Portkey's own announcement in March cited more than a trillion tokens a day, some trade coverage put it at two trillion, and Palo Alto's July release described sixty-eight trillion tokens in the preceding month across the combined platform. The figures are not directly comparable and none of them is independently audited, so they are useful for establishing scale and not much else. ↩

  2. The note is First Take: Palo Alto Network's Portkey Deal Signals the Importance of AI Gateways, dated 1 May 2026 and available to Gartner clients only. The guidance is paraphrased here from the industry commentary summarising it rather than quoted, since the original could not be verified directly. Gartner's related published research on the category includes its Market Guide for AI Gateways and a later Market Overview, both also subscription-only. ↩