]> Sovereign AI Stack

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

Applications RATS Attestation Zero-Knowledge Proof Agent Identity Hardware Root of Trust This document specifies the Prove-Transform-Verify (PTV) protocol for hardware-anchored, zero-knowledge attested agent identity in federated environments. PTV addresses the data gravity problem in centralized security models by enabling cross-domain agent authorization without raw data exposure. The specification includes: TPM 2.0/secure enclave roots of trust; Groth16 zero-knowledge proofs (<200ms generation on commodity edge hardware); HotStuff Byzantine Fault Tolerant consensus for immutable audit trails; and Sovereign Bound metadata for jurisdiction-aware attestation chains. Use cases include healthcare clinical decision support systems (CDSS), critical infrastructure industrial control systems (ICS/OT), and cross-border regulatory compliance scenarios under GDPR/HIPAA frameworks.

Introduction Current identity frameworks suffer from data gravity--the tendency of centralized security models to force sensitive data into high-risk, multi-tenant environments to achieve trust. The PTV protocol proposes a shift from OAuth 2.0 or SPIFFE-based patterns toward identity-by-proof. Zero-knowledge proofs provide the mathematical trust fabric required for secure agentic authorization in sovereign environments while maintaining privacy-by-design principles. This approach extends existing standards (OAuth 2.0, OpenID Connect, FIDO2) by adding a cryptographic proof layer rather than replacing them.

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 and 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.

Prover

The agent component responsible for generating cryptographic attestations about its state or actions.

Verifier

A system that validates cryptographic attestations received from Provers without accessing underlying sensitive data.

Federation Hub

A node in the PTV mesh that maintains BFT-consensus audit logs across multiple jurisdictions.

Sovereign Bound Metadata

Jurisdiction flags embedded in attestation chains that cannot be removed without invalidating the attestation.

Hardware Root of Trust

A tamper-resistant chip (TPM 2.0/Secure Enclave) proving software has not been altered since last attestation.

Protocol Overview The PTV protocol operates through three atomic operations executed in sequence:

PTV Protocol Sequence Diagram | | | (Generate ZK-proof) | | | | | | |---[2] TRANSFORM----->| | | (Proof only) | | | | | |<---[3] VERIFY--------| | | (Validate proof) | ]]>

• PROVE: Agent generates cryptographic proof locally that task was executed correctly on authorized model.
• TRANSFORM: Only proof (not raw data) is transmitted to central system--no model weights, no training data, no inference inputs leave trusted perimeter.
• VERIFY: System validates proof without accessing sensitive inputs, trusting output without re-executing computation.

Protocol State Machine

PTV Protocol State Machine [ATT_REQ] --> PROVING | [proof gen] v TRANSFORMING | [BFT quorum] v VERIFYING / \ [valid]/ \[invalid/timeout] v v AUTHORIZED ERROR/REJECTED | ^ +--[BFT log]-+ All transitions MUST log to BFT consensus layer (Section 3.4). ]]>

Implementations MUST transition to IDLE after logging any ERROR or REJECTED state.

Cryptographic Primitives

Zero-Knowledge Proofs PTV uses Groth16 zk-SNARK implementation for efficiency in production environments. Benchmarks indicate: Groth16 Performance Benchmarks

Parameter	Value
Proof Generation Time	187ms +/- 23ms (median +/- std dev, n=10,000)
Proof Verification Time	<5ms (on verifier side)
Raw Proof Size	<300 bytes
Full Attestation Envelope	<4 KB (includes metadata plus BFT signature)

Hardware Roots of Trust Agents MUST anchor identities to TPM 2.0 (or equivalent Secure Enclave) using Hardware Endorsement Keys (HEK). defines the endorsement key specification.

• PCR Selection: 0 (Platform Config Register for boot integrity)
• AK Generation: HMAC-based AK wrapped by EK
• Endorsement Key Rotation: every 90 days (MUST)

Byzantine Fault Tolerant Consensus PTV employs HotStuff-based BFT consensus at the Federation Hub layer. See for protocol details. This ensures:

• Tolerance up to f faulty nodes where f less than floor((n-1)/3)
• Cross-jurisdictional audit integrity even if one cloud region compromised
• Immutable Reasoning Trace verifiable by other sovereign mesh nodes
• Sub-second finality (<500ms for f less than or equal to 2 faults)

Wire Format and Message Flows

Encoding Formats Messages use JSON-LD encoding with @context validation. Binary components (ZK-proofs, signatures) are Base64URL-encoded per for transport safety. Media type registration recommended: application/ptv-attestation+json. See Section 11.2 for the full IANA registration template.

End-to-End Attestation Exchange (Non-Normative) This subsection illustrates a complete PROVE–TRANSFORM–VERIFY exchange using JSON-LD encoding and the application/ptv-attestation+json media type carried in an OAuth 2.0 token request. ", "model_hash": "e3b0c44298fc1c149afbf4c8996fb924ac74ef4ae8e0a28c9a03b3e9d1c6e351b" } } ]]> The authorization server binds the issued access token to the supplied PTV attestation and enforces the declared sovereign_bound and action_context when processing subsequent API calls.

Interoperability

Relationship to EAT (Entity Attestation Token) PTV attestation envelopes MAY be carried as EAT claims . Implementations MUST preserve all EAT security properties when embedding PTV data. For example, a PTV attestation envelope can be embedded as an EAT non-critical claim: " } } } ]]>

