Internet Engineering Task Force R. Sharif
Internet-Draft CyberSecAI Ltd
Intended status: Standards Track 31 March 2026
Expires: 2 October 2026
Cryptographic Attestation for AI Model Lifecycle:
From Training Data to Inference Output
draft-sharif-ai-model-lifecycle-attestation-00
Abstract
This document defines a cryptographic attestation framework for
the complete lifecycle of artificial intelligence models, from
training data provenance through model weight signing,
quantization verification, deployment attestation, and per-
inference output signing. The framework creates an unbroken
chain of cryptographic evidence binding each inference output to
the specific model version, training data, and deployment
configuration that produced it.
The framework uses ECDSA P-256 digital signatures, SHA-256
hash functions, Merkle trees for corpus attestation, and JSON
Web Key Sets (JWKS) for key discovery. It addresses documented
threats including model distillation attacks, quantization
poisoning, training data manipulation, silent model degradation,
and inference output tampering.
This specification complements the Agent Trust Transport Protocol
(ATTP) [draft-sharif-attp-agent-trust-transport], MCPS message
signing [draft-sharif-mcps-secure-mcp], and the Agent Audit
Trail format [draft-sharif-agent-audit-trail] to provide end-to-
end cryptographic verification from data ingestion to consumer
delivery.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current
Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on 2 October 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents
1. Introduction
2. Terminology
3. Threat Model
4. Attestation Chain Architecture
5. Training Data Attestation
6. Model Weight Signing
7. Quantization Verification
8. Deployment Attestation
9. Inference Output Signing
10. Key Management
11. Verification Procedures
12. Integration with ATTP and MCPS
13. Regulatory Mapping
14. Security Considerations
15. IANA Considerations
16. References
Authors' Addresses
1. Introduction
Artificial intelligence models traverse a complex lifecycle from
training data collection through model training, optional fine-
tuning, quantization, deployment, and inference serving. At each
stage, the model or its outputs may be tampered with, substituted,
or misrepresented.
Current security measures address individual stages in isolation:
o Sigstore (OpenSSF) signs model files at rest but does not
cover inference outputs or training data provenance.
o CycloneDX and SPDX document model lineage as metadata but
provide no cryptographic verification.
o TLS protects model downloads in transit but not against
modification after TLS termination.
o No production system provides per-inference output signing
that binds outputs to specific model versions and training
data.
This specification defines a unified cryptographic attestation
framework that creates an unbroken chain from training data to
inference output. Each stage produces a signed attestation that
references the previous stage, enabling end-to-end verification.
The framework is motivated by documented incidents:
o Industrial-scale model distillation: Three AI laboratories
created 24,000+ fraudulent accounts and conducted 16 million+
exchanges to extract capabilities from a frontier model
(February 2026).
o Quantization poisoning: Research demonstrated 88.7% success
rate for adversarial weight injection in quantized models
that pass all standard security checks (2025).
o Training data poisoning: Only approximately 250 poisoned
documents can compromise LLMs across all model and dataset
sizes (2025).
o Supply chain compromise: A compromised PyPI package with 97
million monthly downloads intercepted AI service credentials
(March 2026).
o Silent model degradation: API providers substituting lower-
capability models without notification to consumers.
1.1. Scope
This specification covers:
o Cryptographic attestation of training data corpora
o Digital signing of model weights (full-precision and
quantized)
o Deployment attestation binding signing keys to specific
model instances
o Per-inference output signing with model provenance metadata
o Verification procedures for consumers
o Key management lifecycle
This specification does not cover model watermarking,
fingerprinting, or behavioural verification methods, which
operate at a different layer.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described
in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in
all capitals, as shown here.
Training Data Attestation: A signed Merkle tree root covering
the SHA-256 hashes of all documents in a training corpus.
Model Weight Signature: An ECDSA P-256 signature over the
SHA-256 hash of model weight tensors.
Quantization Attestation: A signed record binding a quantized
model to the full-precision model from which it was derived,
including per-layer error bounds.
Deployment Attestation: A signed record binding an inference
signing key to a specific model deployment, including model
identity, weight hash, and hardware attestation.
Inference Signature: An ECDSA P-256 signature over an inference
output, bound to model identity metadata and a verifiable
timestamp.
Attestation Chain: The ordered sequence of attestations from
training data through inference output, where each attestation
references the hash of the previous attestation.
3. Threat Model
3.1. Threats to Training Data
TD1 - Data Poisoning: Adversary inserts malicious documents
into the training corpus to manipulate model behaviour.
Research demonstrates that approximately 250 poisoned
documents are sufficient to compromise models of any size.
TD2 - Unlicensed Data: Training corpus includes copyrighted
material without authorisation. Multiple lawsuits with
damages exceeding $4 billion are pending as of March 2026.
TD3 - Data Provenance Falsification: Provider claims training
data meets certain quality or licensing criteria without
cryptographic proof.
3.2. Threats to Model Weights
MW1 - Weight Theft: Adversary exfiltrates model weights for
unauthorised use or competitive advantage. The first
criminal conviction for AI-related economic espionage
occurred in January 2026.
MW2 - Weight Tampering: Adversary modifies model weights to
insert backdoors or degrade performance.
MW3 - Silent Substitution: Provider silently replaces a high-
capability model with a lower-capability model to reduce
serving costs.
3.3. Threats to Quantization
QZ1 - Quantization Poisoning: Adversary produces a malicious
quantized model that appears benign in full precision but
contains adversarial behaviour in the quantized
representation. Demonstrated at 88.7% success rate.
QZ2 - Quantization Misrepresentation: A quantized model is
falsely claimed to be derived from a specific full-precision
model.
3.4. Threats to Inference
IF1 - Output Tampering: Intermediary modifies inference outputs
after generation and before delivery to the consumer.
IF2 - Output Replay: Adversary replays a previously generated
output for a different query.
IF3 - Model Impersonation: Adversary serves outputs from a
different model (including distilled copies) while claiming
they are from the original model.
IF4 - Timestamp Falsification: Provider backdates or
postdates inference timestamps.
4. Attestation Chain Architecture
The attestation chain creates a linked sequence of signed records:
+-------------------+
| Training Data |
| Attestation |
| (Merkle Root) |
+--------+----------+
|
v
+--------+----------+
| Model Weight |
| Signature |
| (refs training) |
+--------+----------+
|
v
+--------+----------+
| Quantization | (optional)
| Attestation |
| (refs full model) |
+--------+----------+
|
v
+--------+----------+
| Deployment |
| Attestation |
| (refs model+key) |
+--------+----------+
|
v
+--------+----------+
| Inference |
| Signature |
| (refs deployment) |
+--------+----------+
Each attestation contains:
o A reference (hash) to the previous attestation in the chain
o Stage-specific metadata
o An ECDSA P-256 signature over the attestation content
o A timestamp
Verification proceeds by walking the chain from any point back
to the training data attestation, verifying each signature and
hash reference.
5. Training Data Attestation
5.1. Corpus Hashing
Each document in the training corpus is hashed individually:
document_hash = SHA-256(document_bytes)
Document hashes are assembled into a Merkle tree. The tree
is constructed with SHA-256 as the hash function, using the
method specified in RFC 6962 Section 2.1 (certificate
transparency Merkle tree).
5.2. Attestation Format
{
"attestation_type": "training_data",
"version": "1.0",
"corpus_id": "gpt4-train-2026-q1",
"merkle_root": "<SHA-256 Merkle root>",
"document_count": 15000000,
"total_tokens": 1200000000000,
"license_attestation": {
"all_licensed": true,
"license_types": ["CC-BY-4.0", "Apache-2.0", "public-domain"],
"audit_date": "2026-03-01T00:00:00Z"
},
"poison_screening": {
"method": "statistical_outlier_detection",
"screening_date": "2026-03-01T00:00:00Z",
"documents_flagged": 0
},
"timestamp": "2026-03-15T10:00:00Z",
"issuer": "training-pipeline-ca",
"signature": "<ECDSA-P256-signature>"
}
5.3. Inclusion Proofs
For any individual document, the provider can generate a Merkle
inclusion proof demonstrating that the document was part of the
attested corpus, without revealing the entire corpus. This
enables selective disclosure for audit and legal purposes.
6. Model Weight Signing
6.1. Weight Hashing
For models small enough to hash in their entirety:
weight_hash = SHA-256(concatenation of all weight tensors
in canonical order)
For large models where single-hash computation is impractical,
a per-layer Merkle tree is constructed:
layer_hash[i] = SHA-256(weight_tensor[i])
weight_merkle_root = MerkleRoot(layer_hash[0..N])
6.2. Signing Format
{
"attestation_type": "model_weights",
"version": "1.0",
"model_id": "gpt-4-turbo-2026-03-31",
"model_version": "2026.03.31",
"weight_hash": "<SHA-256 or Merkle root>",
"hash_method": "merkle_per_layer",
"layer_count": 96,
"parameter_count": 1800000000000,
"architecture": "transformer_decoder",
"training_attestation_hash": "<SHA-256 of training attestation>",
"training_run_id": "run-2026-q1-final",
"timestamp": "2026-03-20T00:00:00Z",
"issuer": "model-signing-ca",
"signature": "<ECDSA-P256-signature>"
}
The training_attestation_hash field links this attestation to
the training data attestation, creating the second link in
the chain.
7. Quantization Verification
7.1. Quantization Attestation
When a model is quantized (e.g., to GGUF, AWQ, or GPTQ format),
the quantization process produces an attestation:
{
"attestation_type": "quantization",
"version": "1.0",
"source_model_id": "gpt-4-turbo-2026-03-31",
"source_weight_hash": "<SHA-256 of full-precision weights>",
"source_weight_signature": "<signature from Section 6>",
"quantization_method": "gguf-q4_k_m",
"quantized_hash": "<SHA-256 of quantized file>",
"layer_manifest": [
{
"layer": "attention.0.weight",
"source_hash": "<SHA-256>",
"quantized_hash": "<SHA-256>",
"max_absolute_error": 0.0012,
"mean_squared_error": 0.00003
}
],
"model_weight_attestation_hash": "<SHA-256 of weight attestation>",
"quantization_tool": "llama.cpp-b4567",
"quantization_tool_hash": "<SHA-256 of quantization tool binary>",
"timestamp": "2026-03-25T00:00:00Z",
"issuer": "quantization-ca",
"signature": "<ECDSA-P256-signature>"
}
7.2. Error Bounds
The layer_manifest includes per-layer error metrics between the
full-precision and quantized weights. Verifiers can check that
error bounds are within acceptable tolerances. Abnormally high
errors on specific layers may indicate adversarial modification
during quantization.
Implementations SHOULD define maximum acceptable error thresholds
per quantization method. Quantized models exceeding these
thresholds SHOULD be rejected.
8. Deployment Attestation
When a model is deployed to an inference endpoint, the deployment
process generates a signed attestation binding the inference
signing key to the specific model:
{
"attestation_type": "deployment",
"version": "1.0",
"deployment_id": "deploy-gpt4t-us-east-001",
"model_id": "gpt-4-turbo-2026-03-31",
"weight_hash": "<SHA-256 of deployed weights>",
"weight_attestation_hash": "<SHA-256 of weight or quant attestation>",
"inference_key_id": "model-gpt4t-2026-03-31-001",
"inference_public_key": {
"kty": "EC",
"crv": "P-256",
"x": "<base64url>",
"y": "<base64url>"
},
"hardware_attestation": {
"platform": "nvidia-h100-confidential",
"attestation_quote": "<base64>"
},
"jwks_endpoint": "https://api.provider.com/.well-known/model-keys",
"deployment_timestamp": "2026-03-31T00:00:00Z",
"issuer": "deployment-ca",
"signature": "<ECDSA-P256-signature>"
}
The inference_public_key is the key that will sign all inference
outputs from this deployment. Publishing it via JWKS enables
consumers to verify outputs without contacting the provider
directly.
9. Inference Output Signing
9.1. Signing Process
For each inference request, the inference engine:
1. Generates the output (text, embeddings, structured data)
2. Constructs the signature payload:
{
"output_hash": "<SHA-256 of raw output bytes>",
"model_id": "gpt-4-turbo-2026-03-31",
"model_version": "2026.03.31",
"weight_hash": "<SHA-256 of deployed weights>",
"deployment_id": "deploy-gpt4t-us-east-001",
"key_id": "model-gpt4t-2026-03-31-001",
"timestamp": 1711900000,
"nonce": "<unique-per-request>",
"request_hash": "<SHA-256 of input prompt>",
"sequence_number": 847293
}
3. Signs the payload with the deployment's ECDSA P-256
private key.
4. Attaches the signature as HTTP headers:
X-Inference-Signature: <base64-DER-encoded signature>
X-Inference-Key-ID: model-gpt4t-2026-03-31-001
X-Inference-Model-ID: gpt-4-turbo-2026-03-31
X-Inference-Weight-Hash: sha256:a7c3f8e2...
X-Inference-Timestamp: 1711900000
X-Inference-Nonce: <unique-nonce>
X-Inference-Sequence: 847293
9.2. Streaming Responses
For streaming responses (Server-Sent Events), the signature
covers the complete accumulated output and is sent as the
final SSE event:
event: inference-signature
data: {"signature":"...","key_id":"...","timestamp":...}
Implementations MAY also sign individual chunks with running
hashes for incremental verification.
9.3. Input-Output Binding
When the request_hash field is present, the signature
cryptographically binds a specific input to a specific output.
This provides non-repudiation: the provider cannot deny
generating a specific output for a specific input, and the
consumer cannot claim a different input produced the output.
10. Key Management
10.1. Key Hierarchy
The framework uses a three-tier key hierarchy:
Tier 1 - Provider Root Key:
Long-lived (years). Stored in HSM with FIPS 140-3 Level 3+.
Signs Tier 2 keys. Published in provider's root JWKS.
Tier 2 - Model Signing Keys:
Medium-lived (months). Signs model weight attestations and
deployment attestations. One per model family.
Tier 3 - Inference Signing Keys:
Short-lived (days to weeks). Generated per deployment
instance. Signs inference outputs. Published in deployment
JWKS.
10.2. Key Rotation
Tier 3 keys SHOULD be rotated at least monthly. When a key
is rotated:
o The new key is added to the JWKS before use.
o The old key remains in the JWKS for a grace period
(RECOMMENDED: 30 days) to allow verification of recent
outputs.
o After the grace period, the old key is removed from the
JWKS but retained in the provider's archive for historical
verification.
10.3. Key Discovery
Consumers discover provider public keys via JWKS:
GET /.well-known/model-keys
The response follows RFC 7517 (JSON Web Key) with extensions
for model identity metadata.
10.4. Revocation
If an inference signing key is compromised:
o The key is immediately removed from the JWKS.
o A signed revocation notice is published at:
GET /.well-known/model-key-revocations
o Consumers checking the JWKS will not find the revoked key
and MUST reject outputs signed with it.
11. Verification Procedures
11.1. Inference Output Verification
A consumer verifying an inference output:
1. Extracts X-Inference-Key-ID from the response.
2. Fetches the provider's JWKS from /.well-known/model-keys.
3. Locates the key matching the key_id.
4. Reconstructs the signature payload from the response body
and headers.
5. Verifies the ECDSA signature.
6. Validates the timestamp is within an acceptable window
(RECOMMENDED: 300 seconds).
7. Validates the nonce has not been seen before.
8. Optionally validates the weight_hash against known-good
model versions.
11.2. Full Chain Verification
For full chain verification (e.g., for regulatory audit):
1. Verify the inference signature (Section 11.1).
2. Retrieve the deployment attestation for the deployment_id.
3. Verify the deployment attestation signature.
4. Verify the weight_hash in the deployment attestation
matches the inference signature's weight_hash.
5. Retrieve the model weight attestation referenced by the
deployment attestation.
6. Verify the model weight attestation signature.
7. Retrieve the training data attestation referenced by the
model weight attestation.
8. Verify the training data attestation signature.
9. Each step verifies that the hash reference in the current
attestation matches the actual hash of the referenced
attestation.
12. Integration with ATTP and MCPS
This framework integrates with the broader agent security
protocol suite:
o ATTP [draft-sharif-attp-agent-trust-transport]: Agent
passports carry a reference to the model's deployment
attestation when the agent uses a specific model.
Consumers can verify both the agent's identity and the
model's provenance.
o MCPS [draft-sharif-mcps-secure-mcp]: MCP tool call
responses can include inference signatures when the tool
invokes a model. The MCPS message signature covers both
the tool response and the embedded inference signature.
o Agent Audit Trail [draft-sharif-agent-audit-trail]:
Inference signatures are recorded in the hash-chained
audit trail, creating a tamper-evident log of which models
generated which outputs.
13. Regulatory Mapping
EU AI Act:
o Article 12 (Record-keeping): The attestation chain provides
cryptographic evidence of the complete model lifecycle.
o Article 13 (Transparency): Training data attestation
documents data sources and licensing.
o Article 15 (Cybersecurity): Per-inference signing protects
output integrity.
o Article 50 (AI system identification): Inference signatures
identify the specific model.
NIST AI 100-1 (AI Risk Management Framework):
o Map 1.1 (Context establishment): Deployment attestation
documents the operational context.
o Govern 1.3 (Processes and procedures): The attestation
chain provides verifiable process documentation.
EU Cyber Resilience Act:
o Connected product security: Models deployed as services
are products under the CRA; inference signing provides
the required security properties.
14. Security Considerations
o Side-channel attacks on signing keys: Mitigated by
hardware-secured key storage (HSM, TPM, TEE).
o Signing oracle attacks: An attacker with API access can
generate signed outputs for arbitrary inputs. Mitigated
by rate limiting and input-output binding.
o Merkle tree collision attacks: SHA-256 provides 128-bit
collision resistance, sufficient for current threat models.
o Quantum computing: ECDSA P-256 is not quantum-resistant.
Future revisions will define profiles for post-quantum
signature algorithms (ML-DSA per NIST FIPS 204).
o Attestation chain forgery: An attacker who compromises
the Tier 1 root key can forge the entire chain. Mitigated
by HSM storage and multi-party key ceremonies.
o Timestamp manipulation: Mitigated by integration with
trusted timestamping services (RFC 3161).
15. IANA Considerations
This document requests registration of the following HTTP
headers:
o X-Inference-Signature
o X-Inference-Key-ID
o X-Inference-Model-ID
o X-Inference-Weight-Hash
o X-Inference-Timestamp
o X-Inference-Nonce
o X-Inference-Sequence
This document requests registration of the following well-known
URI:
o /.well-known/model-keys
o /.well-known/model-key-revocations
16. References
16.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
RFC 2119 Key Words", BCP 14, RFC 8174,
DOI 10.17487/RFC8174, May 2017.
16.2. Informative References
[draft-sharif-attp-agent-trust-transport]
Sharif, R., "Agent Trust Transport Protocol (ATTP)",
Internet-Draft draft-sharif-attp-agent-trust-transport,
March 2026.
[draft-sharif-mcps-secure-mcp]
Sharif, R., "MCPS: Cryptographic Security Layer for
MCP", Internet-Draft draft-sharif-mcps-secure-mcp,
March 2026.
[draft-sharif-agent-audit-trail]
Sharif, R., "Agent Audit Trail Format",
Internet-Draft draft-sharif-agent-audit-trail,
March 2026.
[RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
"Internet X.509 Public Key Infrastructure Time-Stamp
Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161,
August 2001.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962,
June 2013.
[SIGSTORE] OpenSSF, "Model Signing with Sigstore",
https://openssf.org/blog/model-signing, 2025.
[CYCLONEDX] OWASP, "CycloneDX ML-BOM Capabilities",
https://cyclonedx.org/capabilities/mlbom/, 2025.
Authors' Addresses
Raza Sharif
CyberSecAI Ltd
London, United Kingdom
Email: contact@agentsign.dev
URI: https://cybersecai.co.uk