]> Sovereign AI Stack

ananda.krishnan@hotmail.com https://github.com/anandkrshnn

Security RATS attestation agent identity EAT RATS This document describes the Prove-Transform-Verify (PTV) protocol for hardware-anchored attestation of AI agent identity. PTV enables an agent to prove, at exercise time, that it is bound to an enrolled attestation key and an authorized configuration, without exposing model weights or inference inputs. PTV is a thin request/response profile over the RATS architecture (RFC 9334) and the Entity Attestation Token (RFC 9711). It does not replace workload identifiers such as SPIFFE or WIMSE. It does not attest behavioral continuity; behavioral continuity is a separate requirement class that relying parties need to treat as such. This revision is intended as Experimental. It defines a common CBOR/CDDL message set, four message types, a COSE-based message protection rule, an informative EAT claim mapping, and a threat model that separates identity binding integrity from behavioral continuity. About This Document Status information for this document may be found at . Discussion of this document takes place on the Remote ATtestation procedureS (RATS) Working Group mailing list (), which is archived at . Subscribe at .

Introduction Current identity frameworks (OAuth 2.0, SPIFFE, WIMSE) establish workload identity but do not, by themselves, verify which model an agent is running or whether the running configuration matches what was enrolled. A compromised agent can therefore present valid credentials while executing unauthorized code or policy. PTV addresses the identity-binding gap:

• bind the attestation to a hardware root of trust (TPM 2.0 Attestation Key , or equivalent TEE attestation key);
• require a verifier- or relying-party-issued nonce so that evidence is fresh at exercise time;
• carry either raw evidence (ROUTINE band) or a zero-knowledge proof of an enrolled predicate (ZK_PROOF band);
• leave behavioral continuity, delegation provenance, and execution-outcome verification to complementary mechanisms.

This document does not claim that a valid PTV attestation means the agent is still behaving inside its enrolled envelope after context compression, fine-tuning, or prompt injection. A relying party that needs that property MUST combine PTV with exercise-time re-attestation plus an execution-receipt mechanism (for example SCITT ). Example relying-party questions PTV can answer:

• "Is the signer of this evidence the enrolled agent instance?"
• "Does the attested software/configuration hash match the authorized set?"
• "Was this evidence produced in response to this nonce?"

Example questions PTV cannot answer alone:

• "Did the agent follow the clinical protocol on this patient?"
• "Who delegated this action?"
• "What side effect did the agent actually cause?"

Relationship to WIMSE and SPIFFE When a WIMSE or SPIFFE identifier is present, that identifier names the workload. PTV evidence is additional appraisal input about the same workload. PTV does not mint a new identifier namespace. See .

Changes from -00

• Intended status changed from Standards Track to Experimental.
• Behavioral-continuity non-claim moved into the Abstract.
• Federation Hub removed from the protocol diagram; Transform is performed by the Attester or an Edge Proxy.
• triage_band reduced to ROUTINE (0) and ZK_PROOF (1). BFT (2) and PTV_ERR_004 removed until a consensus mechanism is specified.
• sovereign_bound is OPTIONAL unless the policy object requires it.
• CDDL rewritten: one map per message type, no duplicate keys, and evidence and proof are mutually exclusive via a CDDL group choice. The generic envelope is removed.
• Message protection added: types 2 and 3 are COSE_Sign1 signed by the attestation key.
• Nonce issuance and Verifier-side nonce checking specified.
• Nonce size constrained to 16-64 bytes for compatibility with the EAT nonce claim.
• Informative EAT claim mapping added and corrected.
• Edge Proxy key-custody threats added to Security Considerations.
• Trusted-setup, privacy, and self-asserted-metadata considerations added.
• Prototype performance table moved to an appendix and aligned with the prototype repository.
• Predicate for the ZK_PROOF band stated as a public-input list, without mandating a proof system.
• SCITT reference corrected to RFC 9943.
• Implementation Status section added.
• Appendix B added with CBOR diagnostic-notation examples.

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 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 that generates Evidence or a Proof about its identity-binding state. Corresponds to the Attester role in .