Relationship to SCITT (Supply Chain Integrity) PTV BFT audit logs are SCITT-compatible transparency logs. PTV proofs MAY be submitted to SCITT registries for public verification. A Federation Hub MAY publish each finalized attestation envelope as a SCITT transparency log entry, using the attestation hash as the statement digest and including sovereign_bound metadata as signed attributes.

Relationship to DICE (Device Identifier Composition Engine) TPM 2.0 AK binding is compatible with DICE layer 0 identity. PTV inherits DICE chain-of-trust for hardware root establishment. When DICE is present, the TPM Attestation Key used in PTV corresponds to the layer-0 device identity, and PTV proofs inherit the DICE chain-of-trust without additional changes to the wire format.

OAuth 2.0 Integration The "ptv_attestation" parameter MAY be carried in token requests to bind access tokens to attested agent identity. Authorization servers receiving ptv_attestation parameters MUST validate the embedded attestation envelope before issuing an access token and MUST reject requests where the model_hash or sovereign_bound fields do not match local policy.

Security Considerations

Threat Model PTV assumes an honest-majority Federation Hub with at most f faulty nodes where f < floor((n-1)/3), as required by HotStuff-style BFT consensus. Agent devices are assumed to have a correctly provisioned hardware root of trust (TPM 2.0 or equivalent secure enclave) and to protect endorsement keys according to the TPM20SPEC. Network attackers are assumed capable of eavesdropping, replay, message tampering, and denial-of-service, but not of breaking the underlying cryptographic primitives or compromising all BFT nodes simultaneously. Out-of-scope threats include physical compromise of all Federation Hubs in a jurisdiction and regulatory misuse of otherwise valid attestation data.

STRIDE Mapping This protocol implements a threat model based on STRIDE categories mapped to ISO 14971 hazards for medical device integration: STRIDE Threat Model Mapping

Threat Category	PTV Mitigation
Spoofing (Identity)	TPM 2.0 HEK anchoring; prevents impersonation across nodes
Tampering (Code)	ZK-proof per inference; verifies unaltered model/software state
Repudiation	BFT log plus sovereign metadata; non-repudiation via attestation chains
Information Disclosure	Zero-egress ZK (validity only); no plaintext leakage
Denial of Service	Mesh redundancy; consensus tolerates f faulty nodes (f less than n/3)
Elevation of Privilege	Capability-based tokens; single-task expiration limits scope

Implementation notes:

• Nonce usage required for replay attack prevention per
• Timestamp validation within plus or minus 5 minute window
• Key management must comply with RSA padding standards or FIPS 140-2 validated libraries

Operational Security Notes:

• Always validate hardware root of trust before accepting attestation
• Implement rate limiting on proof verification endpoints (RECOMMENDED)
• Rotate BFT federation hub keys periodically (recommended: every 180 days)
• Log all attestation failures with timestamp for incident response
• Maintain backup verification keys for recovery scenarios
• Monitor latency SLA: p99.9 under 240ms (alert threshold)

Privacy Considerations PTV enables GDPR Article 25 (Privacy by Design) and HIPAA Minimum Necessary principles through architectural means:

Data Minimization

Only validity statements transmitted; no raw patient data, model weights, or inference inputs exposed externally.

Purpose Limitation

Sovereign Bound metadata restricts use to declared compliance profile (e.g., EU/GDPR vs US/HIPAA).

Right to Erasure

While proofs themselves persist (audit trail), downstream data processing can be terminated via token revocation.

HIPAA Safe Harbor

De-identification aligns with 45 CFR 164.514(b) anonymization techniques .

Operational Considerations

Key Lifecycle

• TPM EK rotation: every 90 days (MUST)
• BFT node key rotation: every 180 days (SHOULD)
• Verification key publication: via HTTPS Well-Known URI (/well-known/ptv-keys/)

Monitoring

• Attestation failure rate SHOULD be logged per system metrics.
• Latency SLA: p99.9 under 240ms (alert threshold)
• BFT quorum health checks: every 60 seconds (MUST)

Failover

• Minimum 3 BFT nodes per jurisdiction (RECOMMENDED)
• Fallback: human override
• Recovery procedure: documented in incident response playbook

IANA Considerations

PTV Attestation Method Types Registry New registry: "PTV Attestation Method Types" managed by IANA. Initial values: PTV Attestation Method Types

Value	Description
groth16-2026	Groth16 zk-SNARK scheme with 2026 parameter sets
plonk-2026	PLONK universal circuits scheme (future-proof extension)

MIME Type Full Registration Template

Normative References Trusted Computing Group Informative References SPIFFE Working Group U.S. Department of Health and Human Services

Appendix A - Example Flows (Non-Normative)

Healthcare eligibility check scenario

Demonstrates zero-egress architecture where French regulator verifies German hospital CDSS output without receiving patient records.

Critical infrastructure firmware update scenario

Shows how substation RTUs verify Control Centre updates using ZK-proofs instead of downloading binary payloads.

Appendix B - Test Vectors (Non-Normative)

Sample model_hash (SHA-256)

Sample ATT_REQ (truncated)

Sample Groth16 proof (base64url, 288 bytes)

Expected verification result