Attested Inference Receipt (AIR): A COSE/CWT Profile for Confidential AI Inference

1.1. Goals

The goals of AIR v1 are:¶

1. Define a receipt wire format using existing IETF standards (COSE_Sign1, CWT, EAT).¶

2. Bind model identity (cryptographic hash), input/output hashes, attestation metadata, and operational telemetry in a single signed envelope.¶

3. Support AIR-local verification using standard COSE/CWT tooling, while allowing deployments to combine AIR with separate platform-specific attestation verification as needed.¶

4. Carry platform measurements in a portable receipt shape while preserving their platform-specific semantics via measurement_type.¶

5. Define an intentionally closed v1 profile with fail-closed parsing semantics.¶

1.2. Non-Goals

AIR v1 explicitly does not:¶

• Define a transport protocol or session management scheme.¶

• Specify attestation document verification procedures (these are platform-specific).¶

• Define an extension registry or compatibility mechanism for new claim or platform profiles.¶

• Prove data deletion or model correctness.¶

• Provide regulatory certification or compliance guarantees.¶

• Define pipeline chaining or multi-inference receipts.¶

4.1. COSE_Sign1 Envelope

An AIR v1 receipt is a tagged COSE_Sign1 structure (CBOR tag 18) as defined in [RFC9052] Section 4.2:¶

COSE_Sign1 = [
  protected   : bstr,          ; serialized protected header
  unprotected : map,            ; unprotected header map
  payload     : bstr,           ; serialized CWT claims map
  signature   : bstr .size 64   ; Ed25519 signature
]

The signature covers Sig_structure1 = ["Signature1", protected, external_aad, payload] where external_aad is empty (h'').¶

Verifiers MUST reject untagged COSE_Sign1 structures. The CBOR tag 18 is mandatory.¶

4.2. Protected Header

The protected header is a CBOR map containing exactly two entries:¶

Verifiers MUST reject receipts where alg is not -8 or where content type is not 61. Additional protected header parameters are not defined in v1 and MUST NOT be present.¶

The signing algorithm is Ed25519 with strict verification semantics per [RFC8032] Section 5.1.7. Verifiers MUST reject non-canonical S values (S >= L where L is the Ed25519 group order).¶

4.3. Unprotected Header

The unprotected header MUST be empty for AIR v1 receipts. AIR v1 does not use kid or any other unprotected header parameter. Because unprotected header parameters are not covered by the COSE signature, verifiers MUST reject receipts with non-empty unprotected headers.¶

4.4. Payload: CWT Claims Map

The payload is a CBOR-encoded CWT claims map. The map uses deterministic encoding per [RFC8949] Section 4.2.1, with keys sorted by the bytewise lexicographic order of their deterministic encodings.¶

The claims map is closed: verifiers MUST reject maps containing unknown integer keys. Duplicate keys MUST be rejected.¶

4.5. CDDL Schema

The following CDDL [RFC8610] defines the complete wire shape:¶

air-receipt = #6.18([
  protected:   bstr .cbor air-protected-header,
  unprotected: air-unprotected-header,
  payload:     bstr .cbor air-claims,
  signature:   bstr .size 64
])

air-protected-header = {
  1 => -8,          ; alg: EdDSA (Ed25519)
  3 => 61,          ; content type: application/cwt
}

air-unprotected-header = {}

air-claims = {
  ; --- Standard CWT/EAT claims ---
  1   => tstr,                  ; iss: issuer
  6   => uint,                  ; iat: issued-at (Unix seconds)
  7   => bstr .size 16,         ; cti: CWT ID (UUID v4, 16 bytes)
  265 => "https://spec.cyntrisec.com/air/v1",  ; eat_profile
  ? 10 => bstr .size (8..64),   ; eat_nonce (optional)

  ; --- AIR private claims ---
  -65537 => tstr,               ; model_id
  -65538 => tstr,               ; model_version
  -65539 => sha256-hash,        ; model_hash
  -65540 => sha256-hash,        ; request_hash
  -65541 => sha256-hash,        ; response_hash
  -65542 => sha256-hash,        ; attestation_doc_hash
  -65543 => enclave-measurements, ; enclave_measurements
  -65544 => tstr,               ; policy_version
  -65545 => uint,               ; sequence_number
  -65546 => uint,               ; execution_time_ms
  -65547 => uint,               ; memory_peak_mb
  -65548 => tstr,               ; security_mode
  ? -65549 => tstr,             ; model_hash_scheme (optional)
}

