Verified AI Is All You Need: The Case for Private, User-Owned AI

Two Futures of AI

It’s June 12, 2026. You decide to progress on your AI small business hustle focused on a niche agentic workflow. You fire up your paid subscription AI tools and are met with the following message:

The latest frontier model has been restricted by the government.¹ Later that month, you find that Anthropic will allow gated access to a select group of enterprise institutions. At a time when the speed of developing your niche workflow is most critical, the enterprise AI labs, known for absorbing niche workflows into general frontier model knowledge, just got an 18-day head start with the premium model.

As with many restrictions throughout history, we were offered safety as the reason. Claims spread that the new Mythos model could surface vulnerabilities in fundamental, widely-deployed systems. If true and well intentioned, restrictions would be a reasonable course of action. In opposition, accusations of overemphasized safety fears and Anthropic IPO incentives became a topic of discussion.

I can’t help but wonder how many Opus-powered chat windows analyzed Mythos-crafted PR statements during this particular season of controversy.

With the self-awareness of not having access to all information available on the topic, one’s still left to weigh the multiple truths on the ground:

Foundational and widespread software systems likely did need patches before Mythos was openly released.
Smaller businesses and labs who also needed patches were not given the chance.
A precedent for gatekeeping one of the most transformative technologies in ages was potentially set.
A government body, absent clear policy, made the call unilaterally.

Absent all of the other commentary, these truths raise questions like:

“Who decides who gets to use frontier models?” “Would an AI lab ever use ‘safety’ as an excuse to gatekeep for its own benefit?” “Who decides what ‘guardrails’ and biases go into various models' framing of the ‘truth’?”

The metaphorical battlegrounds of centralized versus decentralized power structures stretch far and wide. In the world of AI, two hues of solution are undergoing beta testing in real-time when it comes to safety, access, training, ownership, and transparency. Should a hopefully noble, centralized structure dictate AI practices, or should we default to decentralized, user-owned mechanisms? Or some combination of both?

Whichever side of that debate you fall on, it’s crucial to look the current AI trajectory squarely in the face, consider the historical context of transformative technologies and privacy, and responsibly weigh all options.

After all, it’s always good to have options.

Trust, Privacy, and Centralized AI Inference

Take a moment and consider your AI chat history. This morning you may have discussed retirement planning and analyzed salary, auto, insurance, tax, and spending information. You may have written code. A PDF of a contract or statement may have been uploaded. An email read and responded to. A unique business idea you've never told anyone about, workshopped and tightened.

None of it felt like a decision. Every request left your machine, traveled to a server you’ll never see, and was processed by software you’ll never inspect. By default.

On the heels of similar concerns with SaaS and social media, it’s fair to ask: how do you know the AI provider won’t sell your data, expose it to other users, or play the part of a less-than-enterprise-hardened custodian?

Is My Data Private When Using AI?

At the consumer tier, AI companies often use the data you input. At the enterprise and API tier, they promise not to, by contract.

AI data promises particularly matter when considering how AI models get built: expensive compute and repeated exposure to enormous amounts of inputs until output prediction starts to resemble reasoning. Most frontier models we know today were trained on the open internet. With breadth now largely covered, depth has become the new frontier for training.

Is your domain expertise the valuable depth AI models need to train?

Of course, training is only one driver of the AI data discussion. Your data could be retained longer than stated. It could be exposed in a breach. It could be subpoenaed. It could be read by an AI provider employee or the provider’s AI inference tools. It could be handed to an advertiser. It could be sold with the company or governed by a policy that changes from year to year.

I think most of the premier AI providers are nobly attempting to grow the AI frontier while keeping humanity’s collective best interests at the forefront of every decision. Nonetheless, notice what all of the above suboptimal scenarios have in common. It's not malice, bad faith, or likelihood.

Users cannot check on any of them.

And enterprises can't check either. If well-funded, they can negotiate better terms, demand more audits, and hire people to read the fine print, but every one of those is a stronger promise. And as a practical matter, a promise is only worth whatever it costs to enforce. Contracts assume a counterparty willing to spend years and millions litigating a thing they can't observe in the first place.

