Security Model

Stogas runs its API gateway inside an AMD SEV-SNP confidential VM. The host can stop or delay the VM, but should not be able to read guest memory, private keys, provider credentials, or request plaintext.

The verification chain

1. Release provenance: GitHub Actions and Stogas independently authorize the same public source, IGVM hash, launch policy, and SNP measurement.
2. Hardware attestation: AMD-signed SNP evidence proves an approved measurement booted on genuine hardware at an accepted security version.
3. Key binding: SNP report data binds the node's TLS key, certificate hashes, and application keys to that measured guest.
4. Freshness: a signed drand round and the verifier's captured wall clock bound how old the node evidence may be.

No root of trust is accepted from the downloaded bundle. The verifier ships the AMD, Sigstore, drand, and Stogas release roots it trusts.

Request path

Verification and evidence publication happen outside the inference request path. Once a node is trusted, requests use the normal OpenAI-compatible HTTPS API. This avoids a live dependency on GitHub, Sigstore, Rekor, AMD KDS, drand, or the evidence service for each model request.

stogas-verify serve additionally checks that the upstream TLS connection presents a certificate hash and public key belonging to the same verified node.

Release authorization

The Stogas release public key is:

MCowBQYDK2VwAyEAByVn3LvWVbf3YkokMZPvir70vcDu0nNflgXoM0Y8aQU=

It signs canonical stogas.gateway.launch-policy.v1 bytes using the domain separator stogas gateway launch policy v1\n. GitHub's attestation must independently bind the exact same launch-policy digest and IGVM digest. A node is trusted only when its SNP measurement belongs to that verified release set.

Availability

A verified bundle can contain records that are no longer fresh enough for a particular client. The verifier reports those records separately and never adds them to that client's trusted set.

The verifier fails closed after bundle expiry. Confidential verification can authenticate a reachable gateway, but it cannot prevent a network, host, or service outage.

What is not proven

Confidential verification does not:

• prove that reviewed code has no vulnerabilities;
• hide traffic timing or destination metadata;
• make an upstream AI provider confidential unless that provider offers its own verified confidential execution;
• prevent the host or operator from stopping service;
• let browser JavaScript inspect the certificate used by fetch;
• verify response proofs or provide end-to-end application encryption in the current protocol.