Back to blog

How do you know the running program matches the open source?

Open source makes code inspectable; remote attestation gives the client a way to verify what runs remotely.

Publishing server code is an important first step. But a repository and the program handling a real request are separated by a build, a deployment, and a running environment. “Open source” alone cannot rule out a different program running on the server.

PrimeRouter addresses that gap by making the local client verify the remote program before sending request content.

What open source does and does not establish

Source code can be reviewed for model substitution, content retention, or routing bypasses. Even reviewed code leaves two questions: does the running artifact correspond to an approved version, and does the key used for this connection belong to that artifact?

Mapping source, an inspectable build artifact, and its runtime measurement is one part of the answer. The user's computer must still check evidence from the remote environment when it establishes a protected connection.

Four checks before a request leaves

  1. Evidence origin. The open-source client checks the signature and attestation system behind the trusted execution environment's evidence.
  2. Runtime identity. It compares the measured program in that evidence with an approved version.
  3. Key binding. It confirms that the public key used for the connection is bound to the attested program, rather than trusting a web page that merely says “verified.”
  4. Encrypted session. Only after those checks pass does the client negotiate session keys and send request content.

If any check fails, the client should not fall back to sending the request unverified. Verification is a prerequisite, not a status badge.

Be precise about what the proof means

Remote attestation helps establish that a particular program is running in a protected environment and binds a communication key to it. It does not, by itself, prove an upstream model name or subscription tier. Assessing model and channel substitution also requires inspecting the verified program's routing logic and the verifiable records produced along the request path.

Content confidentiality and request metadata are separate concerns. The relay still needs routing and billing information; request bodies travel through the encrypted session between the local client and the verified program.

For the full connection sequence, read Verification and encryption.