External model endpoints

Attestation and the evidence chain describes you verifying the router. This page is the opposite direction: the router verifying a model deployment somewhere else. The vocabulary differs because the verifying party differs, and the two must not be read as the same claim.

External endpoints

Some of the models the router serves run in another deployment, on this cloud or another Swarm cloud. Toward those the router occupies exactly the position Gatekeeper occupies toward the router: a paying client that fetches the upstream's evidence, verifies it, binds the channel, and refuses to send traffic without a valid verdict. The verifier is the same Gatekeeper binary, running as a sidecar inside the router's own deployment.

The upstream's ordinary API key is the credential the router uses when proxying. It is stored encrypted and never shown again.

Two factors, both required

A verdict of Verified by this router means two things held at the last check:

1. The cloud, by launch measurement. The measurement the attested-root check derives for the upstream's cloud is on a list the deployment's operator curates. A measurement admits a cloud, never a deployment: every confidential VM on that cloud has the same one.
2. The deployment, by evidence digest. The digest the upstream publishes equals the one pinned for that endpoint.

The first factor alone would admit every deployment on a trusted cloud, including one somebody else stood up there. The second factor is what makes the verdict about a specific application.

The trust list is the sole authority for factor 1. A registry signature on the measurement is shown as registry-signed for information, but it does not admit on its own.

What a model's status means

An endpoint starts as Pending and serves nothing. It becomes verified by this router only once both factors hold, and the router re-checks on its own schedule rather than once at registration.

A later check that sees a different digest, which is what a redeploy of the upstream looks like, denies the endpoint at the stage digest-mismatch. Its models leave /v1/models, connections in flight are closed, and the model reads as unavailable until the new digest is approved. A measurement that changes, which is what a rebuilt cloud looks like, denies at measurement-not-trusted the same way.

None of that is something you act on. What it means for you is that a model can disappear from the catalogue between one request and the next, and that this is the design working rather than an outage: the router would rather serve nothing than proxy a prompt to a deployment it cannot currently vouch for.

The status words and stage names are listed on Vocabulary. What you see is the model's availability in the catalogue and, in the chat, Inspect upstream attestation, which shows the upstream's own relayed evidence.

What this does not change for you

Your pin on this router's evidence digest covers this router's deployment, the egress verifier included. It does not reach the external upstream: the trust list is database state, not part of the pinned snapshot. What you get instead is transparency. External models are reached through this router and billed the same way; usage.endpoint names where a generation went; the upstream's evidence is relayed raw at GET /v1/evidence/<endpoint> for your own inspection; and any signed-in user can read the endpoints, the trust list, the verdicts and the pinned digests.

Fail-closed is the rule. A model whose endpoint holds no verdict is absent from /v1/models, not listed and broken; a request for it answers 503 attestation_failed; a verdict withdrawn under a running stream ends it with attestation_revoked.