It’s fair to point out: this is how business has always worked to some degree. Policy over proof serves as the standard for many companies that, with enough vetting, choose to trust banks, lawyers, cloud providers, etc, based on a mix of reputation and terms of service.

Another historical advantage of large technology providers is in economies of scale. When companies earn the trust of a substantial portion of the market, they generate the revenue to scale operations until their training and inference costs are hard to compete with. The catch is that those savings at scale don’t benefit the AI end user at all unless they’re passed along rather than captured as margin. A decentralized market tends to pass along that savings due to competition. Centralized entities often have the option to bank the profit margin.

In many ways, trust-based policy made a lot of sense when business and data moved at the speed of humans. But does it make sense in a world of AI agents? In a world where advances in cryptography and encryption mechanisms offer proof as the default option?

You Already Live in a Verified World

Absent competing incentives, the appeal is obvious: consider a world where one knows their data and AI inference are user-owned, secure, cost-effective, and censorship-resistant without having to trust a counterparty they can’t formally verify.

In fact, we already use verified systems by default dozens of times a day. When you visit your bank's website or app, you're not asked to trust that you're interacting with your bank's servers. SSL/TLS runs a handshake that cryptographically verifies the bank's certificate was signed by a trusted Certificate Authority, establishes a shared session key, and encrypts the data that follows for private transmission and provable integrity.² This is the default that would be considered negligence to roll back.

The same verification governs the software we run. When developers install packages through uv/pip, cargo, npm, and similar ecosystems, the tooling checks the package downloaded against the hash of the content signed by the provider. A file changed or altered in transit by a bad mirror or man-in-the-middle attack would result in a different hash and fail to install. Your devices and operating systems apply the same default verification by refusing to run, or warning before running, executables that aren't signed by reputable developers. The Google and Apple app stores don’t just promise they’re delivering and running the real financial, social media, or photo app on your phone. It’s verified by default and would be considered negligence not to do so.

Another example likely sits in your pocket right now. Your phone contains a secure enclave, a small trusted execution environment purposefully walled off from the main processor, running its own microkernel and encrypted memory.³ When you use Face ID, a mathematical representation of your face is stored in and only made available to the enclave. The data never leaves the device, never gets sent to Apple, and is never included in device backups.⁴ Neither the phone operating system nor the apps running on it can view the data or use it.

The enclave works with your sensitive data and processes a helpful result without giving away all of the data: match or no match. If you own a smartphone, you’ve already been relying on hardware to protect your most sensitive data without having to trust that your device isn’t misusing it. A hardware isolated environment provides verified privacy and user-ownership. Again, it’s the default and would be considered negligence to treat differently.

Are we to believe that virtually every layer of our digital lives should follow a verification-by-default principle except the most sensitive data being shared with AI?

To the contrary, verified AI follows as the natural expectation.

Trusted Execution Environments (TEEs): The AI Verification Primitive

That enclave in your phone has a general name: a trusted execution environment (TEE). As mentioned previously, a TEE is an isolated section of the hardware running its own encrypted memory. It’s sealed off so completely that the operating system, hypervisor, admin with root access, and even the physical owner of the machine cannot see what happens inside.⁵ When you give a TEE sensitive work, it can output valuable results without letting the parties supplying the input or hardware owners access sensitive data.

Face ID and fingerprint scanners have done this for a decade. Why not run AI inference this way? This is exactly where the most innovative spaces within trusted AI are moving.

Remote attestation explained

What makes TEEs more than a locked box is a concept called remote attestation. On startup, the environment essentially measures itself by hashing the exact code it will run and then signing that measurement with a key chain rooted in a private key fused into the silicon when manufactured.⁶ Like the secure enclave, the key never leaves the hardware.

Anyone can ask the TEE for a signed report that, in effect, shows the exact software code running and cryptographic proof that the code is being run on that particular, genuine hardware. If a single byte of the code is swapped, the cryptographic hash would change completely and the measurement would not match. It’s essentially SSL for computation. A package hash for running inference. A secure enclave for AI. Proof, verified by default, yet again.

