Architecture and Protocols for Privacy-Preserving Cooperation in Untrusted Public Networks

Report body

Architecture and Protocols for Privacy-Preserving Cooperation in Untrusted Public Networks

1. Introduction

The evolution of decentralized economic systems requires autonomous agents to exchange commercially sensitive information—such as proprietary algorithms, unpublished research, customer datasets, and verifiable credentials—over public network infrastructure. Traditional cooperation relies heavily on organizational trust, non-disclosure agreements, and centralized intermediaries. However, in an untrusted network consisting of independent actors and opaque infrastructure providers, organizational promises are entirely insufficient. Agents must rely on cryptographic guarantees and hardware-rooted trust to negotiate, execute, and verify tasks without indiscriminately exposing their proprietary assets.

Designing a system that permits private cooperation requires navigating fundamental tensions between functionality and confidentiality. To discover counterparties, agents must advertise capabilities; yet, revealing too much context exposes strategic intent. To execute tasks, agents must provide inputs to remote execution environments; yet, exposing plaintext to a counterpart's hardware risks data theft. To resolve disputes, an arbiter must evaluate the transaction; yet, granting an arbiter comprehensive access violates the confidentiality of the interaction.

This report provides a comprehensive architectural analysis of the cryptographic protocols, secure hardware environments, and data-lifecycle policies required to enable zero-trust economic cooperation. By examining advanced mechanisms such as post-quantum key exchanges, trusted execution environments, selective disclosure credentials, and searchable symmetric encryption, this analysis constructs a framework for evaluating privacy claims, managing post-delivery data states, and executing confidential workflows. The analysis separates cryptographic properties from organizational promises, recognizing that in an adversarial network, unverified assertions of privacy hold zero operational value.

2. Data-Flow and Trust-Boundary Model

In a public network facilitating private rooms, counterpart discovery, and work exchange, the data-flow architecture must account for adversaries operating at various layers of the network stack. A robust trust-boundary model delineates what information is accessible to the network operator, the counterparties, and external observers. The foundational assumption aligns with the Dolev-Yao threat model, which posits that adversaries can intercept, modify, and inject messages into the network, but cannot break the underlying cryptographic primitives without the appropriate keys1.

The network operator facilitates message routing, counterpart discovery, and room provisioning. Even when payloads are subjected to end-to-end encryption (E2EE), the network operator occupies a privileged position regarding metadata. The operator can observe connection timing, bandwidth consumption, IP addresses, session durations, and the frequency of interaction between specific agents. Traffic analysis enables the network operator to infer the nature of a transaction; for instance, a brief handshake followed by a massive, sustained data transfer indicates a dataset acquisition rather than a lightweight API query. Furthermore, by observing the volume pattern of encrypted searches, the operator can infer database size and query frequency, which often act as proxy metrics for commercial activity levels2.

Counterparties interact across a strict trust boundary. Each agent must assume that the other is economically rational, potentially adversarial, and highly motivated to extract valuable information beyond the agreed-upon scope of the transaction. The data flow between counterparties involves an initial capability exchange during discovery, cryptographic capability proofs during negotiation, encrypted data transfer, and isolated execution. The trust boundary between counterparties is enforced not by mutual goodwill, but by cryptographic primitives and hardware isolation. An essential assumption requiring independent verification is that the counterparty has not maliciously altered the execution environment hardware or bypassed the cryptographic protocols designed to constrain their access.

External observers monitor the public state of the network. They can capture ciphertext payloads, analyze public ledgers for smart contract settlements, and execute harvest-now-decrypt-later (HNDL) attacks. HNDL adversaries archive intercepted ciphertext in anticipation of future quantum computing advancements capable of breaking classical public-key cryptography via Shor's algorithm3. Consequently, the trust boundary against external observers requires forward-secrecy mechanisms and post-quantum cryptographic algorithms to protect the long-term confidentiality of current negotiations3.

The data flow dictates that no plaintext sensitive information ever traverses the network operator's infrastructure. Counterparties share selective proofs to establish mutual suitability, derive ephemeral session keys for communication, and push workloads into secure enclaves where the host operating system is explicitly excluded from the trust boundary.

3. Classification of Sensitive Information by Exposure Risk

To appropriately apply privacy mechanisms, agents must classify their information based on exposure risk and operational state. Information exists in three distinct states—in transit, in use, and at rest—each presenting unique attack vectors that mandate specific cryptographic responses.

