RATS A. Damodaran Internet-Draft Sovereign AI Stack Intended status: Standards Track 5 April 2026 Expires: 7 October 2026 The Prove-Transform-Verify (PTV) Protocol for Attested Agent Identity draft-anandakrishnan-rats-ptv-agent-identity-00 Abstract This document describes the Prove-Transform-Verify (PTV) protocol for hardware-anchored attestation of AI agent identity. PTV is designed to enable an agent to prove that it is running an authorized model and policy without exposing sensitive data. The protocol is intended to compose with existing RATS attestation mechanisms and to support exercise-time re-attestation requirements. The protocol defines a common envelope format (CBOR/CDDL), message types for attestation request/response, and a threat model that separates identity binding integrity from behavioral continuity. Behavioral continuity is treated as a separate requirement class addressed via exercise-time checks and execution receipts (e.g., SCITT composition), not by PTV alone. Example use cases include healthcare clinical decision support systems (CDSS), critical infrastructure industrial control systems (ICS/OT), and cross-border regulatory compliance scenarios. 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 7 October 2026. Damodaran Expires 7 October 2026 [Page 1] Internet-Draft PTV Attested Agent Identity April 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology and Definitions . . . . . . . . . . . . . . . 3 2. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Identity Binding Integrity . . . . . . . . . . . . . . . 4 2.2. Behavioral Continuity (Out of Scope for -01) . . . . . . 5 2.3. Exercise-time Freshness Requirement . . . . . . . . . . . 5 3. PTV Model and Roles . . . . . . . . . . . . . . . . . . . . . 5 3.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 5 3.2. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Deployment Models . . . . . . . . . . . . . . . . . . . . 6 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. CBOR/CDDL Envelope . . . . . . . . . . . . . . . . . . . 6 4.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 8 4.2.1. PTV_PROVE_REQ (Message Type 1) . . . . . . . . . . . 8 4.2.2. PTV_PROVE_RESP (Message Type 2) . . . . . . . . . . . 8 4.2.3. PTV_TRANSFORM_ATT (Message Type 3) . . . . . . . . . 8 4.2.4. PTV_VERIFY_RESULT (Message Type 4) . . . . . . . . . 9 4.3. Error Code Registry . . . . . . . . . . . . . . . . . . . 9 4.4. Performance Characteristics (Informative) . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5.1. Freshness and Replay . . . . . . . . . . . . . . . . . . 11 5.2. Zero-Knowledge Proof Mechanism . . . . . . . . . . . . . 11 5.3. Identity Misbinding . . . . . . . . . . . . . . . . . . . 11 5.4. Denial of Service . . . . . . . . . . . . . . . . . . . . 12 6. Interoperability and Future Work . . . . . . . . . . . . . . 12 6.1. EAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. Layering and Composition . . . . . . . . . . . . . . . . 12 6.3. SCITT and Execution Receipts . . . . . . . . . . . . . . 12 6.4. Execution Outcome Verification . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. Normative References . . . . . . . . . . . . . . . . . . . . 13 9. Informative References . . . . . . . . . . . . . . . . . . . 13 Damodaran Expires 7 October 2026 [Page 2] Internet-Draft PTV Attested Agent Identity April 2026 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction Current identity frameworks (OAuth 2.0, SPIFFE) establish workload identity but do not verify what model an agent is running or whether it follows authorized policies. This gap creates systemic risk: a compromised agent can generate unauthorized outputs while still presenting valid credentials. For example, in a clinical decision support system, a hospital may need cryptographic evidence that a diagnosis was produced by an approved model and policy set, without exposing patient records or model internals. Similarly, in an industrial control system, an operator may need cryptographic evidence that a safety-critical control action was generated by an authorized agent configuration, without exporting plant telemetry or proprietary control logic. The PTV protocol addresses this gap by binding agent identity to hardware roots of trust (TPM 2.0 or Secure Enclave) and using zero- knowledge proofs to attest to model integrity without exposing model weights or inference data. 1.1. Terminology and Definitions 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. Agent An autonomous software entity that performs tasks on behalf of a user or system. Attester The agent component responsible for generating cryptographic attestations about its state or actions. Verifier A system that validates cryptographic attestations received from Attesters without accessing underlying sensitive data. Relying Party A system that consumes attestation results to make authorization decisions. PTV Edge Proxy A trusted gateway that performs attestation on behalf of constrained devices lacking hardware roots of trust. Damodaran Expires 7 October 2026 [Page 3] Internet-Draft PTV Attested Agent Identity April 2026 Nonce A cryptographically random value used to prevent replay attacks. Triage Band A risk classification (ROUTINE, ZK_PROOF, BFT) that determines the attestation mechanism. Valid values are 0 (ROUTINE), 1 (ZK_PROOF), or 2 (BFT). Governance Pack A set of policies and compliance rules applied during attestation. Proof A zero-knowledge proof attesting to agent state. Sovereign Bound Metadata Jurisdiction and data residency metadata embedded in attestation chains that cannot be removed without invalidating the attestation. The corresponding envelope field is sovereign_bound, which contains the subfields jurisdiction, data_residency, and compliance. Hardware Root of Trust A tamper-resistant chip (TPM 2.0 or Secure Enclave) providing cryptographic evidence that software has not been altered since last attestation. 2. Threat Model 2.1. Identity Binding Integrity Identity binding integrity asks: "Is this the agent that was enrolled, and is the signer of this attestation trusted to hold the corresponding key?" PTV addresses this class of threats by: * binding attestation evidence to a hardware root of trust (e.g., TPM AK), * using nonce-based freshness to prevent replay, and * allowing policy-aware verification of configuration state. This corresponds to cryptographic identity continuity in the sense of the RATS Architecture [RFC9334]. A relying party that consumes a PTV attestation MAY treat it as an assertion about identity binding integrity only, unless additional mechanisms are in place. Damodaran Expires 7 October 2026 [Page 4] Internet-Draft PTV Attested Agent Identity April 2026 2.2. Behavioral Continuity (Out of Scope for -01) Behavioral continuity asks: "Is the enrolled agent still behaving within its attested envelope after context changes?" This version of PTV does not fully address this requirement class. In particular, PTV does not detect or mitigate: * behavioral drift after context compression or summarization, * model weight replacement or fine-tuning after enrollment, and * runtime drift from adversarial prompt injection or accumulated state corruption. A valid PTV attestation on a behaviorally-drifted agent is therefore a false signal of behavioral identity continuity. For high-stakes use cases such as clinical decision support systems (CDSS) and ICS/ OT, relying parties SHOULD treat behavioral continuity as a separate requirement. It can be partially addressed by combining PTV freshness with delegation provenance (e.g., HDP) and execution outcome verification (e.g., SCITT receipts). See Section 6. 2.3. Exercise-time Freshness Requirement For high-stakes deployments, relying parties SHOULD be able to demand fresh attestation at exercise time (per authorization decision), via an EAT nonce challenge or a PTV challenge-response, rather than relying solely on a credential issued at enrollment time. 3. PTV Model and Roles 3.1. Protocol Overview The PTV protocol operates through three phases: Agent Federation Hub Verifier | | | |--[1] PROVE---------------| | | - Generate proof | | | - Hash: Model+Metadata | | | | | | |--[2] TRANSFORM--------------->| | | - Forward Proof Only | | | | | |<-[3] VERIFY-------------------| | | - Validate Proof | | | - No Raw Data Exposed | Figure 1: PTV Protocol Sequence Diagram Damodaran Expires 7 October 2026 [Page 5] Internet-Draft PTV Attested Agent Identity April 2026 The three phases are as follows: * *PROVE:* The agent generates a cryptographic proof locally that a task was executed correctly on an authorized model. * *TRANSFORM:* Only the proof (not raw data) is transmitted to the central system. * *VERIFY:* The system validates the proof without accessing sensitive inputs. 3.2. Roles The PTV protocol defines four logical roles: * *Attester:* The agent generating attestations. May be a direct TPM-bound agent or a constrained device using an Edge Proxy. * *Verifier:* The system validating attestations. * *Relying Party:* The system consuming attestation results for authorization decisions. * *Edge Proxy:* An optional gateway performing attestation on behalf of constrained devices. 3.3. Deployment Models PTV supports two deployment models: * *Direct Mode:* The agent has a TPM 2.0 or TEE and generates proofs natively. * *Proxy-Assisted Mode:* The agent is a constrained device (e.g., legacy PLC, sensor) without a TPM. The PTV Edge Proxy performs attestation on its behalf. 4. Message Formats 4.1. CBOR/CDDL Envelope All PTV messages are encapsulated in a common envelope structure, serialized using CBOR [RFC8610]. The following CDDL rules define the envelope: Damodaran Expires 7 October 2026 [Page 6] Internet-Draft PTV Attested Agent Identity April 2026 triage-band = 0..2 ptv-envelope = { ptv_version: tstr, msg_type: ptv-msg-type, nonce: bstr, ? attester_id: tstr, ? sovereign_bound: { jurisdiction: tstr, data_residency: tstr, compliance: [* tstr] }, ? triage_band: triage-band, ? evidence: bstr, ? proof: bstr, ? policy: ptv-policy, ? result: ptv-result, ? behavior_fingerprint: bstr, ? timestamp: time, ? extensions: { * tstr => any } } ptv-msg-type = &( prove-req: 1, prove-resp: 2, transform-att: 3, verify-result: 4 ) ptv-policy = { ? audience: tstr, ? policy_uri: tstr, ? trust_domain: tstr, ? requirements: [* tstr] } ptv-result = &( success: 0, failure: 1, indeterminate: 2 ) The behavior_fingerprint field is OPTIONAL in this version. It is intended for deployments that adopt a SCITT-style execution receipt pattern. Its contents are opaque bytes with deployment-specific semantics; this version does not define normative processing rules. See Section 6.3 for discussion of related future work. Damodaran Expires 7 October 2026 [Page 7] Internet-Draft PTV Attested Agent Identity April 2026 In PTV_PROVE_RESP and PTV_TRANSFORM_ATT, exactly one of evidence or proof MUST be present. A message that contains neither or both MUST be rejected by the verifier. 4.2. Message Types 4.2.1. PTV_PROVE_REQ (Message Type 1) Sent by the relying party to request attestation. Contains a nonce and optional policy constraints. PTV_PROVE_REQ = { ptv_version: "1.0", msg_type: 1, nonce: bstr, ? policy: ptv-policy } 4.2.2. PTV_PROVE_RESP (Message Type 2) Sent by the attester in response to a prove request. Contains either evidence (for ROUTINE triage) or a proof (for ZK_PROOF triage). PTV_PROVE_RESP = { ptv_version: "1.0", msg_type: 2, nonce: bstr, attester_id: tstr, sovereign_bound: { jurisdiction: tstr, data_residency: tstr, compliance: [* tstr] }, triage_band: triage-band, (evidence: bstr // ROUTINE triage // OR proof: bstr), // ZK_PROOF triage ? behavior_fingerprint: bstr, timestamp: time } 4.2.3. PTV_TRANSFORM_ATT (Message Type 3) Sent by the Edge Proxy to the Verifier. Damodaran Expires 7 October 2026 [Page 8] Internet-Draft PTV Attested Agent Identity April 2026 PTV_TRANSFORM_ATT = { ptv_version: "1.0", msg_type: 3, nonce: bstr, attester_id: tstr, sovereign_bound: { jurisdiction: tstr, data_residency: tstr, compliance: [* tstr] }, triage_band: triage-band, (evidence: bstr // ROUTINE triage // OR proof: bstr), // ZK_PROOF triage timestamp: time } 4.2.4. PTV_VERIFY_RESULT (Message Type 4) Sent by the verifier to the relying party. PTV_VERIFY_RESULT = { ptv_version: "1.0", msg_type: 4, nonce: bstr, result: ptv-result, ? reason: tstr, ? audit_id: tstr, timestamp: time } 4.3. Error Code Registry The following error codes are defined for PTV attestation failures: Damodaran Expires 7 October 2026 [Page 9] Internet-Draft PTV Attested Agent Identity April 2026 +=============+==============+=================================+ | Code | Description | Recovery Action | +=============+==============+=================================+ | PTV_ERR_001 | TPM | Verify TPM 2.0 presence and | | | attestation | permissions | | | failure | | +-------------+--------------+---------------------------------+ | PTV_ERR_002 | Proof | Regenerate proof with correct | | | verification | inputs | | | failed | | +-------------+--------------+---------------------------------+ | PTV_ERR_003 | Jurisdiction | Check sovereign_bound against | | | mismatch | policy | +-------------+--------------+---------------------------------+ | PTV_ERR_004 | Quorum not | Retry with additional consensus | | | reached | nodes | +-------------+--------------+---------------------------------+ | PTV_ERR_005 | Envelope | Generate fresh attestation | | | expired | | +-------------+--------------+---------------------------------+ | PTV_ERR_006 | Nonce replay | Discard and request a new nonce | | | detected | generated according to the | | | | cryptographic randomness | | | | guidance in RFC 4086 [RFC4086]. | +-------------+--------------+---------------------------------+ | PTV_ERR_007 | Model hash | Update approved model list | | | not approved | | +-------------+--------------+---------------------------------+ Table 1: PTV Error Codes 4.4. Performance Characteristics (Informative) *Note:* The following figures are preliminary observations from a prototype implementation. They are provided for illustration only and are not normative requirements of the protocol. Damodaran Expires 7 October 2026 [Page 10] Internet-Draft PTV Attested Agent Identity April 2026 +==================+================+=====================+ | Metric | Observed Value | Conditions | +==================+================+=====================+ | Proof generation | ~187ms | Prototype, n=10,000 | | | | (illustrative) | +------------------+----------------+---------------------+ | Proof | <5ms | Single proof | | verification | | (prototype) | +------------------+----------------+---------------------+ | Raw proof size | <300 bytes | Groth16 (BN254) in | | | | prototype | +------------------+----------------+---------------------+ Table 2: Prototype Performance Observations 5. Security Considerations This section discusses security and privacy considerations for the PTV protocol. 5.1. Freshness and Replay All PTV attestations MUST include a nonce provided by the relying party or verifier. The nonce MUST be cryptographically random (see [RFC4086]) and MUST NOT be reused across attestation sessions. Timestamps SHOULD be included and checked against a deployment- specific freshness window (RECOMMENDED: less than or equal to 300 seconds). 5.2. Zero-Knowledge Proof Mechanism PTV is designed to be compatible with zero-knowledge proof systems but does not mandate a specific construction. The predicate being proven MUST be specified, for example: "the hash of the agent configuration matches an enrolled value". The zero-egress property of ZK-proofs aligns with Privacy by Design principles. Deployers SHOULD assess compliance with applicable regulations; this protocol is designed to facilitate such assessments but does not constitute legal certification. 5.3. Identity Misbinding Attestations SHOULD be bound to the specific agent instance using a hardware root of trust (TPM 2.0 or Secure Enclave). Software-only attestations are NOT RECOMMENDED for high-assurance deployments. Damodaran Expires 7 October 2026 [Page 11] Internet-Draft PTV Attested Agent Identity April 2026 5.4. Denial of Service Verifiers SHOULD implement rate limiting and proof caching to mitigate DoS attacks. 6. Interoperability and Future Work 6.1. EAT When Entity Attestation Tokens (EAT, [RFC9711]) are present, PTV evidence and proofs SHOULD map to EAT claims such as eat_nonce, swname, and swversion. PTV evidence/proofs are also intended to be usable within SEAT/ExPAT-style exported attestation mechanisms. A future revision of this document may define a concrete mapping. 6.2. Layering and Composition PTV is designed to compose with complementary protocols that address different parts of the agentic trust chain. Specifically: * PTV provides attested agent identity and model/policy binding at exercise time (the "who and what is running" layer), * The Human Delegation Provenance Protocol (HDP) [HDP] establishes signed delegation provenance anchored to a human principal (the "who authorized what" layer), and * SCITT-based execution receipts or Execution Outcome Verification (EOV) provide evidence of what the agent actually produced (the "what was done" layer). A natural composition point is for an EOV receipt to reference a hash of an HDP delegation record as its delegation token, rather than duplicating the full provenance chain. Future revisions of this document may describe concrete mappings once the HDP and EOV models stabilize. 6.3. SCITT and Execution Receipts PTV is intended to compose with SCITT as follows: * PTV/SEAT provide attested agent identity and state at exercise time, and * SCITT COSE_Sign1 statements carry execution receipts for actions with external effects. Three open standardization gaps remain, treated as future work: 1. A registered COSE header label for the behavioral fingerprint. 2. A standardized format for behavior probes / fingerprints. Damodaran Expires 7 October 2026 [Page 12] Internet-Draft PTV Attested Agent Identity April 2026 3. A live transparency service for cross-domain execution logs. 6.4. Execution Outcome Verification Execution outcome verification is treated as a separate concern from attestation. This version assumes that execution receipts, where needed, are carried by SCITT or a similar transparency mechanism. Delegation provenance protocols (for example HDP [HDP]) and execution-outcome attestation patterns are complementary to PTV and out of scope for this version. 7. IANA Considerations This document makes no requests of IANA. Future revisions may request registration of media types, OAuth parameters, or attestation method registries once the protocol design has stabilized. 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997, . [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", June 2005, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", May 2017, . [RFC8610] Bormann, C. and H. Birkholz, "CBOR Data Definition Language (CDDL)", June 2019, . [RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "Entity Attestation Token (EAT)", December 2024, . 9. Informative References [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation ProcedureS (RATS) Architecture", January 2023, . Damodaran Expires 7 October 2026 [Page 13] Internet-Draft PTV Attested Agent Identity April 2026 [HDP] Dalugoda, S., "Human Delegation Provenance Protocol (HDP): Cryptographic Chain-of-Custody for Agentic AI Systems", March 2026, . Author's Address Anandakrishnan Damodaran Sovereign AI Stack Email: ananda.krishnan@hotmail.com URI: https://github.com/anandkrshnn Damodaran Expires 7 October 2026 [Page 14]