Getting this to work under the performance constraints necessary to run AI inference models at scale was the missing piece that arrived more recently. CPU TEEs existed for years, but AI runs on GPUs, and until the current generation of GPUs there was no equivalent protection. Beginning with the likes of NVIDIA’s H100 GPUs, hardware isolation could finally extend to the GPU itself.⁷ In practice the two halves chain together: an Intel TDX confidential virtual machine establishes trust and manages a secure channel to the GPU and the GPU produces its own signed attestation of firmware and state.⁸ Verifying both means verifying an unbroken chain from the CPU that received the request to the silicon that processed it. The data is encrypted as it moves between them and decrypted only inside the verified GPU. It’s never visible to the host, data center, or provider.

It's also worth noting that verified compute isn't a new AI-specific concept. It’s a general primitive that, due to advances in GPU, arrived on the AI scene relatively recently. The same hardware protects payment credentials, DRM media, hospital patient data, and countless sets of sensitive data across fields.

Confidential AI inference is just the most pressing and overdue application of a secure and verified world.

Drawbacks to TEEs

Though a highly practical solution, TEEs are not perfect and it’s worth mentioning a few of the cracks that researchers have found to date. In late 2025, researchers from Georgia Tech and Purdue demonstrated an attack that could pull cryptographic keys straight off DDR5 memory and forge remote attestations that passed verification.⁹ The meaningful catch is that the exploit requires soldering a custom device onto the memory bus of servers. Worth noting beyond this specific exploit is that a TEE still roots its trust in Intel's and NVIDIA's silicon and key infrastructure. A TEE moves trust to the hardware rather than eliminating it. That’s a real threat from a data-center adversary, but close to irrelevant to the everyday questions of user-owned AI and privacy as a matter of comparison to the industry’s current approach.

Moving to a more secure landscape is still a huge win compared to the current status quo. It would seem unwise to settle for zero-verification because one cannot have perfect verification. Compared to a policy you cannot inspect, a proof that requires an adversary to physically alter a server is a categorically better place to stand.

Purely cryptographic alternatives (like fully homomorphic encryption or multiparty computation) need no trusted hardware, but at the current moment they're far too slow and expensive to run AI workloads.

The wise path is to take the iterative win and go from there.

What Verified AI Inference Looks Like Today

None of this is theoretical. This is happening right now in the AI world. Standard AI models are running with provable privacy inside TEEs without modification, and the performance cost runs under 5% for typical queries, approaching zero for larger models and longer sequences, rather than the orders of magnitude of difference that make other privacy approaches less tenable.¹⁰ Verifiability and capability now coexist by simply proving what hardware was being used and software was already being run.

Near AI, co-founded by Illia Polosukhin, one of the original Google authors of the transformer paper 'Attention Is All You Need,' is one of a variety of providers building AI inference services on TEE infrastructure today.¹¹ It runs open models inside Intel TDX confidential VMs paired with NVIDIA H200 confidential GPUs, with every response carrying a hardware attestation that binds the exact hardware, model, and code that was run. You can check that attestation yourself against their open verifier, rather than taking anyone's word for it.

You can interact with your own user-owned AI agent via agent.near.ai (I hooked up a gentlemanly Telegram bot named Bast to my agent) for a personal assistant that keeps the data in your hands.

Or you can interact with user-owned AI directly with prompts through private.near.ai, which provides a familiar looking chat interface.

Like other services abstracting away models from the harnesses, it also allows choice of model and uses the same API interface as everyone else, so adopting it is close to a non-event. You change a base URL, keep your existing code, and pick a model from the catalog. Another neat feature is that you can also use closed AI models and the service will redact personally identifiable information (PII), if you want to take a more modest iterative step towards user-owned AI.

Near AI is but one example of the directional move towards verifiable AI and data sovereignty. Phala and others are building on the same open, confidential-inference stack to reach for the same future.

The Future Should Be Verifiable

The point isn’t for every AI request to move away from centralized providers tomorrow, or that companies like Anthropic and OpenAI have no place. Labs are crucial to the success of new LLM models, expansive orchestration, and pushing forth the frontier. But lack of data verification should be a choice rather than a default or a prerequisite.