sha256-hash = bstr .size 32
sha384-hash = bstr .size 48

enclave-measurements = nitro-measurements / tdx-measurements

nitro-measurements = {
  "pcr0"             => sha384-hash,
  "pcr1"             => sha384-hash,
  "pcr2"             => sha384-hash,
  ? "pcr8"           => sha384-hash,
  "measurement_type" => "nitro-pcr",
}

tdx-measurements = {
  "pcr0"             => sha384-hash,   ; MRTD
  "pcr1"             => sha384-hash,   ; RTMR0
  "pcr2"             => sha384-hash,   ; RTMR1
  "measurement_type" => "tdx-mrtd-rtmr",
}

The full CDDL is also provided in Appendix A.¶

5.1. Standard CWT/EAT Claims

5.2. AIR Private Claims

AIR uses negative integer keys in the CWT private-use range to avoid collision with IANA-registered claims. Keys -65537 through -65548 are assigned and required. Key -65549 is assigned and optional. No other AIR private claim keys are defined in v1.¶

7.1. Layer 1: Parse

1. Decode the input as CBOR. Confirm the outer structure is tagged with CBOR tag 18.¶

2. Decode the COSE_Sign1 array (4 elements).¶

3. Confirm the receipt size does not exceed 65,536 bytes.¶

4. Decode the protected header. Confirm it is a well-formed CBOR map.¶

5. Confirm alg (label 1) in the protected header is -8 (EdDSA). Reject receipts with any other algorithm.¶

6. Confirm content type (label 3) in the protected header is 61 (application/cwt).¶

7. Confirm the unprotected header is empty.¶

8. Decode the payload. Confirm it is a well-formed CBOR map.¶

9. Confirm eat_profile (key 265) equals "https://spec.cyntrisec.com/air/v1". Reject receipts with unknown profile values.¶

7.2. Layer 2: Cryptographic Verification (AIR-local)

1. Construct Sig_structure1 = ["Signature1", protected, h'', payload].¶

2. Verify the Ed25519 signature over Sig_structure1 using the provided public key. The verification MUST use verify_strict semantics (reject non-canonical S values).¶

7.3. Layer 3: Claim Validation

1. Confirm cti (key 7) is exactly 16 bytes.¶

2. Confirm iat (key 6) is a non-zero unsigned integer.¶

3. Confirm model_hash (key -65539) is exactly 32 bytes and not all zeros.¶

4. Confirm all required text string claims (iss, model_id, model_version, policy_version, security_mode) are non-empty and within reasonable bounds (implementation-defined, RECOMMENDED maximum 1024 bytes each).¶

5. Confirm enclave_measurements (key -65543) is a map.¶

6. Confirm measurement_type within enclave_measurements is one of the defined values ("nitro-pcr" or "tdx-mrtd-rtmr").¶

7. Confirm all pcr0/pcr1/pcr2 values are exactly 48 bytes.¶

8. If measurement_type is "tdx-mrtd-rtmr", confirm pcr8 is absent. TDX measurement maps MUST NOT contain pcr8.¶

9. If model_hash_scheme (key -65549) is present, confirm it is one of the defined values ("sha256-single", "sha256-concat", "sha256-manifest"). Unknown values MUST be rejected.¶

10. Confirm the claims map contains no unknown integer keys and no duplicate keys.¶

7.4. Layer 4: Policy Evaluation

Policy checks are configurable per verifier deployment. The following checks are defined:¶

FRESH (timestamp bounds):

If configured, verify now - max_age <= iat <= now + clock_skew.¶

NONCE (challenge binding):

If the verifier supplied a nonce, verify eat_nonce matches.¶

MODEL (expected model):

If configured, verify model_hash and/or model_id match expected values.¶

PLATFORM (expected platform):

If configured, verify measurement_type matches expected value.¶

REPLAY (deduplication):

