Privacy Proof

Where your prompt goes, and who can see it.

ApexOne lets you verify instead of trust. The entire service runs inside a single hardware-protected confidential computer, running open-source code pinned to an exact version — and your own browser can confirm that, right now, against chip-maker Intel’s root of trust. This page explains, in plain language, what we prove, what we deliberately don’t claim, and how you can check it yourself in one click.

Verify right now

Tip

Open apex1.us/proof — the page runs the verification in your own browser automatically. Green check marks mean it passed.

In one line

Only two places ever see your prompt in the clear:

Inside ApexOne's confidential computer

One hardware-protected Intel TDX confidential VM — memory-encrypted, and not even our own operators can look inside it or change the code it runs.

The upstream model provider, at the very end

Because it actually runs the model, it sees the plaintext under its own privacy policy. We state this honestly, without hiding it.

Beyond those two, the network and every middle step handle only ciphertext.

Our promise (and the honest limits)

What we guarantee

Between your device and the upstream model provider, no middle step can read your prompt — including us, the ApexOne operator. And you don’t have to take that on faith: the code running inside the confidential computer is public, and its fingerprint is signed by Intel hardware.

What we don't overstate

• The upstream model provider sees your plaintext. A request routed to Claude, GPT or any other hosted model must ultimately reach that provider in the clear, handled under their privacy policy. We never claim confidentiality from the model provider.
• We do not claim “your model was not swapped.” Judge that by the replies you actually receive and by the evidence below.
• We do not claim we keep no records. ApexOne is a gateway: it maintains the usage and billing data any gateway needs. What the hardware proof establishes is which code is running — not a promise about what that code chooses to store. The code is public; read it.
• Some raw firmware registers have no published reference. The /proof page shows them and marks them explicitly as unverified rather than faking a comparison. The identity of the operating system image is instead anchored through a separate, fully checked measurement.

We spell out the scope precisely so that the part we can prove is genuinely trustworthy.

The journey your prompt takes

💻Your deviceyou type a prompt

🔒 encrypted→

🔒 ApexOne · Intel TDX confidential VMhardware-isolated · memory-encrypted · one enclave

🌐 ApexOne service
TLS ends here, inside

+

📜 Attestor
issues live hardware proof

⚠ plaintext→

🤖Upstream model providersees plaintext · its own policy

Step	What happens	What we can prove
1. Your device → ApexOne	Your connection is encrypted, and it is decrypted inside the confidential computer — the TLS private key is generated in the enclave and never leaves it, so there is no edge server outside the hardware boundary that could peek.	Genuine Intel TDX hardware + a code fingerprint confirming it runs exactly the public code. For a stronger check that doesn’t rely on TLS at all, use the end-to-end encryption test below.
2. ApexOne, inside the confidential computer	The whole service — request handling, routing to the model — runs in one hardware-isolated, memory-encrypted VM whose code neither the operator nor any middlebox can alter.	Code fingerprint → the exact public source version and the exact signed container images; the proof is bound to a one-time random number your browser just generated, so an old report can’t be replayed at you.
3. ApexOne → upstream model provider	Cannot be private: the provider decrypts and processes your plaintext under its own policy.	An honest note — not a confidentiality claim. We can only prove the request truly left from the attested confidential computer.

How to verify it yourself

≈ 30 seconds

1. Open apex1.us/proof.

2. The page automatically starts verifying in your browser — you’ll see the checks move from “Checking…” to a green “Verified”.

3. All green means: genuine Intel confidential hardware + running exactly the public, untampered code + a proof generated right now (not an old, replayed one).

The whole process runs in your own browser, with no reliance on our servers — it asks chip-maker Intel’s root of trust to confirm “this is genuine hardware, running that public code.” Press Re-verify anytime; the page draws a fresh one-time random number and checks again.

What each check proves

What you’ll see	Plain meaning
Attestation payload integrity	The hardware report arrived intact and well-formed.
Genuine Intel confidential hardware	Not an ordinary server pretending — a real chip, verified against Intel’s own certificate chain and revocation data.
One-time nonce binding	This proof was generated right now, for you: the random number your browser just made is baked into the hardware report.
Measurement log authenticity	The record of what was booted and launched is replayed and shown to match the hardware register — the log cannot have been edited afterwards.
Application identity	The deployment is the one we publish, not a look-alike.
Deployment fingerprint	It runs exactly the deployment we publish, not a single byte changed — checked twice, independently: once from the measurement log, once straight out of a hardware register.
OS image fingerprint	The operating system underneath is the published, unmodified image.
Encryption key binding	The public key you’d encrypt to is itself covered by the hardware proof — so “only the enclave can decrypt” is vouched for by Intel hardware, not by our word.
Raw firmware registers	Shown for completeness and marked informational: no published reference exists for them, so nothing is compared. We’d rather show the gap than fake a match.

Advanced: the live end-to-end encryption test

At the bottom of the /proof page there’s an optional live test that lets you see that the middle can’t read your prompt. Unlike the automatic verification, it makes a real inference request — so it needs an API key, a model, and a tiny amount of quota. Press Encrypt & round-trip once, and your browser will:

1. Encrypt your prompt locally into ciphertext that only that confidential computer’s hardware-attested key can open.

2. Send the ciphertext to the real inference endpoint, then decrypt the encrypted model reply that comes back.

3. Show you exactly what each party saw:

You, in your browser

👁 Plaintext — your prompt and the decrypted reply.

The middle (ApexOne's network path, any middlebox)

🚫 Only a blob of ciphertext, which cannot be recovered.

The confidential computer

🔓 Can decrypt — and only it can, which is why a real reply came back.

The reply decrypting and passing its integrity check proves that only the confidential computer holding the hardware-protected private key could open what you sent. This conclusion holds whether or not you trust the network encryption — and you can confirm it yourself: open your browser’s devtools, Network tab, and look at the request body. It contains nothing but ciphertext.

Before you try it

This demo prompt is decrypted inside the confidential computer and then, by design, forwarded in the clear to the upstream model provider (step 3), and it consumes a small amount of quota. Don’t paste anything sensitive. Your API key stays in your browser and is sent only to authorize that one request.

Check it independently

Don’t want to just take our word for it? You don’t have to. The apex1.us/proof page publishes the exact reference values (the “fingerprints”) for the current deployment and lets you — or any independent third party — compare them, line by line, against the hardware proof read live. If the values match, the running code really is the public, untampered code we claim.

Everything you need is on the /proof page itself:

• the current reference values — App ID, deployment fingerprint, OS image, source commit, and the exact container-image digests;
• direct links to the public source code (FiiLabs/sub2api), to the measured deployment file, and to the public build pipeline that produces cosign-signed images with SLSA provenance;
• a one-click download of the proof report, which you can re-check in an independent explorer such as proof.t16z.com;
• verification that runs against Intel’s own attestation data, not ours.

The reference values are not baked into the page — they are fetched live from a file in the public repository, so every change to them is public git history. That is deliberate: it means we cannot quietly move the goalposts after the fact.

Note

We keep the exact fingerprint values on the /proof page rather than in this guide on purpose: the verification method described here never changes, but the specific fingerprints do change every time we ship an update — and the page always shows the current ones. This guide stays valid; the page stays live.

FAQ

Does verifying use my data, my API key, or my credits?

It depends which of the two things on the page you mean:

• The automatic verification (runs by itself when the page opens) is read-only and free. It checks the hardware proof using only public data — it sends none of your content, uses no API key, and never touches your balance.
• The optional live encryption test (only runs when you press “Encrypt & round-trip once”) makes one real API call to prove the middle can’t read your prompt. Like any real request, it uses your API key and a tiny amount of credits (a fraction of a cent) — so if your balance dropped by a cent or two right after verifying, that was this test, not the automatic check. Your API key stays in your browser and is sent only to authorize that one request; we never store it.

What if verification shows “could not complete” or “failed”?

Press Re-verify and try again first — occasional network issues (for example Intel’s verification-data service being temporarily unreachable) produce “could not complete”, which is neither a pass nor a fail. If it keeps reporting an outright failure, do not trust that deployment and contact us.

Does this guarantee the model provider won’t see my content?

No, and we never claim it does. Any hosted model must be handed the plaintext to answer you. What we guarantee is that every middle step between your device and that provider handles only ciphertext.

Do I need to understand cryptography to verify?

No. Just open /proof and look for the green checks. The terminology and reference values are there for advanced users who want to dig deeper.

Note

This document describes the ApexOne production environment (apex1.us and api.apex1.us), which runs as a single Intel TDX confidential VM. Reference values are refreshed on every version update; live verification always reflects what the /proof page reads on the spot.