User-owned AI can and will arrive without asking users to run their own hardware or maintain a zero trust posture. But users should be able to choose the models they use, shop for cost, control the data and memory surrounding those models, and change inference providers without surrendering ownership of their digital life. Open-weight models and competitive inference market portability can make it affordable. Trusted execution environments and other future breakthroughs in user-owned AI can make the promises surrounding AI inference verifiable.

That becomes especially important as AI evolves from isolated chat windows into persistent agents used for tasks throughout one’s day-to-day. An agent will eventually understand your email, calendar, finances, health information, private conversations, business relationships, credentials, and years of accumulated memories. The more useful AI systems become, the more complete the picture of users becomes. In turn, the less reasonable it becomes to secure the digital life of the user with a privacy policy alone.

Users should be able to ask: Which model answered this? Where did it run? Who could see the request? What code handled it? Can any of that be proven?

Near AI, Phala, and the broader confidential-compute ecosystem are early answers to those questions, albeit not perfect. TEEs will improve. New vulnerabilities will be discovered. Cryptographic alternatives may eventually become practical. The specific providers and technical architectures will change.

The important thing is establishing the expectation now that AI should not permanently remain a black box operated behind somebody else’s policy.

We already verify the websites we visit, the software we install, the applications running on our phones, and the hardware protecting our identities. Applying the same principles to AI inference isn’t a radical departure, but rather a natural continuation of how secure digital systems have always matured.

Verified compute may not solve every problem surrounding AI ownership, access, cost, or control. But it changes the foundational question from “Do you trust us?” to “Would you like to verify?”

That is the much better foundation on which to build user-owned AI.

“Statement on the US government directive to suspend access to Fable 5 and Mythos 5.” Accessed: Jul. 24, 2026. [Online]. Available: https://www.anthropic.com/news/fable-mythos-access ↩
E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.3,” Internet Engineering Task Force, Request for Comments RFC 8446, Aug. 2018. doi: 10.17487/RFC8446. ↩
“The Secure Enclave,” Apple Support. Accessed: Jul. 24, 2026. [Online]. Available: https://support.apple.com/guide/security/the-secure-enclave-sec59b0b31ff/web ↩
“Facial matching security,” Apple Support. Accessed: Jul. 24, 2026. [Online]. Available: https://support.apple.com/guide/security/facial-matching-security-sece151358d1/web ↩
V. Costan and S. Devadas, “Intel SGX Explained,” 2016, 2016/086. Accessed: Jul. 24, 2026. [Online]. Available: https://eprint.iacr.org/2016/086 ↩
J. Ménétrey et al., “Attestation Mechanisms for Trusted Execution Environments Demystified,” vol. 13272, 2022, pp. 95–113. doi: 10.1007/978-3-031-16092-9_7. ↩
I. rangel Says, “Confidential Computing on NVIDIA H100 GPUs for Secure and Trustworthy AI,” NVIDIA Technical Blog. Accessed: Jul. 24, 2026. [Online]. Available: https://developer.nvidia.com/blog/confidential-computing-on-h100-gpus-for-secure-and-trustworthy-ai/ ↩
P.-C. Cheng et al., “Intel TDX Demystified: A Top-Down Approach,” Mar. 27, 2023, arXiv: arXiv:2303.15540. doi: 10.48550/arXiv.2303.15540. ↩
“TEE.fail: Breaking Trusted Execution Environments via DDR5 Memory Bus Interposition.” Accessed: Jul. 24, 2026. [Online]. Available: https://tee.fail ↩
J. Zhu, H. Yin, P. Deng, A. Almeida, and S. Zhou, “Confidential Computing on NVIDIA Hopper GPUs: A Performance Benchmark Study,” Nov. 05, 2024, arXiv: arXiv:2409.03992. doi: 10.48550/arXiv.2409.03992. ↩
A. Vaswani et al., “Attention Is All You Need,” Aug. 02, 2023, arXiv: arXiv:1706.03762. doi: 10.48550/arXiv.1706.03762. ↩