If the verifier maintains a seen-cti store, reject duplicate cti values.¶

Verifiers SHOULD document which Layer 4 policies they enforce.¶

8.1. draft-messous-eat-ai

[I-D.messous-eat-ai] defines AI-related claims for EAT, including model identification, training metadata, and performance metrics. AIR v1 is complementary: where draft-messous-eat-ai focuses on per-agent identity, provenance, and authorization metadata, AIR v1 focuses narrowly on per-inference execution evidence from a confidential workload. AIR intentionally binds a specific request/ response event to attestation-linked metadata; it is not a general AI agent identity profile. A future version of AIR could adopt registered claim keys from draft-messous-eat-ai once they stabilize, replacing the current private-use integer keys.¶

8.2. SCITT

The Supply Chain Integrity, Transparency and Trust [SCITT] framework uses "receipt" to mean a countersigned statement from a transparency service. In AIR, "receipt" means a workload-signed inference proof. The two are complementary: an AIR receipt could be registered as a SCITT statement, and the resulting SCITT receipt (countersignature from the transparency service) would provide independent auditability. This document uses "AIR receipt" consistently to avoid ambiguity.¶

8.3. RATS Architecture

AIR can be incorporated into a RATS [RFC9334] architecture as follows:¶

• The confidential workload is the Attester.¶

• A deployment-specific Verifier can evaluate AIR receipts together with platform attestation evidence and applicable endorsements or reference values.¶

• The end user, auditor, or compliance officer is the Relying Party (they consume verification results).¶

• The TEE platform vendor or attestation service providing endorsements or reference values acts as the Endorser.¶

AIR v1 is a workload-emitted signed application-layer artifact, not a verifier-emitted attestation result. AIR does not replace the underlying platform attestation evidence or the verifier procedures needed to evaluate it. Instead, AIR packages per-inference execution claims together with measurements and a hash reference to the platform attestation document. It is therefore distinct from IETF EAR (EAT Attestation Result), which is produced by a verifier after evaluating platform evidence. In a complete deployment, a verifier may evaluate platform evidence and AIR together, and an EAR might reference an AIR receipt as part of the evidence it considered.¶

9.1. Receipt Integrity

The Ed25519 signature over the COSE Sig_structure1 protects the protected header and all claims against tampering. The unprotected header is not covered by the signature; AIR v1 requires it to be empty (Section 4.3).¶

9.2. Algorithm Pinning

AIR v1 pins the signing algorithm to Ed25519 (alg = -8). The algorithm identifier is carried in the protected header and is therefore signed. This prevents algorithm confusion attacks where an attacker substitutes a weaker algorithm.¶

9.3. Replay Protection

Replay protection in AIR v1 is a shared responsibility:¶

• The cti claim provides a unique receipt identifier. Verifiers maintaining state SHOULD track observed cti values and reject duplicates.¶

• The eat_nonce claim (optional) provides challenge-response freshness. When present, it binds the receipt to a specific verifier-supplied challenge, preventing replay to other verifiers.¶

• The sequence_number claim provides monotonicity within a session. Gaps indicate missed receipts.¶

Verifiers not maintaining state and not using eat_nonce have limited replay protection (only iat-based freshness). Deployments requiring strong replay resistance MUST use at least one of cti deduplication or eat_nonce.¶

9.4. Model Hash Limitations

The model_hash claim (SHA-256 of model weights) proves byte-level identity, not model correctness, bias, or safety. Two distinct models with identical hashes are computationally infeasible, but a model with a correct hash may still produce harmful or incorrect outputs.¶

The model_hash_scheme claim (Section 5.2.13) declares how the hash was computed. Unknown scheme values MUST be rejected. This prevents a verifier from accepting a hash computed with an unrecognized method that might weaken integrity guarantees.¶

9.5. Attestation Document Not Verified by Receipt

The attestation_doc_hash claim is a SHA-256 hash of the platform attestation document. AIR v1 does not embed or verify the attestation document. AIR-local verification alone is therefore insufficient to establish TEE assurance. Verifiers requiring such assurance MUST independently obtain and verify the attestation document using platform-specific procedures (e.g., Nitro COSE verification against the AWS root CA, Intel TDX DCAP verification against Intel PCS).¶

