Stop Blindly Trusting AI Providers: Two Verifiable Alternatives

When you call a hosted LLM, you're unconditionally trusting two things you can't verify yourself.

First, the model listed on your invoice may not be the one actually answering you. A provider can quietly swap in a smaller quantized version or a cheaper distilled model under the same name, and you'd never know. Your Agent slowly degrades in performance, and you end up blaming your own prompts.

Second, where your prompt actually goes. Most gateways hand you a privacy policy — and a policy is a promise about what a company says it will do, not a technical constraint on what it can do.

For anyone delegating more and more tasks to personal AI Agents, the cost of these two blind spots grows with every layer of trust you extend. Two Bittensor subnets each target one of these problems: Engy (SN53) and SayGM (SN28). They solve different things, so let's break down how each works and where it fits.

Engy: Prove the Model You're Paying For Is the One Actually Running

Engy is an OpenAI-compatible inference API serving frontier open-weight models including GLM, Kimi, DeepSeek^Ad, and Qwen. Its core value proposition is verifiability.

According to the project documentation, each model's weights and quantization scheme are committed to a public Merkle root. Every response carries a TOPLOC proof — a compact fingerprint of the model's internal activations. Validator nodes re-compute these proofs by sampling and compare them against the committed checkpoint; miners that fail verification are penalized.

The project README puts it plainly: "No TEE required, no trusted hardware required. The proof locks in the math, not the machine." This is what allows Engy to serve inference across a permissionless compute cluster — including consumer-grade GPUs — without requiring you to trust whoever owns those GPUs.

Engy also claims zero data retention by default for all accounts.

---

Merkle root comes from a cryptographic data structure called a Merkle tree. A Merkle tree takes a large set of data blocks, hashes them pairwise layer by layer, and produces a single fixed-length root hash — the Merkle root. If any single block is modified, the root hash changes completely and cannot be forged. Using this to "commit" to model weights means computing a publicly verifiable fingerprint across all model parameter files. If a different version is running, the fingerprint won't match — tampering has nowhere to hide.

TOPLOC proof is a lightweight integrity proof technique designed specifically for LLM inference. The core idea: during a forward pass, compute compact commitments over the intermediate activations at select layers. Since a given input on a given model produces deterministic activations, a verifier only needs to recompute local activations for the same batch of tokens to determine whether the provider ran the claimed model — no need to replay the entire inference. This is much harder to game than simple output comparison: it's not hard to produce similar outputs with a smaller model, but fabricating intermediate layer activation fingerprints is a different matter entirely.

---

SayGM: A Gateway Where Even the Operator Can't Read Your Requests

SayGM is a drop-in gateway supporting Claude, GPT, Gemini, and a range of open-source models. It exposes all three API formats — OpenAI-compatible, native Anthropic, and native Gemini — so most existing code only needs a new base_url and key to connect.

The key is its execution environment: the gateway runs inside an Intel TDX Trusted Execution Environment (TEE). TLS terminates inside the enclave, meaning routing and guardrail logic happens in a place that SayGM's own operators and the host machine cannot read. The gateway also exposes a remote attestation endpoint, so this claim comes with hardware-signed evidence rather than just a page of policy text.

Two tiers are worth understanding:

• Frontier models (Claude, GPT, Gemini): Requests are sealed through the gateway, then handled by the model provider under their own API terms — identical to calling them directly.
• Confidential models (with -tee suffix, e.g. kimi-k3-tee): Open-weight models also run inside the TEE, so the prompt remains sealed end-to-end.

On pricing, rates are published in real time via a machine-readable model catalog, capped at or below the model vendors' list prices. SayGM's own OpenRouter comparison page shows average savings of roughly 29% across the nine models it compares, after accounting for OpenRouter's 5.5% top-up fee. Note this is SayGM's own comparison data, not independently verified; savings vary by model, and some models in the catalog may be priced higher than OpenRouter.

---

Trusted Execution Environment (TEE) is an isolated region that CPU vendors carve out at the hardware level, called an "enclave." Code and data inside the enclave are invisible to the OS, hypervisor, and even the physical server owner during execution — root access doesn't help you read its memory. Intel TDX (Trust Domain Extensions) is Intel's next-generation confidential computing technology for cloud deployments, operating at the granularity of an entire virtual machine — better suited than the earlier SGX for running a full application stack.

Remote Attestation is the companion mechanism to TEE: the enclave can provide an external requestor with a report signed by the CPU's hardware private key, proving "this code is genuinely running inside a TEE on this chip model, and the running code has hash X." This report can be verified through Intel's certificate chain, replacing "trust the provider's word" with "verify hardware-signed cryptographic evidence." TLS terminating inside the enclave means HTTPS decryption also happens in that invisible isolated region — the host layer where the gateway operator sits only ever sees ciphertext.

---

Which One to Use, and When

These two tools don't compete — one proves what ran, the other restricts who can see the request. Here's a practical decision guide:

• You need to know exactly which open-source model answered — for benchmarking, long-running Agents, or any scenario where a silent model swap ruins results — use Engy.
• You need Claude, GPT, or Gemini, but want the routing layer sealed — use SayGM.
• You want open-weight models with the strongest privacy guarantees — use SayGM's -tee models.
• You want cheap, verifiable open-source model tokens for background Agent work — use Engy.

Minimal Integration Code

Both work with the standard OpenAI Python SDK — just swap base_url, key, and model name.

Engy:

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://api.engy.ai/v1",
    api_key=os.environ["ENGY_API_KEY"],
)

resp = client.chat.completions.create(
    model="glm-5.2",
    messages=[{"role": "user", "content": "hello"}],
)
print(resp.choices[0].message.content)

SayGM:

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://api.saygm.com/v1",
    api_key=os.environ["GM_API_KEY"],
)

resp = client.chat.completions.create(
    model="kimi-k3-tee",  # Confidential tier: end-to-end TEE
    messages=[{"role": "user", "content": "hello"}],
)
print(resp.choices[0].message.content)

Note that on SayGM, model IDs carry no provider prefix. Claude models use Anthropic's native /v1/messages endpoint, so calling them requires the Anthropic SDK. GET /v1/models will tell you the tier for each model and which API shapes it supports.

Limitations and Trade-offs: Neither Actually Eliminates Trust

Be clear-eyed about this: neither solution eliminates trust — they redirect it to places you can at least partially verify.

Engy's limitations:

• Verification is sampling-based and probabilistic — the project openly acknowledges this. It is not a complete proof of every forward pass. Stronger re-computation auditing is being layered on top of fingerprint checks incrementally.
• As a buyer, you don't verify the proof yourself on every call. During the current stabilization phase, the primary verification is handled by Engy's GPU-backed validator nodes.
• It only supports open-weight models. If you need Claude or GPT, this tool doesn't apply.
• Verification proves which model ran — it is not a privacy guarantee. For data privacy you still rely on the zero-retention policy.

SayGM's limitations:

• For frontier models, the provider (Anthropic, OpenAI, Google) still sees your prompt in plaintext. SayGM is transparent about this — the sealing covers the gateway, not the model provider.
• Documentation notes that lower-level attestation verification tooling is still being prepared for general buyer use. You can retrieve an attestation now, but self-verifying it requires some TDX expertise.
• The catalog is curated (tens of models, not hundreds). If you need niche models, larger aggregators still have a role.
• TEE shifts trust to the hardware vendor. That's significantly better than a page of policy text, but it's still a form of trust.

Conclusion: A Receipt You Can Actually Check

Neither is perfect, but both swap "trust us" for something you can inspect: a proof bound to public weights, or a chip-signed attestation. As the framing goes, a model that can't show its work is just "a rumor with a keyboard." For Agents that run unattended and handle personal data, having a verifiable receipt is what matters — trust can be extended, but a good captain always checks for themselves.