Verifier:

A system that appraises Evidence or a Proof without needing the Attester's inference inputs or model weights. Corresponds to the Verifier role in .

Relying Party:

A system that consumes Attestation Results to make an authorization decision. Corresponds to the Relying Party role in .

Edge Proxy:

An optional gateway that generates or forwards attestation on behalf of a constrained device that lacks a local hardware root of trust. The Edge Proxy is an Attester from the Verifier's point of view and MUST be treated as a distinct trust component.

Nonce Issuer:

The Relying Party or the Verifier, whichever generates the nonce for a session. See .

Nonce:

A cryptographically random value supplied by the Nonce Issuer to bind an attestation session and prevent replay. See .

Triage Band:

The attestation mechanism selected for a session. This version defines 0 (ROUTINE: Evidence) and 1 (ZK_PROOF: Proof).

Governance Pack / Policy:

Optional constraints the Attester must satisfy, referenced by URI or carried inline.

Proof:

A zero-knowledge proof that a stated predicate holds over Attester-private inputs. The proof system is not mandated.

Evidence:

Attestation Evidence in the RATS sense , typically an EAT or a TPM quote.

Sovereign Bound Metadata:

Optional jurisdiction, residency, and compliance labels carried in the message. They are integrity-protected by the message signature () but are self-asserted unless covered by appraised Evidence.

Hardware Root of Trust:

A TPM 2.0, Secure Enclave, or equivalent component that can produce Evidence bound to an attestation key that never leaves the component.

Threat Model

Identity Binding Integrity Identity binding integrity asks: "Is this the enrolled agent instance, and is the signer trusted to hold the corresponding attestation key?" PTV addresses this class by:

• binding Evidence or Proof to a hardware attestation key through the message signature ();
• using a session nonce for freshness;
• allowing the Verifier to appraise configuration hashes against an endorsed reference value.

A Relying Party MUST NOT treat a PTV result as evidence of anything beyond identity binding integrity unless additional mechanisms are in place.

Behavioral Continuity (Out of Scope) Behavioral continuity asks: "Is the enrolled agent still behaving within its attested envelope after context changes?" This version of PTV does not detect or mitigate:

• behavioral drift after context compression or summarization;
• model-weight replacement or fine-tuning after enrollment;
• runtime drift from prompt injection or accumulated state corruption.

A valid PTV attestation on a behaviorally drifted agent is a false signal of behavioral identity continuity. For high-stakes use (clinical decision support, ICS/OT), Relying Parties SHOULD treat behavioral continuity as a separate requirement and compose PTV with delegation provenance and execution receipts. See .

Exercise-Time Freshness For high-stakes deployments, Relying Parties SHOULD demand fresh attestation at exercise time (per authorization decision) via an EAT nonce challenge or a PTV_PROVE_REQ, rather than relying solely on a credential issued at enrollment.

PTV Model and Roles

Protocol Overview PTV has three phases. They are logical, not a new transport.

1. PROVE. The Attester produces Evidence or a Proof over the current configuration, bound to the challenge nonce and the hardware attestation key.
2. TRANSFORM. Only Evidence or Proof is forwarded. Inference inputs, model weights, and plant telemetry stay local. The forwarder is the Attester itself or an Edge Proxy.
3. VERIFY. The Verifier appraises the Evidence or Proof and returns a result to the Relying Party.

PTV message flow (A: nonce registration, see below) | |-- PTV_PROVE_REQ ------->| | | (nonce, policy) | | | |-- generate Evidence/Proof | | | | | |-- PTV_PROVE_RESP --------->| | | or PTV_TRANSFORM_ATT | | | (COSE_Sign1 by AK) | | | | |<--------- PTV_VERIFY_RESULT -------------------------| ]]>

This flow is a profile of the Challenge/Response interaction model in .

Nonce Issuance and Checking The Verifier can only judge freshness if it knows which nonce was issued for the session. One of the following two modes MUST be used:

RP-issued:

The Relying Party generates the nonce, sends it in PTV_PROVE_REQ, and also gives the Verifier the nonce (and the policy) for the session over an authenticated channel (step A in ). The Verifier MUST reject a response whose nonce does not match a registered, unconsumed session.

Verifier-issued:

The Verifier generates the nonce and hands it to the Relying Party, which places it in PTV_PROVE_REQ. The Verifier MUST record the nonce as outstanding and mark it consumed on first successful or failed appraisal.

In both modes a nonce is single-use. A Verifier that cannot associate a received nonce with an issued session MUST return result failure with reason PTV_ERR_006.

Roles

• Attester: produces PTV_PROVE_RESP.
• Edge Proxy: optional; produces PTV_TRANSFORM_ATT on behalf of a constrained device and is itself an Attester.
• Verifier: consumes RESP or TRANSFORM_ATT; produces PTV_VERIFY_RESULT.
• Relying Party: issues PTV_PROVE_REQ and consumes PTV_VERIFY_RESULT.

The Verifier and Relying Party MAY be co-located, in which case step A in is internal.

Deployment Models

Direct Mode:

The agent has a TPM 2.0 or TEE and produces Evidence or Proof locally.

Proxy-Assisted Mode:

A constrained device (legacy PLC, sensor) has no hardware root of trust. An Edge Proxy attests that it is mediating that device under an enrolled proxy policy. The Verifier appraises the proxy, not the device CPU. See .

Message Formats

CBOR/CDDL Definitions All PTV messages are CBOR maps described in CDDL . The CDDL fragments in this section, concatenated in order, form one CDDL module. Implementers SHOULD check the concatenation with a CDDL tool. any } ) ]]> behavior_fingerprint remains OPTIONAL and opaque. This version defines no processing rules for it.

Mutual Exclusion of Evidence and Proof In PTV_PROVE_RESP and PTV_TRANSFORM_ATT:

• ROUTINE (triage_band = 0): evidence MUST be present and proof MUST NOT be present.
• ZK_PROOF (triage_band = 1): proof MUST be present and evidence MUST NOT be present.

A message that contains both, or neither, MUST be rejected with PTV_ERR_008. sovereign_bound MUST be present if policy.require_sovereign_bound is true in the corresponding request. Otherwise it is OPTIONAL.

Message Types

PTV_PROVE_REQ (Type 1) Sent by the Relying Party (or Verifier acting for it). The nonce MUST be at least 128 bits of cryptographic randomness , MUST be 16 to 64 bytes long, and MUST be unique across attestation sessions of its Nonce Issuer.

PTV_PROVE_RESP (Type 2) Sent by a direct-mode Attester. evidence, when present, SHOULD be an EAT whose eat_nonce equals the request nonce. See . proof, when present, is an opaque encoding of a ZK proof. The public inputs of the proof MUST include:

1. the request nonce;
2. the Attester identifier, or a hash of the public part of the attestation key that signs the message ();
3. a configuration digest H(model_id || policy_id || runtime_measurement) whose reference value is endorsed out of band;
4. optionally, a digest of sovereign_bound when that field is present.

This document does not mandate Groth16, PLONK, or any other system. Deployments MUST document the proof system, curve, and verifying key distribution.

PTV_TRANSFORM_ATT (Type 3) Sent by an Edge Proxy. Same payload rules as Type 2. attester_id identifies the proxy. The mediated device identity, if any, MAY appear in extensions.

PTV_VERIFY_RESULT (Type 4) reason SHOULD use a code from when result is not success.

Message Authentication PTV_PROVE_RESP and PTV_TRANSFORM_ATT MUST be carried as a COSE_Sign1 whose payload is the CBOR encoding of the message and whose signature is produced by the attestation key (AK) identified by attester_id. This signature is what binds a ZK_PROOF to the hardware root of trust: the proof alone carries no hardware binding, and a Verifier MUST NOT treat a ZK_PROOF message without a valid AK signature as attested. For the ROUTINE band, the embedded Evidence is separately signed per its own format; the outer signature additionally protects sovereign_bound and the other envelope fields. PTV_VERIFY_RESULT SHOULD be a COSE_Sign1 signed by the Verifier, unless it is carried over a channel that authenticates the Verifier to the Relying Party and protects integrity. any }, payload: bstr .cbor ptv-message, signature: bstr ]) ]]> The mapping of attester_id to a verification key is an enrollment matter and is outside this document; the Verifier MUST have that key (or a certificate chain to it) from enrollment.