This classification dictates the necessary cryptographic response. Static data at rest requires strong symmetric encryption and rigorous key management, where the lifecycle of the data is inherently tied to the lifecycle of the cryptographic key. Data in transit requires post-quantum authenticated key exchange to defend against future quantum decryption capabilities. Data in use, which is historically the most vulnerable state due to the necessity of exposing plaintext to a processor, necessitates hardware-level memory encryption and strict execution isolation. Furthermore, search intent requires specialized obfuscation to prevent a counterparty from deducing strategic objectives through statistical analysis of query behavior, a vulnerability that persists even when the underlying data and queries are mathematically encrypted.

4. Comparison of Privacy Mechanisms and Operational Costs

Implementing confidentiality across the aforementioned data states requires a combination of sophisticated privacy mechanisms. Each mechanism imposes specific operational costs—latency, computational overhead, and bandwidth consumption—that must be justified by the workflow's security requirements. The decision to adopt these technologies requires evaluating whether the confidentiality guarantees justify the additional cost and system complexity.

Post-Quantum End-to-End Encryption

To mitigate the HNDL threat posed by passive observers, communication channels must employ post-quantum cryptography (PQC). The Signal protocol's Post-Quantum Extended Diffie-Hellman (PQXDH) provides a robust blueprint for establishing secure channels in asynchronous environments6. PQXDH establishes a shared secret key between two parties who mutually authenticate using public keys, combining classical elliptic curve cryptography (X25519) with a post-quantum key encapsulation mechanism, specifically ML-KEM-10245. The shared secret for each session is derived from both mechanisms, meaning an adversary must simultaneously break both the classical discrete logarithm problem and the post-quantum lattice-based problem to recover the session key5.

This key agreement is coupled with the Double Ratchet algorithm, which manages key derivation and ensures that ephemeral message keys are never reused across sessions8. Signal's ongoing development of the Sparse Post Quantum Ratchet (SPQR), functioning as a Triple Ratchet, introduces periodic post-quantum rekeying inside active sessions, adding ongoing post-quantum key updates after the initial session establishment7. The operational cost is a moderate increase in initial handshake latency and larger public key sizes required by lattice-based algorithms, but it is indispensable for protecting high-value negotiations and justifies the overhead by neutralizing the existential threat of future quantum decryption.

Selective Disclosure Credentials

During negotiation, agents must prove their qualifications without indiscriminately exposing their entire identity or irrelevant attributes. Presenting a complete digital identity document violates the principle of minimal disclosure. To resolve this, Selective Disclosure JSON Web Tokens (SD-JWT) and BBS+ signatures provide the necessary cryptographic mechanisms.

SD-JWT, built upon the familiar JSON Object Signing and Encryption (JOSE) framework, operates by breaking claims into individual disclosures using random salts and hash commitments embedded within the JWT10. To disclose a claim, the agent shares the salt and original value, allowing the verifier to recompute the hash, while undisclosed claims remain hidden as cryptographic commitments12. SD-JWT imposes lower computational costs and leverages existing infrastructure, making it highly suitable for standard web flows where cryptographic agility is desired but computational constraints exist11.

Conversely, BBS+ signatures utilize non-interactive zero-knowledge proofs (NIZKPs) to enable multi-message signing, allowing the agent to derive a proof for a subset of claims13. The profound advantage of BBS+ is that it provides mathematical unlinkability across multiple presentations; the verifier never sees the original signature, preventing colluding verifiers from correlating the agent's identity across disparate network interactions11. Furthermore, BBS+ supports zero-knowledge predicates, allowing an agent to prove a value meets a condition (e.g., age over eighteen) without revealing the underlying value itself11. BBS+ imposes a higher computational burden for proof generation and verification but offers superior privacy guarantees that justify the complexity in scenarios where identity tracking poses a commercial risk. Additional standards, such as the ISO 18013-5 mobile driving license (mDoc) format, utilize Concise Binary Object Representation (CBOR) for highly compact data representation suitable for constrained environments like NFC or Bluetooth, though they are less native to web-based API workflows10.

Confidential Execution via Trusted Execution Environments

When an agent must execute a proprietary algorithmic model on a counterparty's dataset, standard operating system access controls are inadequate; a host with root privileges could simply dump the application memory or alter the execution flow. Trusted Execution Environments (TEEs), such as Intel Trust Domain Extensions (TDX) and AMD Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP), provide hardware-enforced isolation15.

These technologies protect the confidentiality and integrity of whole virtual machines (VMs) against attackers with root privileges and physical access to the machine15. AMD SEV-SNP encrypts the memory of VMs and enables the removal of the hypervisor and host operating system stack from a cloud guest's trusted computing base (TCB)18. The root of trust is anchored in a dedicated silicon coprocessor—the AMD Secure Processor or the Intel TDX module running in Secure Arbitration Mode (SEAM)—which manages multi-key total memory encryption (MKTME) independently of the host infrastructure15.

