Venice ACI/1 attestation format not parsed

[ai-13rac1]

Problem

Venice is running two different TEE stacks. Some models return the existing dstack format that teep understands, while others return a new aci/1 format (private-ai-gateway-dev vendor) that teep does not parse. The attestation data is present — event log, source provenance, TDX quote, NVIDIA payload — but in different JSON locations, so teep reports missing data and fails multiple enforced checks.

As of 2026-06-26, 10 of 13 Venice models are on the new format. Only 3 models (e2ee-gemma-4-31b, e2ee-glm-5-1, e2ee-qwen3-6-35b-a3b) still use the dstack format.

Observed failures on ACI/1 models

✗ build_transparency_log     no attested model image repositories extracted from compose  [ENFORCED]
✗ compose_binding            no app_compose in attestation response (enforced)  [ENFORCED]
✗ sigstore_verification      no image digests to verify (enforced)  [ENFORCED]
✗ event_log_integrity        no event log entries in attestation response (enforced)  [ENFORCED]

Format differences

The two formats return the same data in different locations:

Field	dstack (working)	ACI/1 (not parsed)
api_version	absent	aci/1
vendor	absent	private-ai-gateway-dev (under attestation.vendor)
Event log	top-level event_log	attestation.evidence.event_log
Compose/provenance	compose_manager_attestation	attestation.source_provenance
VM config	absent	attestation.evidence.vm_config
Key custody	absent	attestation.evidence.key_custody
TLS binding	absent	attestation.evidence.downstream_tls_binding
Signing key	signing_public_key + signing_key	signing_public_key only
Workload ID	absent	workload_id (sha256 digest)

ACI/1 response structure

{
  "api_version": "aci/1",
  "workload_id": "sha256:3def476b...",
  "attestation": {
    "vendor": "private-ai-gateway-dev",
    "tee_type": "tdx",
    "workload_keyset": { "workload_identity": "...", "keyset_epoch": "...", ... },
    "report_data": "...",
    "source_provenance": {
      "repo_url": "https://github.com/Dstack-TEE/private-ai-gateway.git",
      "repo_commit": "1b43f76e43c2459856faebe9cd97d8e01cb0df0c",
      "image_digest": null,
      "image_provenance": null
    },
    "evidence": {
      "quote": "...",
      "event_log": "...",
      "vm_config": "...",
      "key_custody": { "provider": "...", "keys": [...] },
      "downstream_tls_binding": { "domain": "...", "spki_sha256": "..." }
    }
  },
  "intel_quote": "...",
  "nvidia_payload": "...",
  "signing_public_key": "04943cea0b...",
  "signing_algo": "ecdsa",
  "signing_address": "0x79a5061e..."
}

The source_provenance field includes repo_url and repo_commit which could be used for supply chain verification instead of extracting image names from a compose manifest.