9.6. Workload Honesty and Evidence Scope

An AIR receipt only speaks for what the signing workload observed and emitted. If the workload is malicious, misconfigured, or signs hashes for data that did not come from the claimed inference path, AIR can still produce a syntactically valid receipt. AIR therefore does not protect against an untrusted signer or against semantics outside the measured workload boundary.¶

Deployments that rely on AIR for end-to-end assurance MUST treat the receipt as meaningful only when the signing key is bound to an attested workload whose measurement set and execution policy are acceptable to the verifier.¶

9.7. Signing Key Binding

AIR v1 does not define how the Ed25519 signing key relates to the TEE attestation. A verifier MUST NOT infer TEE provenance from the AIR signature alone. A cross-workload substitution or relay attack occurs when a receipt signed by one workload is presented with attestation evidence from a different workload. A deployment that requires end-to-end TEE assurance MUST verify, using a platform-specific binding mechanism, that the AIR signing public key is bound to the attested workload represented by the attestation evidence. AIR v1 does not define these mechanisms because they differ by platform (e.g., Nitro attestation documents carry a public_key field, while TDX deployments commonly bind via REPORTDATA). Implementations that require end-to-end TEE assurance SHOULD:¶

1. Generate the Ed25519 key inside the TEE at startup.¶

2. Include the public key in the platform attestation document (e.g., Nitro public_key field, TDX REPORTDATA).¶

3. Provide the attestation document alongside the receipt for end-to-end verification.¶

9.8. TEE Compromise

AIR v1 assumes the TEE hardware is correct (Trust Assumption TA-1). A hardware vulnerability, firmware bug, or supply chain compromise affecting the TEE breaks all AIR guarantees. AIR v1 does not define revocation mechanisms for compromised platforms.¶

9.9. Clock Integrity

The iat claim depends on the workload's system clock. On AWS Nitro, the enclave uses the host clock (no independent time source). On Intel TDX, the CVM has a TSC but it is subject to frequency scaling. AIR v1 freshness checks are only as accurate as the platform clock.¶

9.10. Deterministic Encoding

AIR v1 requires deterministic CBOR encoding ([RFC8949] Section 4.2.1). This ensures that the same claims always produce the same payload bytes, preventing signature-valid variants of the same receipt. Implementations MUST sort map keys per the CBOR deterministic encoding rules.¶

9.11. Closed Claims Map

The claims map is closed: unknown integer keys MUST be rejected. This prevents downgrade attacks where an attacker adds unrecognized claims that a naive verifier might silently accept as benign. This closed-scope behavior is intentional in AIR v1; future extensions require a revised profile.¶

10.1. Input/Output Hashes

The request_hash and response_hash claims contain SHA-256 hashes, not plaintext inputs or outputs. However, for low-entropy inputs (e.g., binary classification queries, yes/no questions), an adversary with knowledge of the input space could brute-force the hash to recover the original input. Deployments handling sensitive low-entropy data SHOULD consider whether receipt exposure risks input recovery.¶

10.2. Correlation Metadata

AIR receipts contain timestamps (iat), sequence numbers, and identifiers (cti, iss) that could be used to correlate activity across receipts. In privacy-sensitive deployments, operators SHOULD consider whether the combination of receipt metadata enables unwanted profiling.¶

10.3. Nonce Privacy

The eat_nonce claim, when present, may leak correlation data if the same nonce is reused across sessions or if the nonce encodes client-identifying information. Verifiers SHOULD use random nonces and avoid embedding client identifiers in nonce values.¶

12.1. Reference Implementation (Rust)

Organization:

Cyntrisec¶

Implementation:

EphemeralML (common/src/air_receipt.rs, common/src/air_verify.rs)¶

Description:

Full AIR v1 emitter and 4-layer verifier. Generates COSE_Sign1 receipts with deterministic CBOR encoding and Ed25519 signing. Verifier implements all four layers (parse, crypto, claims, policy) with structured error codes.¶

Maturity:

Reference implementation with end-to-end validation on three confidential-computing platforms.¶

Coverage:

Validated against the 10-vector AIR corpus (2 valid, 8 invalid) and exercised in cross-cloud E2E runs.¶

