Confidential computing is the answer the industry has settled on for enterprises that need to keep their data out of frontier labs like OpenAI, Anthropic or Google DeepMind. Across providers, the proposition is much the same: the workload runs inside a hardware-isolated environment, its memory remains encrypted during inference, and even the company operating the machine cannot see the data passing through it. The processor enforces that isolation, and in most implementations the technology delivers what is promised. The more important question is how a customer verifies that it did.
In most confidential computing deployments, the company running the infrastructure is also the company checking the evidence that the infrastructure behaved as described. The provider attests, the provider verifies its own attestation, and the customer is left accepting the verdict. That works for a startup moving quickly on data nobody will ask about later. A bank cannot build a control around it, because compliance programs written against GDPR, HIPAA or SOC 2 rest on evidence an outside party can inspect and an auditor can put in a file.
That gap explains most of where enterprise AI has stalled.
Why enterprises keep proprietary data out of AI systems
The typical adoption pattern inside regulated firms is broad and shallow. Employee assistants are everywhere, along with summarization, coding help and analysis of public market data, and the productivity case for all of it is settled at this point. The boundary appears when you ask which data those systems are permitted to touch. What gets processed is what is not proprietary, so trading logic, client portfolios, underwriting models, clinical records and the accumulated institutional knowledge that makes one firm worth more than its competitors all stay behind the firewall, which is where most of the value would have come from.
The approval process holds that boundary in place. Getting a single model through a large enterprise risk assessment takes six months to a year. Releases ship in weeks, so the system that finally clears review has usually been superseded twice. Most of that year goes to committees arguing about what could go wrong with no way to settle it, because the provider's answer to the central question is a contract clause, and a clause cannot be tested.
The cost of self-hosting open-weight models
Faced with that, a lot of firms have stopped waiting. What happens most often among organizations that are not comfortable entrusting their data to a frontier lab is that they stand up their own inference infrastructure inside their own cloud account and run open-weight models they control end to end.
What that means is that the firm reserves or buys GPU capacity and then keeps it utilized. It hires people who can serve and monitor a model in production. It builds an evaluation harness, because without one there is no way to tell whether a model upgrade improved anything. It puts retrieval, orchestration and logging around the model, runs a security review across the whole stack, and staffs someone to be on call when inference goes down at two in the morning. At the end of that, it is running an open-weight model that trails the frontier by some margin on most tasks.
Every line of that is a substitute for a guarantee the firm could not buy. What it purchases in return is the knowledge of who could read the data, and I do not think many of these deployments would exist if an infrastructure provider could sell the same certainty with evidence attached. The bill enterprises are already absorbing is the closest thing we have to a market price on verifiable confidentiality.
What cloud adoption in regulated industries got right
When I was at State Street in the mid-2010s, shared infrastructure was practically unthinkable for a systemically important bank, and even years later regulated institutions were still hesitant about public cloud for reasons that will sound familiar. Data compliance. Confidentiality. Intellectual property. Nobody could establish with any confidence who else might reach the data once it left the building.
Fast forward to today and cloud is now the default for those same institutions, and it won on evidence. Controls became auditable, third-party certifications carried real weight with examiners, and a bank could eventually demonstrate more assurance against compromise in a cloud environment than it could in its own data centers.
The adoption curve carries over, but often the controls do not. Access control lists, retention policies and database permissions were designed for data sitting still in a known place under a known owner, and running a model over that data changes what needs to be shown. Where did the data go, who is accountable for the decision the system produced, and what can either party demonstrate about it a year later when a supervisor asks? A permissions matrix has nothing useful to say about any of that.
Four requirements for a confidential AI provider
Regulated industries do not take a service provider's word that its controls work. An independent auditor tests them, issues a report, and the report is what goes to the regulator. Every major outsourcing relationship in financial services runs on some version of that arrangement, and it works because the party making the claim and the party checking it are different parties with different incentives.
Confidential computing has the technical half of that already and has been missing the independent half. So the useful question for an enterprise evaluating an inference provider is whether the provider's setup reaches the same evidentiary standard the rest of its stack already meets. These are the four things I would ask a provider to demonstrate:
- Hardware isolation that shuts out the operator. The workload runs inside a confidential virtual machine with encrypted memory. The host operating system, the GPU operator and the inference provider itself are excluded by the silicon instead of by policy.
- A verifier independent of the operator. Someone who does not run the workload checks the attestation. Intel Trust Authority offers this as a service, appraising the environment against Intel's own reference values and issuing a signed token that records its verdict, so the chain of trust ends at the company that makes the chip doing the enforcing. NEAR AI Cloud put this into production in August 2026, and it is the clearest example of the separation working, with the provider running the workload, Intel verifying it independently, and customers including Brave, Venice AI and the Government of Bermuda able to check both.
- Raw evidence published, not summarized. A customer or an auditor should be able to examine the underlying measurements directly instead of reading the provider's assurance that everything checked out.
- An output other systems can act on. A signed attestation token is machine-readable, which means a key management system can be configured to release decryption keys only when a valid one is present, an access platform can gate workloads on it, and a compliance team can hand an auditor third-party evidence in place of a provider self-assessment.
An attestation establishes that the workload ran inside a genuine, unmodified environment its operator could not read, but it doesn't determine whether the model is any good, whether the prompt was sensible, or what an application does with the output once inference is finished. It answers where the computation happened and who could see it, and those two questions gate the others, which is why I expect them to be solved first.
Where confidential compute ends and agent custody begins
Once those agents start moving money, a second set of questions opens up. Who holds the signing authority, what is the agent permitted to do with it, and how does a human take control back when something breaks? I have written about custody and policy enforcement as separate engineering problems, and they are genuinely separate. But they arrive at the same procurement desk, from the same buyer, on the same timeline.
That buyer will ultimately need evidence across the entire chain: proof of where the agent computed, controls over what it was authorized to do, and a record of what it actually did. That is why I expect confidential compute, custody and policy enforcement to be evaluated together even if they remain distinct parts of the stack.
The question I would ask a provider
Who checks the attestation?
If the provider checks its own work, what is on offer is still a promise, however good the engineering behind it may be. Enterprises have spent the last few years declining to buy promises where their most sensitive data is concerned.
Independent attestation is available today, but most inference providers have not adopted it, partly because their customers have not learned to ask for it yet. The pressure will start with buyers that have to prove something to somebody else.
Banks and regulators across Europe, the Middle East and Asia have begun piloting quantum-safe wallet generation and transfers on a NEAR testnet alongside the Responsible Fintech Institute and Safeheron. In that work, the focus is signing rather than confidential inference, but the buyers are the same: institutions that need to demonstrate how their infrastructure works to the supervisors evaluating it alongside them.
Those buyers cannot build a control around a provider's assurance alone. They need evidence that can survive internal review, external audit and a supervisor's questions. Asking a bank to take a provider's word for something it must independently demonstrate has never worked anywhere else in its stack, and I see no reason AI will be the exception.
overview