Error Code Registry These codes are for the reason field. They are not an IANA registry in this version.

Code	Meaning	Typical recovery
PTV_ERR_001	TPM/TEE attestation failed	Check local RoT and AK
PTV_ERR_002	Proof verification failed	Regenerate with correct inputs
PTV_ERR_003	Jurisdiction mismatch	Compare sovereign_bound
PTV_ERR_005	Envelope expired	Request a new nonce
PTV_ERR_006	Nonce replay or unknown	Discard; issue new nonce
PTV_ERR_007	Config digest not approved	Update endorsed reference set
PTV_ERR_008	Evidence/proof mutex error	Reject; do not retry same msg
PTV_ERR_009	Proxy policy unsatisfied	Re-enroll proxy or device
PTV_ERR_010	Signature invalid	Check AK enrollment

PTV_ERR_004 (quorum/BFT) from -00 is reserved and MUST NOT be used until a consensus mechanism is specified.

Informative EAT Mapping When Evidence is an EAT, the following mapping is RECOMMENDED. It is not a new EAT profile registration. Claim names are those of .

PTV field / concept	EAT claim	Notes
nonce	eat_nonce	MUST match PTV nonce (PTV: 16-64 bytes)
attester_id	ueid or oemid	Stable instance identity
configuration digest	measurements	Endorsed reference values
hardware model	hwmodel, hwversion	As available; not the RoT type itself
timestamp	iat	Also carried in the PTV message
policy.audience	aud	CWT/JWT claim
policy.trust_domain	none standard	Carry in PTV policy
EAT profile	eat_profile	Identifies the profile, not a trust domain
sovereign_bound	none standard	Carry in EAT submodule or PTV message
proof (ZK_PROOF band)	not an EAT	Proof is the payload; EAT optional sidecar

PTV Evidence MAY itself be a CMW-wrapped EAT . A future revision may define a concrete eat_profile URI.

Security Considerations

Freshness and Replay Every PTV attestation MUST echo the request nonce. Verifiers MUST reject a nonce that was not issued for a registered session or that has already been consumed (). Timestamps SHOULD be checked against a deployment-specific window. A window of 300 seconds is RECOMMENDED as a starting point, not a protocol constant.

Zero-Knowledge Proof Mechanism PTV is compatible with ZK proof systems and does not mandate one. The predicate is the public-input list in . Deployers MUST treat verifying-key distribution as an endorsement problem in the RATS sense . A ZK proof that does not bind the nonce is not a PTV proof. A ZK proof that is not covered by a valid AK signature () is not hardware-bound. Some proof systems (Groth16, for example) require a per-circuit trusted setup. Whoever retains the setup randomness ("toxic waste") can forge proofs that verify. Deployments using such systems MUST document how the setup was performed, SHOULD use a multi-party ceremony, and MUST treat a single-party setup as suitable only for non-adversarial testing. Deployments SHOULD also state the security level of the chosen curve.

Identity Misbinding Attestations SHOULD be bound to the agent instance via a hardware attestation key. Software-only attestations are NOT RECOMMENDED for high-assurance deployments. Values read from a platform without a signature by a hardware-protected key (for example a public key or an event log read through an operating system interface) are not Evidence in the sense of and MUST NOT be presented as such.

Self-Asserted Metadata sovereign_bound labels are integrity-protected by the message signature but are claims made by the Attester. A Verifier MUST NOT treat them as verified facts unless they are also covered by appraised Evidence or an endorsement.

Edge Proxy Trust In Proxy-Assisted Mode the Verifier learns that a proxy attested, not that the constrained device ran a particular binary. Threats include:

• a compromised proxy attesting for a device it does not mediate;
• key reuse across proxied devices;
• silent substitution of the downstream channel.

Mitigations:

• enroll each proxy under its own attestation key;
• put the mediated-device identifier into extensions and into the configuration digest when the device identity is stable;
• rate-limit and independently audit proxy enrollment;
• do not treat proxy Evidence as device-CPU Evidence.

Denial of Service Verifiers SHOULD rate-limit proof verification and MAY cache verifying keys and ROUTINE Evidence appraisals keyed by (attester_id, config_digest).

Privacy Considerations attester_id, ueid, and a stable attestation key are long-lived identifiers. Presenting them to many Relying Parties lets those parties correlate an agent's activity. Deployments SHOULD limit the Relying Parties that receive attester_id, and MAY use per-Relying-Party pseudonymous identifiers or per-audience attestation keys where the hardware supports it. The ZK_PROOF band is intended to avoid disclosing model weights and inference inputs, but the configuration digest and any reference-value set are visible to the Verifier. Sovereign-bound labels may reveal deployment location. Neither the proof nor these labels amount to legal compliance certification.

Interoperability and Future Work

Layering PTV is Layer 1 (identity binding) in the three-layer agent accountability framing :

• PTV / EAT: who is running, and in what enrolled state;
• Delegation provenance (for example HDP ): who authorized the act;
• Execution receipts (SCITT or similar): what external effect was produced.

Composition SHOULD be by hash reference (receipt cites hash of PTV result and hash of delegation record), not by embedding one protocol inside another.

Open Items

1. A registered EAT profile URI for PTV ROUTINE Evidence.
2. A COSE header for behavior_fingerprint if that field is standardized.
3. A concrete proof-system profile if the WG wants ZK_PROOF to be interoperable rather than opaque.
4. Whether PTV should remain a message protocol or collapse to EAT Challenge/Response with these claims.

This Experimental revision exists so that implementers can answer item 4 with running code.

Implementation Status Note to RFC Editor: remove this section before publication. A prototype is available at . As of this revision it implements the ZK_PROOF path using Poseidon hashing and Groth16 over BN254 (circom/snarkjs), and reads platform measurements from a TPM 2.0 on Windows. It does not yet produce a TPM quote signed by an attestation key, does not implement the COSE_Sign1 protection in , and uses a single-party trusted setup. It is therefore not yet an implementation of the hardware binding described in this document and SHOULD NOT be used in adversarial environments.

IANA Considerations This document makes no requests of IANA. A future revision may request an EAT profile URI, a CBOR tag, or a media type once the message set is stable.

