Skip to main content
Use this page when a request to cloud-api.near.ai needs evidence for a NEAR-operated model environment in addition to the gateway. Request that report explicitly with provider=near.

Request model evidence

Include the canonical model ID when requesting the report. Do not use an alias: send x-no-aliasing: true so the request fails instead of being rewritten to another model ID.
The response includes gateway evidence and NEAR model-report candidates in model_attestations[]. The field is omitted when no candidate is available. If your policy requires NEAR model evidence, reject a missing or empty model_attestations[]. Before sending a completion, verify every candidate and retain the verified results; do not choose a raw entry yourself. For a later provider_tee response signature, select exactly one retained verified report whose signing_address and signing_algo match the signature. If no report or more than one report matches, the response is unverified. A report fetched after the completion cannot replace this preflight evidence.
provider=near requests NEAR model reports from this endpoint. It does not select the provider for a later completion. A provider_tee response is verified only when its signer and algorithm uniquely match a retained verified report.

NEAR model report fields

The NEAR report uses these fields:

Verify NEAR model reports

Perform these checks on every returned candidate before sending a completion:
  1. Verify intel_quote with an Intel DCAP quote verifier, such as dcap-qvl, and apply your TCB and advisory policy.
  2. Read report data from the verified quote. Require it to bind the client-generated nonce and signing_address; require request_nonce to match the client nonce. When report_data is present, require it to match the verified quote. Interpret the address using signing_algo.
  3. Replay event_log as described in Replay the RTMR3 event log and require the resulting RTMR3 to equal the RTMR3 in the verified quote.
  4. If tcb_info is JSON text, decode it to obtain app_compose. Hash the raw app_compose string without parsing or reserializing it. Require the quote’s 48-byte MRCONFIGID to equal 01, then that SHA-256 hash, then 15 zero bytes. See Check the configuration measurement.
  5. When GPU evidence is present, follow GPU evidence verification.
  6. Apply your own allowlist and provenance policy to the verified measurements.
After receiving a provider_tee response signature, select the one retained report whose signer identity and algorithm match the signature. If the match is absent or ambiguous, reject the response as unverified.
model_attestations[] is not an inventory of every model instance behind a URL. Instances of the same model share one signing key, including instances with different measured configurations, so a matching signer does not establish that the report and the completion came from the same serving instance.

Relationship to NEAR AI Cloud gateway TLS

The browser or client connection is to cloud-api.near.ai. Its TLS endpoint binding is verified against gateway_attestation, not against a TLS fingerprint carried by an upstream model report. See NEAR AI Cloud gateway TLS connection binding.

Verify a signed response

For a NEAR AI Cloud gateway response with signature_kind: "provider_tee", verify the signature over the endpoint-defined payload and match its signer to exactly one previously verified model report. For a gateway signature, match the signer to the previously verified gateway_attestation instead. See NEAR AI Cloud gateway response signatures.

Other provider documentation

Chutes documents its own evidence format in TEE Evidence Verification.