Contact:

borys@cyntrisec.com¶

12.2. Python Interop Verifier

Organization:

Cyntrisec (same team, independent implementation)¶

Implementation:

spec/v1/scripts/interop_test.py¶

Description:

Minimal Python verifier using pycose and cbor2 libraries. Validates COSE_Sign1 structure, Ed25519 signature, and claim presence.¶

Maturity:

Test/interop.¶

12.3. E2E Validation

The reference implementation has been validated end-to-end on three confidential computing platforms:¶

13.1. Valid Receipt Walkthrough

The following describes a valid AIR v1 receipt in diagnostic notation. This corresponds to the v1-nitro-no-nonce golden vector.¶

The COSE_Sign1 envelope (tagged with CBOR tag 18):¶

18([
  h'A2012703183D',           / protected: {1: -8, 3: 61} /
  {},                         / unprotected: empty /
  h'B0...',                   / payload: CWT claims map /
  h'<64 bytes>'               / signature: Ed25519 /
])

The protected header decodes to:¶

{
  1: -8,    / alg: EdDSA /
  3: 61     / content type: application/cwt /
}

The payload (CWT claims map) includes the 16 required claims:¶

{
  1: "cyntrisec.com",                          / iss /
  6: 1740000000,                               / iat /
  7: h'<16 bytes UUID v4>',                    / cti /
  265: "https://spec.cyntrisec.com/air/v1",    / eat_profile /
  -65537: "minilm-l6-v2",                      / model_id /
  -65538: "1.0.0",                             / model_version /
  -65539: h'<32 bytes SHA-256>',               / model_hash /
  -65540: h'<32 bytes SHA-256>',               / request_hash /
  -65541: h'<32 bytes SHA-256>',               / response_hash /
  -65542: h'<32 bytes SHA-256>',               / attestation_doc_hash /
  -65543: {                                    / enclave_measurements /
    "pcr0": h'<48 bytes SHA-384>',
    "pcr1": h'<48 bytes SHA-384>',
    "pcr2": h'<48 bytes SHA-384>',
    "measurement_type": "nitro-pcr"
  },
  -65544: "policy-2026.02",                    / policy_version /
  -65545: 1,                                   / sequence_number /
  -65546: 77,                                  / execution_time_ms /
  -65547: 0,                                   / memory_peak_mb /
  -65548: "FullAttestation"                    / security_mode /
}

Verification with the corresponding Ed25519 public key succeeds through all four layers.¶

13.2. Invalid Receipt Categories

The specification includes 8 invalid golden vectors covering failure modes across all verification layers:¶

Complete vector files (JSON with hex-encoded COSE bytes, expected failure codes, and policy overrides) are available in the reference implementation repository.¶

14.1. Normative References

[FIPS180-4]

National Institute of Standards and Technology, "Secure Hash Standard (SHS)", August 2015, <https://csrc.nist.gov/pubs/fips/180-4/upd1/final>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC8032]

Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/rfc/rfc8032>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8392]

Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.

[RFC8610]

Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.

[RFC8949]

Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/rfc/rfc8949>.

[RFC9052]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, <https://www.rfc-editor.org/rfc/rfc9052>.

[RFC9334]

Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, <https://www.rfc-editor.org/rfc/rfc9334>.

[RFC9711]

Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711, April 2025, <https://www.rfc-editor.org/rfc/rfc9711>.

14.2. Informative References

[I-D.messous-eat-ai]

Messous, A., Morand, L., and P. C. Liu, "Entity Attestation Token (EAT) Profile for Autonomous AI Agents", 23 February 2026, <https://datatracker.ietf.org/doc/draft-messous-eat-ai/>.

[RFC7942]

Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, <https://www.rfc-editor.org/rfc/rfc7942>.

[RFC9782]

Lundblade, L., Birkholz, H., and T. Fossati, "Entity Attestation Token (EAT) Media Types", RFC 9782, DOI 10.17487/RFC9782, May 2025, <https://www.rfc-editor.org/rfc/rfc9782>.

[SCITT]

"Supply Chain Integrity, Transparency, and Trust (SCITT)", n.d., <https://datatracker.ietf.org/wg/scitt/about/>.