Verify a Request

Independently verify TEE inference attestation for a Gateway request at /request/:requestId.

ORGN Scanner is not Studio Code Security (Shannon). Scanner audits Gateway inference attestation and confidential compute sandboxes — it does not scan your repository for CWE vulnerabilities. For code security assessments, see Code Security.

Verification in ORGN Scanner means confirming that a specific Gateway inference request executed inside a genuine Trusted Execution Environment — backed by hardware attestation, not vendor policy.

There is no /verify route. Open any request at:

https://scanner.orgn.com/request/:requestId

Replace :requestId with the UUID from your Gateway response headers, spend log, or the Messages feed.

Cryptographic verification applies to TEE models only (near_*, phala_*). ZDR models routed through Vercel (vercel_*) appear in Scanner for observability but do not produce hardware attestation receipts.

What verification proves

For a TEE request with Verified attestation status, independent verification confirms:

The inference ran inside a genuine hardware-backed Trust Domain
The execution environment was not tampered with at request time
Intel TDX and/or NVIDIA GPU evidence is present and internally consistent
A session nonce cryptographically binds CPU and GPU attestations to the same execution

Scanner shows the verification outcome and the raw artifacts. You do not need to trust ORGN's UI — you can re-validate the receipt against public Intel and NVIDIA PKI roots.

Verify in the UI

Find the request

Open scanner.orgn.com/messages and locate the request by ID, model, or time range. Or navigate directly:

https://scanner.orgn.com/request/<request-id>

No sign-in is required.

Check attestation status

On the request detail page, look for the attestation panel:

Status	Meaning
Verified	Receipt validated against hardware PKI — safe to export for compliance
Pending	Request succeeded; attestation receipt not yet received from the TEE provider
Failed	Receipt received but verification failed — inspect the error field
N/A	ZDR model — no hardware attestation path

Inspect evidence artifacts

For verified TEE requests, the detail page exposes:

Attestation ID and attestation type (provider class)
Signing address — on-chain or PKI signing address for the receipt
Message signing address and message signature — binds request/response hashes
Intel quote — TDX attestation report (when has_intel is true)
GPU evidence — NVIDIA SPDM certificates and evidence blobs (when has_nvidia is true)
Nonce — session binding value shared across CPU and GPU attestations
Attestation timestamp — when the receipt was generated

Copy these artifacts for offline verification or compliance archives.

Validate independently

Re-validate the receipt outside Scanner:

Decode the Intel TDX quote and verify the signature chain against Intel's DCAP root of trust
Validate each NVIDIA GPU evidence certificate against NVIDIA's attestation PKI
Confirm the nonce in the TDX REPORT_DATA matches the nonce in each GPU SPDM evidence header
Verify the message signature binds the request and response hashes to the signing address

For field-level definitions, see Attestation reference. For the full cryptographic flow, see Verifiable privacy.

Verification via API

Programmatic access uses the same public Gateway explorer API:

curl -s "https://api.gateway.orgn.com/internal/console/explorer/request/<request-id>" \
  | jq '.attestation'

The response includes spend_log (request metadata) and attestation (receipt payload with Intel quote, GPU evidence, and verification flags). No user authentication is required — the endpoint is public.

Related list and overview endpoints:

Endpoint	Purpose
`GET /internal/console/explorer/overview`	Platform-wide stats
`GET /internal/console/explorer/messages`	Paginated request list
`GET /internal/console/explorer/models`	Model catalog

Common verification outcomes

Verified — TEE request

All hardware checks passed. The request ran in an attested Trust Domain. Export the attestation ID, signing address, Intel quote, and GPU evidence for your compliance record.

Pending — receipt in flight

The inference completed but the TEE provider has not yet returned the attestation receipt. Refresh the page after a few seconds. Persistent pending states may indicate a provider-side delay — check the request status field separately.

Failed — verification error

A receipt arrived but validation failed. The attestation.error field describes the failure (stale quote, nonce mismatch, invalid certificate chain, etc.). Do not treat the request as cryptographically proven until the error is resolved.

N/A — ZDR request

Vercel-routed models enforce zero data retention through provider agreements. Scanner records the request for observability but no hardware receipt exists. If your compliance narrative requires cryptographic proof, route through a TEE model (near_* or phala_*).

Sandbox verification (separate system)

Inference receipt verification (this page) is distinct from sandbox TDX attestation. Sandbox attestation proves the compute environment is genuine — not that a specific inference call ran inside it.

Inference receipts: /request/:requestId
Sandbox TDX: /sandboxes/:sandboxId

See Sandboxes and Attestation reference for the two-system breakdown.

Next steps

Attestation reference — field definitions for both attestation systems
Request details — full metadata reference
Scanner Quickstart — end-to-end walkthrough
Gateway quickstart — send a TEE request that produces a receipt

On this page