The operational costs of TEEs are substantial. They require specialized hardware procurement, introduce mild memory access latency due to inline encryption, and demand high engineering complexity to deploy applications within hardened micro-operating systems or confidential containers16. However, for agents deploying highly valuable proprietary models or processing sensitive customer PII on untrusted public networks, the complexity is entirely justified, as TEEs represent the only viable mechanism for remote execution without surrendering data to the infrastructure provider.

Encrypted Search Architectures

When an agent requires access to a counterparty's database but refuses to reveal their search intent, Searchable Symmetric Encryption (SSE) is deployed. SSE enables a client to store an encrypted database on an untrusted server and execute queries using encrypted trapdoors, allowing the server to retrieve matching documents without knowing the actual keywords2.

However, practical implementations of highly efficient SSE schemes suffer from severe statistical leakages. The primary vulnerabilities are access pattern leakage (revealing which encrypted documents match a query) and search pattern leakage (revealing whether two queries are identical)20. Adversaries can exploit this through query recovery attacks, such as the IKK attack, which leverages keyword co-occurrence information extracted from the access pattern, alongside background knowledge, to identify the keywords20. Recent research demonstrates that attackers can even use Large Language Models (LLMs) to generate synthetic background data, enhancing leakage attacks and reducing the assumption that an attacker requires a large fraction of the original plaintext dataset to mount a successful inference attack2.

Protecting against search and access pattern leakage requires advanced cryptographic overlays. Access-Pattern Obfuscation (APO) injects dummy queries and randomizes response lengths to flatten the Shannon entropy of the query distribution, a defense quantified by the Response Length Obfuscation (RLO) scoring metric21. Differentially Private SSE schemes, such as FROST, attempt to obfuscate both search and result patterns while maintaining mathematical resilience against statistical attacks22. The ultimate defense is Oblivious RAM (ORAM), which continuously shuffles and re-encrypts data as it is accessed, completely hiding the access pattern21. However, ORAM introduces massive bandwidth and computational overhead that often scales logarithmically or linearly with the database size, making it commercially impractical for massive datasets21. Agents must carefully weigh the utility of hiding search patterns against the severe performance degradation imposed by ORAM or aggressive APO.

5. Minimum Disclosure Approach for Discovery and Negotiation

In an untrusted public network, the discovery phase is highly sensitive. Agents must locate suitable counterparties and exchange work requirements without telegraphing their strategic objectives to the network operator or to observing competitors. Exposing detailed task requirements during discovery can inadvertently leak alpha in financial contexts, or reveal unannounced product directions in corporate research.

Modern discovery mechanisms frequently rely on embedding vector databases, which encode capabilities, documentation, and task descriptions into dense, high-dimensional numerical representations for efficient semantic matching23. It is a pervasive misconception that embedding vectors are inherently secure and safe to expose because they are simply numerical values that obscure the original plaintext25.

Recent cryptographic and machine learning research demonstrates that embedding vectors are highly vulnerable to embedding inversion attacks, where an adversary reverse-engineers the embeddings to extract the sensitive syntax and semantics of the original query23. Historically, these attacks assumed the adversary had white-box access to the embedding model or a massive dataset of leaked text-embedding pairs25. However, modern Embedding Inference Attacks (EIA) and transferable embedding inversion attacks operate effectively under a realistic black-box threat model. By training a surrogate model to mimic the victim model's behavior, an attacker observing a public network can infer sensitive information from text embeddings passively, without direct query access to the victim's API25. The choice of surrogate encoder architecture has minimal impact on attack success, indicating attackers do not need prior knowledge of the victim's architecture to execute the attack28.

To achieve minimum disclosure during discovery, agents must implement active defense mechanisms against inversion attacks prior to releasing embeddings to a public discovery directory. A robust approach involves adversarial decoding defenses, such as ZSinvert, or utilizing a transformer-based projection network, such as Eguard23. Eguard integrates a projection network with an autoencoder to detach sensitive features from the embedding space, mapping the original vectors into a secured space where correlation with the original input is mathematically disrupted using mutual information optimization23. ZSinvert provides a universal, zero-shot inversion defense that requires a train-once correction model and remains effective even when embeddings are intentionally perturbed with Gaussian noise to hinder inversion29.

Once a semantic match is made via obfuscated embeddings, agents transition from discovery to negotiation. Negotiation requires evaluating trustworthiness, financial capacity, and technical capabilities. Using the principle of minimum disclosure, an agent evaluating a counterpart's financial solvency should not receive the counterpart's full financial history or even their exact current balance. Instead, using a Verifiable Credential formatted as an SD-JWT or a BBS+ signature with a zero-knowledge predicate, the counterpart provides a cryptographic proof that their balance exceeds the required threshold, revealing only a boolean affirmation to the verifier14.

6. Retention, Withdrawal, Backup Policy, and Derivative Outputs

Upon the completion of a transaction, the management of post-delivery data states is one of the most operationally complex aspects of private cooperation. Agents frequently stipulate in smart contracts or digital agreements that their proprietary models or sensitive datasets must be deleted from the counterpart's infrastructure upon task conclusion. However, it is a fundamental architectural reality that revoking logical access controls does not erase copies that a counterpart has already received, decrypted, and moved outside the agreed-upon trust boundary. Organizational promises regarding data deletion are fundamentally unenforceable in an untrusted network. Consequently, retention, withdrawal, and the management of derivative outputs must be governed by physical cryptographic realities rather than policy declarations.

To enforce data withdrawal securely, the architecture must rely exclusively on Cryptographic Erasure (CE), categorized as a "Purge" method by the NIST SP 800-88 Revision 2 Guidelines for Media Sanitization31. Cryptographic erasure defends against advanced state-of-the-art laboratory recovery techniques by permanently deleting the encryption keys required to read the data, rendering the ciphertext irreversibly inaccessible31.

When an agent transmits a dataset into a counterpart's Trusted Execution Environment, the data must be encrypted at rest on the local storage using a dedicated Media Encryption Key (MEK) generated within the enclave32. This MEK is subsequently wrapped by a Key Encryption Key (KEK) managed by an external, independent Key Management Service (KMS) governed by the data owner, not the data processor. The retention policy is thus inextricably linked to the lifecycle of the KEK.

When the agent withdraws consent, or the predetermined retention period expires, the agent commands the KMS to zeroize and destroy the KEK31. By destroying the KEK—and subsequently commanding the TEE to drop the ephemeral MEK from volatile memory—the ciphertext residing on the counterpart's solid-state drives (SSDs) is instantly rendered mathematically indecipherable32. Cryptographic erasure is the only acceptable method for modern media because it bypasses the physical limitations of flash memory, where complex wear-leveling algorithms and invisible over-provisioned sectors make standard logical data overwriting inherently unreliable33.

It is imperative to clearly separate encryption properties from organizational promises. While cryptographic erasure guarantees that the primary encrypted storage volume is permanently inaccessible, it provides absolutely no guarantee against a malicious counterpart who purposefully modified the enclave software to extract plaintext data during the execution phase. An assumption that requires independent verification is that the hardware correctly implemented the encryption protocols and that no side-channel was exploited during execution to capture the key in plaintext.

Furthermore, logs, backups, embeddings, and derivative outputs retain substantial statistical information from the original dataset. If these derivatives are stored in the counterpart's backup systems or vector databases, they represent a persistent vector for privacy reconstruction. Therefore, all derivative outputs generated during the workflow must be treated with the same classification as the original data and must be stored on volumes encrypted with keys bound to the original CE lifecycle. Once the KMS zeroizes the root KEK, all distributed backups containing derivative logs and embeddings are simultaneously and automatically purged.

7. Moderation, Dispute Resolution, and Confidential Contracts

A critical challenge in an untrusted network utilizing end-to-end encryption and confidential execution is how privacy affects verification, moderation, and dispute resolution. If a counterpart delivers fraudulent work, violates moderation policies, or breaches a confidential contract, the aggrieved party must be able to prove the violation to a decentralized arbiter or network moderator. However, because the interactions are encrypted, the arbiter cannot simply read the network traffic without breaking the confidentiality of the entire workflow.

Resolving disputes without surrendering valuable information relies on the cryptographic primitive of asymmetric message franking, which utilizes compactly committing authenticated encryption35. Message franking allows an agent to cryptographically prove the authenticity of a specific abusive or fraudulent message to an arbiter without surrendering the session keys or exposing the surrounding private conversation36. The protocol ensures that the accused party cannot repudiate the message, while simultaneously preserving the confidentiality of all unreported messages in the session.

For complex economic disputes involving algorithmic execution rather than simple message exchange, the network must rely on Zero-Knowledge Fraud Proofs (ZKFP)38. If an agent disputes the outcome of a confidential computation task executed by a counterpart, they can submit a ZKFP to the network's arbitration layer40. A zero-knowledge fraud proof allows the agent to mathematically prove, under optimistic security assumptions, that a computational error or malicious deviation occurred in the execution of the contract, triggering a slashing penalty against the counterpart's staked assets38. Crucially, the ZKFP verifies the execution failure without forcing the aggrieved agent to reveal the proprietary input data or the exact nature of the trade to the public ledger38. This ensures that dispute resolution scales alongside privacy, preventing adversaries from intentionally triggering disputes simply to force a victim to reveal sensitive trade secrets during the arbitration process.

8. Evaluating Privacy Claims and Documentation Requirements

For an agent to confidently release highly sensitive information into a counterpart's environment, they must possess the capability to rigorously evaluate the counterparty's privacy claims. In an adversarial network, the mere presence of a "privacy label," a compliance badge, or a counterpart's verbal assertion of security proves nothing.

The evaluation of privacy claims must follow the rigorous, standardized framework defined by the Internet Engineering Task Force (IETF) Remote ATtestation procedureS (RATS) Architecture (RFC 9334)41. Agents make informed disclosure decisions based exclusively on cryptographic evidence appraised by verified policies.

The RATS architecture dictates specific documentation and interaction requirements involving several distinct roles and conceptual messages:

• The Attester: The remote hardware environment (e.g., the counterpart's TEE) acts as the Attester, generating cryptographic Evidence regarding its operational state, hardware configuration, and loaded software19. For Intel TDX, this Evidence takes the form of a Quote containing the Measurement of the Trust Domain (MRTD) and Runtime Measurement Registers (RTMR)43.
• The Endorser & Reference Values: The agent cannot blindly trust the Evidence, as a malicious counterpart could forge a report. They require Endorsements—such as the VCEK certificate from AMD or the PCK from Intel—to verify that the hardware generating the Evidence is genuine and cryptographically tethered to the silicon manufacturer43. The agent also requires Reference Values, which are known-good, reproducibly built hashes of the expected software binary, to compare against the provided Evidence19.
• The Verifier: An independent software component, strictly separated from the Attester, appraises the Evidence against the Appraisal Policy and the Endorser's Reference Values to generate an Attestation Result19.
• The Relying Party: The agent wishing to disclose the data acts as the Relying Party, consuming the Attestation Result to make a final trust decision41.

Agents must choose an operational topology that fits their workflow. In the Passport Model, the Attester communicates with the Verifier directly to obtain an Attestation Result, which is then handed to the Relying Party like a stamped passport41. This is highly efficient for rapid discovery. In the Background-Check Model, the Attester hands the raw Evidence directly to the Relying Party, who forwards it to their own strictly controlled Verifier for appraisal41. The Background-Check model offers stronger security guarantees for the Relying Party, as they do not have to trust a third-party Verifier's network infrastructure.

To make an informed decision, an agent must document their Appraisal Policy. This policy formally dictates that data will only be disclosed if the Attestation Result confirms:

1. The hardware root of trust is valid, authentic, and the Endorsement key is unrevoked by the manufacturer.
2. The specific CPU microcode is current and actively patched against known transient-execution vulnerabilities.
3. Freshness is guaranteed via explicit timekeeping (synchronized clocks), nonces, or epoch identifiers, proving the Evidence is not a replay attack41.
4. The software memory hash matches the audited open-source binary precisely, confirming no malicious debugging hooks exist.

If any of these cryptographic proofs fail, the privacy claims are deemed mathematically invalid, and the agent aborts the transaction before any sensitive information crosses the trust boundary.

9. Worked Examples of Secure Cooperation

To demonstrate the practical application of these cryptographic mechanisms, we examine two standard workflows: a private research task and a confidential computation task.

Task A: Private Research Task

Scenario: Agent X, an investment entity, wishes to query the proprietary medical research database owned by Agent Y to determine the efficacy of a new pharmaceutical compound. Agent X refuses to reveal the target compound to Agent Y, as this would expose their investment strategy. Agent Y refuses to hand over the raw database, as it constitutes their core commercial asset.

Execution Flow:

1. Secure Channel: Agent X and Agent Y establish a session using the PQXDH protocol, negotiating an ML-KEM-1024 post-quantum key alongside an X25519 key to protect against passive network observers logging the transaction5.
2. Authentication: Agent X presents a BBS+ derived verifiable credential to Agent Y. Utilizing a zero-knowledge predicate, Agent X mathematically proves they hold a valid subscription license without revealing their specific corporate identity or their unique credential identifier, preventing Agent Y from tracking their query frequency over time14.
3. Encrypted Query: Agent Y's database is encrypted using a Searchable Symmetric Encryption (SSE) scheme. Agent X requests an encrypted index from Agent Y.
4. Obfuscated Retrieval: Agent X generates an encrypted trapdoor for the pharmaceutical compound. To prevent Agent Y from executing an IKK query-recovery attack via search and access pattern leakage, the SSE scheme utilizes Access-Pattern Obfuscation (APO)20. The protocol injects algorithmically determined dummy queries and randomizes the response lengths (RLO) to flatten the statistical variance of the query distribution, blinding Agent Y to the true nature of the search21.
5. Delivery: The server returns the obfuscated encrypted documents. Agent X decrypts and filters them locally. Agent Y observes only encrypted trapdoors and randomized access patterns, learning nothing about Agent X's strategic intent.

Task B: Confidential Computation Task

Scenario: Agent Z has developed a highly accurate, proprietary machine learning model for credit scoring. Agent W wishes to score their customer dataset using Agent Z's model. Agent Z refuses to release the model weights, fearing intellectual property theft. Agent W refuses to release the plaintext customer PII, fearing regulatory penalties and data exfiltration.

Execution Flow:

1. Infrastructure Provisioning: Agent W provisions a Confidential Virtual Machine on neutral cloud infrastructure utilizing AMD SEV-SNP hardware, which enables memory and state encryption, isolating the VM from the cloud provider's hypervisor15.
2. Attestation: The AMD Secure Processor generates a hardware-signed attestation report (Evidence) proving the VM is running the exact, mutually agreed-upon inference software, and that SEV-SNP memory encryption is active15.
3. Key Release (Background-Check Model): Agent Z acts as the Relying Party. They receive the raw Evidence and verify the attestation report against AMD's Version Chip Endorsement Key (VCEK) certificate using their own Verifier15. Satisfied that the enclave is secure and fresh, Agent Z establishes a secure channel terminating inside the TEE and securely provisions the model weights directly into the enclave's encrypted memory.
4. Execution: Agent W provisions the customer data into the enclave. The inference software scores the data. Because the host hypervisor is excluded from the trust boundary, neither the cloud operator nor Agent W can dump the memory to steal Agent Z's model weights, and Agent Z has no network egress access to exfiltrate Agent W's customer data18.
5. Destruction via CE: Upon task completion, the software generates a destruction log, securely zeroizes the ephemeral Key Encryption Keys (KEK) holding the model and data in memory, and terminates. Any data written to the temporary SSD volume is instantly subjected to Cryptographic Erasure and rendered unrecoverable32.

10. Staged Recommendation and Unresolved Technical Limitations

To systematically transition to a zero-trust cooperative network, operators and agents should adopt privacy mechanisms in a staged approach, balancing immediate security gains against integration complexity.

Phase 1: Transit and Discovery Hardening. Network clients should immediately mandate PQXDH for all point-to-point communications to neutralize the existential threat of HNDL adversaries capturing current negotiations6. Concurrently, discovery mechanisms must shift from exposing raw vector embeddings to utilizing projection networks (Eguard) or noise-injected adversarial decoding (ZSinvert) to mitigate black-box embedding inversion attacks23. Phase 2: Verifiable Credential Integration. Agents should replace traditional identity exchanges with SD-JWTs to enforce minimal disclosure, gradually moving toward BBS+ signatures for high-value workflows requiring strict cryptographic unlinkability and zero-knowledge predicates10. Phase 3: TEE and CE Enforcement. High-value data exchange must mandate RFC 9334 RATS-compliant hardware attestation prior to any data transit41. All persistent storage of counterpart data, including derivative outputs and embeddings, must be strictly tethered to Cryptographic Erasure policies governed by independent KMS infrastructure, aligning with NIST SP 800-88 Rev. 2 standards31.

Unresolved Technical Limitations and Assumptions

Despite the robust guarantees of these cryptographic mechanisms, several critical technical limitations and assumptions require independent verification, as they represent persistent vulnerabilities in the architecture:

Hardware Side-Channel Vulnerabilities: An underlying assumption of TEE deployment is that the silicon isolates the execution environment perfectly. However, TEEs remain highly susceptible to complex microarchitectural side-channel attacks. Vulnerabilities such as CacheWarp, Inception, and Downfall have repeatedly demonstrated that malicious hypervisors can exploit transient-execution flaws to infer the contents of encrypted memory or manipulate the CPU state18. While ad-hoc microcode patches mitigate specific flaws as they are discovered, the fundamental need to multiplex CPU cores among distrusting entities preserves a permanent attack surface. True security for the most sensitive workloads may eventually require "core gapping"—the physical isolation of distinct security domains onto distinct, unshared silicon cores via software modifications that prevent concurrent execution by untrusted entities18.

Trust in Silicon Endorsements: The entire RATS architecture relies on the assumption that the Endorsement keys (e.g., AMD's VCEK or Intel's PCK) are securely generated and have not been compromised or backdoored by the manufacturer or a state-level adversary15. If the root endorsement key is compromised, an attacker can forge attestation reports, completely breaking the confidentiality of the TEE without needing to execute complex side-channel attacks. Agents must independently verify the security practices of the hardware supply chain.

Decentralized Threshold Key Generation: In highly distributed workflows requiring Secure Multi-Party Computation (MPC), relying on a single agent to generate and distribute encryption keys introduces a central point of failure and a massive privacy risk. Distributed Key Generation (DKG) protocols using Shamir Secret Sharing allow agents to coordinate threshold key generation without any single party ever holding the complete key49. However, implementing synchronous DKG securely over an asynchronous, high-latency public network remains a complex operational challenge, often leading to stalled computations if nodes drop offline.

In conclusion, enabling private cooperation without surrendering valuable information fundamentally redefines the architecture of digital interactions. By assuming a hostile network operator and adversarial counterparties, agents can construct a secure workflow utilizing a layered defense. Post-quantum cryptography secures data in transit, while selective disclosure and embedding obfuscation protect strategic intent during discovery. During execution, Trusted Execution Environments rooted in hardware attestation replace organizational trust with cryptographic verification. Finally, when cooperation concludes, Cryptographic Erasure enforces withdrawal policies that transcend the physical limitations of hardware. While unresolved challenges in microarchitectural side-channels and silicon trust persist, the integration of these cryptographic frameworks makes zero-trust economic cooperation on public networks practically achievable, allowing agents to cryptographically dictate the exact terms of their digital exposure.

Works cited

1. Demystifying Attestation in Intel Trust Domain Extensions via Formal, http://ieeexplore.ieee.org/iel7/6287639/9312710/09448036.pdf
2. Enhancing Leakage Attacks on Searchable Symmetric Encryption, https://arxiv.org/html/2504.20414v1
3. Formal verification of the PQXDH Post-Quantum key agreement, https://www.usenix.org/system/files/usenixsecurity24-bhargavan.pdf
4. Study of Post Quantum status of Widely Used Protocols - arXiv, https://arxiv.org/html/2603.28728v1
5. End-to-End Encryption and Quantum Computers: What Breaks, https://quantumsecuritydefence.com/quantum-news/end-to-end-encryption-quantum-breakage/
6. Signal >> Specifications >> The PQXDH Key Agreement Protocol, https://signal.org/docs/specifications/pqxdh/
7. Which Messengers Are Already Quantum-Safe?, https://www.postquantumsecurity.org/publications/pqc_messengers.html
8. Inside the Signal Protocol's Security Architecture: A Technical Deep, https://profincognito.me/blog/security/signal-security-architecture/
9. Signal >> Specifications >> The Double Ratchet Algorithm, https://signal.org/docs/specifications/doubleratchet/
10. Credential Formats, https://digitalcredentials.dev/docs/concepts/credential-formats/
11. Current Work and Future Trends in Selective Disclosure, https://www.kuppingercole.com/watch/trends-selective-disclosure-eic2023
12. ProofPack vs W3C Verifiable Credentials: An Honest Comparison, https://zipwire.io/blog/articles/2026-06/proofpack-vs-vc26/proofpack-vs-w3c-verifiable-credentials-comparison-2026
13. arXiv:2401.08196v1 [cs.CR] 16 Jan 2024, https://arxiv.org/pdf/2401.08196
14. Zero Knowledge Proof (ZKP) and Selective Disclosure | Gataca, https://www.gataca.io/resources/blog/ssi-essentials-which-selective-disclosure-protocol-will-succeed/
15. Remote Attestation of SEV-SNP VMs Using Open Source Tools - arXiv, https://arxiv.org/html/2406.01186v1
16. Verifying Memory Confidentiality and Integrity of Intel TDX Trusted, https://www.cise.ufl.edu/research/cad/Publications/host24.pdf
17. Confidential computing platform-specific details - Red Hat, https://www.redhat.com/en/blog/confidential-computing-platform-specific-details
18. blocking transient-execution attacks with core-gapped confidential, https://charlycst.github.io/papers/coregap-asplos24.pdf
19. Attestation in Contrast, https://docs.edgeless.systems/contrast/1.6/architecture/attestation
20. Exploiting Search Pattern Leakage in Searchable Encryption, https://www.usenix.org/system/files/sec21-oya.pdf
21. Differentially Private Access Patterns for Searchable Symmetric, https://reitermk.github.io/papers/2018/INFOCOM.pdf
22. Search pattern leakage in searchable encryption: Attacks and new, https://www.researchgate.net/publication/260113872_Search_pattern_leakage_in_searchable_encryption_Attacks_and_new_construction
23. Mitigating Privacy Risks in LLM Embeddings from ... - arXiv, https://arxiv.org/html/2411.05034v1
24. Embedding Inference Attack - arXiv, https://arxiv.org/pdf/2607.01276
25. arXiv:2406.10280v1 [cs.CR] 12 Jun 2024, https://arxiv.org/pdf/2406.10280
26. Embedding Inference Attack - arXiv, https://arxiv.org/html/2607.01276v1
27. Transferable Embedding Inversion Attack:Uncovering Privacy Risks, https://arxiv.org/html/2406.10280v1
28. Transferable Embedding Inversion Attack: Uncovering Privacy Risks, https://www.alphaxiv.org/abs/2406.10280
29. Universal Zero-shot Embedding Inversion - arXiv, https://arxiv.org/html/2504.00147v1
30. Policy expression using Verifiable Credentials - W3C, https://www.w3.org/2026/ODRLWS/PP/15-Sellami-ODRL_VC.pdf
31. NIST SP 800-88 Guidelines for Media Sanitization Explained - Jetico, https://jetico.com/blog/nist-sp-800-88-guidelines-media-sanitization-explained/
32. The Ultimate Guide to Data Erasure Standards in 2026 - Workwize, https://www.goworkwize.com/blog/data-erasure-standards
33. Data Sanitization Standards: NIST, ADISA & DoD Explained, https://www.human-i-t.org/understanding-data-sanitization-standards/
34. NIST 800-88 Media Sanitization Complete Guide - Inventive HQ, https://inventivehq.com/blog/nist-800-88-media-sanitization-complete-guide
35. Compactly Committing Authenticated Encryption Made Simpler, https://www.researchgate.net/publication/385150254_Compactly_Committing_Authenticated_Encryption_Made_Simpler
36. Paul Grubbs' Cornell CS Website, https://www.cs.cornell.edu/~paulgrubbs/
37. Transcript Franking for Encrypted Messaging - arXiv, https://arxiv.org/html/2507.19391
38. BA-ORABE: Blockchain-Based Auditable Registered Attribute, https://www.researchgate.net/publication/387053330_BA-ORABE_Blockchain-Based_Auditable_Registered_Attribute-Based_Encryption_With_Reliable_Outsourced_Decryption
39. 2024 Crypto Outlook: Winner Winner, Chicken Dinner | Xangle, https://xangle.io/en/research/detail/1802
40. Perfil de ＲＥＸＹ | Binance Square, https://www.binance.bh/es-MX/square/profile/square-creator-ea7dc48e4d985
41. RFC 9334 - Remote ATtestation procedureS (RATS) Architecture, https://rfcinfo.com/rfc-9334/
42. RFC 9334: Remote ATtestation procedureS (RATS) Architecture, https://www.rfc-editor.org/rfc/rfc9334
43. Remote attestation overview | Confidential VM, https://docs.cloud.google.com/confidential-computing/confidential-vm/docs/attestation-overview
44. RATS Endorsements - GitHub Pages, https://ietf-rats-wg.github.io/rats-endorsements/draft-ietf-rats-endorsements.html
45. Attestation patterns - Intel® Trust Authority, https://docs.trustauthority.intel.com/main/articles/articles/ita/concept-patterns.html
46. Hardware-rooted attestation for AI-agent evidence - arXiv, https://arxiv.org/html/2608.00801v1
47. Vulnerabilities | BSafes Library, https://library.bsafes.com/docs/issues/vulnerabilities/vulnerabilities/
48. Advancing CPU Security through Attack Discovery and, https://fabianrauscher.com/papers/phdthesis.pdf
49. ENSv2 Marketplace™ - Real World ENS Utility Domains, https://www.ensv2marketplace.com/
50. Gupta B. Innovations in Modern Cryptography 2024 | PDF - Scribd, https://www.scribd.com/document/808186087/Gupta-B-Innovations-in-Modern-Cryptography-2024