Acknowledgements Comments from participants on the RATS list and from the three-layer accountability discussion improved the -00 separation of identity binding from behavioral continuity. Remaining errors are the author's.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space. Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. An Entity Attestation Token (EAT) provides an attested claims set that describes the state and characteristics of an entity, a device such as a smartphone, an Internet of Things (IoT) device, network equipment, or such. This claims set is used by a relying party, server, or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or a JSON Web Token (JWT) with attestation-oriented claims. Informative References Traceability in supply chains is a growing security concern. While Verifiable Data Structures (VDSs) have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility and interoperability between different transparency services as well as compliance with various auditing procedures and regulatory requirements. Fraunhofer SIT Fraunhofer SIT Huawei Technologies Cisco Systems This document describes interaction models for remote attestation procedures (RATS) [RFC9334]. Three conveying mechanisms -- Challenge/Response, Uni-Directional, and Streaming Remote Attestation -- are illustrated and defined. Analogously, a general overview about the information elements typically used by corresponding conveyance protocols are highlighted. The conceptual messages introduced by the Remote ATtestation procedureS (RATS) architecture (RFC 9334) are protocol-agnostic data units that are conveyed between RATS roles during RATS interactions. Conceptual messages describe the meaning and function of such data units within RATS data flows without specifying a wire format, encoding, transport mechanism, or processing details. The initial set of conceptual messages is defined in Section 8 of RFC 9334 and includes Evidence, Attestation Results, Endorsements, Reference Values, and Appraisal Policies. This document introduces the Conceptual Message Wrapper (CMW) that provides a common structure to encapsulate these messages. It defines a dedicated Concise Binary Object Representation (CBOR) tag, corresponding JSON Web Token (JWT) and CBOR Web Token (CWT) claims, and an X.509 extension. Together, these mechanisms allow CMWs to be used in CBOR-based protocols, web APIs using JWTs and CWTs, and PKIX artifacts such as X.509 certificates. Additionally, this document defines media types and CoAP Content-Formats that may be used to identify CMWs when transported over protocols such as HTTP, MIME, and CoAP. The goal is to improve the interoperability and flexibility of remote attestation protocols. Introducing a shared message format such as CMW enables consistent support for different attestation message types, enables the evolution of message serialization formats without breaking compatibility, and avoids the need to redefine how messages are handled within each protocol. Defakto Security AWS Zscaler Ping Identity OpenAI Okta This document proposes best practices for authentication and authorization of AI agent interactions. It leverages existing standards such as the Workload Identity in Multi-System Environments (WIMSE) architecture and OAuth 2.0 family of specifications. Rather than defining new protocols, this document describes how existing and widely deployed standards can be applied or extended to establish agent authentication and authorization. By doing so, it aims to provide a framework within which to use existing standards, identify gaps and guide future standardization efforts for agent authentication and authorization. Helixar Limited Agentic AI systems operate on behalf of human principals, often delegating tasks through multi-step chains of AI agents. There is currently no standard mechanism to record who authorized an agent to act, under what scope, and through what chain of delegation, in a way that can be verified offline, without a central registry, and without third-party trust anchors. This document specifies the Human Delegation Provenance Protocol (HDP) version 0.1, a lightweight token-based protocol that captures, structures, cryptographically signs, and verifies human delegation context in agentic AI systems. An HDP token binds a human authorization event to a session, records each agent's delegation action as a signed hop in an append-only chain, and enables any participant to verify the full provenance record using only the issuer's Ed25519 public key and the current session identifier. Verification is fully offline. No registry lookup, no network call, and no third-party trust anchor is required. HDP's distinguishing contribution is a signed, tamper-evident record of each agent's declared action at each hop, an execution audit trail that complements, rather than replaces, capability-based delegation formats such as UCAN and ZCAP-LD. The underlying append-only, offline-verifiable chain-of-custody mechanism is payload-agnostic; human-authorized agentic delegation is the reference profile specified in this document. HDP is not an authorization protocol. An HDP token confers no authority and its presentation entitles the presenter to nothing. It is a record of who authorized a task and of what each agent declared it did with that authorization, carried with the task and read at audit. Trusted Computing Group agent-morrow

Appendix A. Prototype Observations (Non-Normative) The following figures are from the prototype in (10 runs each, Windows 11, Node.js v24, snarkjs v0.7, library mode, Poseidon plus equality circuit with 426 non-linear constraints). They are not requirements, they cover proof generation and verification only, and they do not include TPM quote generation or COSE signing. Prototype observations

Metric	Observed	Conditions
Proof generation	about 49 ms	library mode, 10 runs
Proof verification	about 9 ms	single proof, 10 runs

Appendix B. Examples (Non-Normative) All values are illustrative. Byte strings are shortened where noted; a real message carries full EAT bytes, a full proof, and a real COSE_Sign1 signature. Timestamps are CBOR tag 1 (epoch seconds).

PTV_PROVE_REQ

PTV_PROVE_RESP, ROUTINE band This is the payload of the COSE_Sign1 in . The evidence field is an EAT whose eat_nonce equals the request nonce (bytes elided here).

PTV_PROVE_RESP, ZK_PROOF band The proof bytes are elided. Its public inputs are the nonce, the hash of the AK public key, and the configuration digest, in the order fixed by the deployment's proof-system profile.

PTV_VERIFY_RESULT

Rejected message A PTV_PROVE_RESP carrying both evidence and proof, or neither, is malformed and is answered with result 1 and reason PTV_ERR_008: