We can't read your prompts, and we can't swap your model

Every request you send through an AI gateway asks you to take two things on faith.

The first is that nobody on the other side reads it. Prompts carry customer records, unreleased code, contract drafts, numbers you have not published. Whether any of it gets stored, how long it sits there, which employees can open it, whether it ends up in a training set: what you hold is a terms-of-service page and a support address.

The second is that you got the model you paid for. You name an expensive model, the request goes out, text comes back. A quiet swap to a cheaper sibling, a quantized build carrying the same name, a context window trimmed to save money: none of that shows up in the response. The invoice at the end of the month is a total.

Both are checkable. Here is how we make them checkable.

Where your request actually runs

The machine handling your request has its memory encrypted by the CPU itself, with the key held inside the chip and never handed out. The operating system cannot read that memory. Neither can the hypervisor, the cloud provider, or one of our own engineers with root on the box. Everyone outside the chip sees ciphertext.

That draws a hard line through the product, and it is worth saying exactly where the line sits. Message content exists only inside the encrypted memory, for as long as the request takes. The billing side records token counts, model names and timestamps. It holds no message content.

The machine reports on itself

Encrypted memory alone would still leave you trusting our account of what runs inside it. So the machine produces a report, signed by the CPU, carrying a fingerprint of the exact program loaded into that encrypted memory.

You can ask for that report at any time. You check the signature against AMD's certificate chain, on your own hardware, using public tooling. None of that path runs through us, which is the point of it.

Change one byte

The fingerprint is what turns all of this from a promise into something enforceable, and the fastest way to see why is to break it.

Below is the gateway logic that decides which model runs, simplified down to the part that matters. Press the button to slip a single exclamation mark into it, turning "never substitute by default" into "always substitute by default", then watch the fingerprint underneath.

One character of source, and the fingerprint has almost nothing in common with the one before it. Every release we ship moves that number, which is why we publish it. A change we did not announce moves it too, and nothing we do afterwards moves it back.

The model you name is the model that runs

The model in your request is the model that executes. Automatic fallback to a different model is off by default here, and switching it on takes an explicit flag in your own request. We do not make that call on your behalf, because the whole value of naming a model is that naming it settles the question.

Where a model is available through more than one supply channel, we may move between channels to keep it serving. The model stays the model.

Every call is itemized

Model name, input and output token counts, timestamp, queryable call by call and reconcilable against your own logs. Every charge on the invoice traces back to a specific request, so a disagreement about a bill is a matter of comparing two records rather than a matter of opinion.

Where this stops

What we can prove covers the stretch from where a request leaves you to where it enters the model vendor. How a vendor handles data inside its own systems is not ours to vouch for, and we would rather write that boundary down here than leave it ambiguous later.

For work where even that stretch has to stay inside your own walls, the whole gateway can run in your own data centre with open-weight models served locally, so nothing leaves the building at all.