Internet-Draft lake Intended status: standards-track March 2026 Expires: September 05, 2026 Privacy-Preserving Agent Learning Protocol for Federated Multi-Tenant Environments draft-agent-ecosystem-agent-learning-protocol-00 Abstract Federated learning enables distributed AI agents to collaboratively improve models without centralizing training data. However, existing federated architectures lack comprehensive privacy guarantees for multi-tenant environments where agents from different organizations must learn together while preventing data leakage. This specification defines the Privacy-Preserving Agent Learning Protocol (PPALP) that combines differential privacy, secure aggregation, and zero-knowledge proofs to enable federated agent learning with formal privacy guarantees. PPALP provides mechanisms for privacy-preserving model updates, tenant isolation enforcement, and cryptographic verification of privacy compliance. The protocol supports heterogeneous agent types while maintaining backward compatibility with existing federated learning frameworks. This work addresses critical privacy gaps in federated agent architectures and provides implementable solutions for secure cross-organizational AI collaboration. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document is intended to have standards-track status. Distribution of this memo is unlimited. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Privacy Budget A quantitative measure of the privacy cost incurred by releasing information about a dataset through differential privacy mechanisms Tenant Isolation The property that agent learning activities of one organizational tenant cannot infer private information about another tenant's data or models Secure Aggregation A cryptographic protocol that allows computation of aggregate statistics over distributed data without revealing individual contributions Gradient Inversion Attack An attack where an adversary attempts to reconstruct training data from shared gradient information in federated learning Privacy Compliance Verifier A system component that cryptographically verifies adherence to differential privacy guarantees and tenant isolation requirements Federated Coordinator The central entity responsible for orchestrating privacy- preserving model aggregation across multiple tenants in federated learning Table of Contents 1. Introduction ................................................ 3 2. Terminology ................................................. 4 3. Problem Statement ........................................... 5 4. Privacy-Preserving Agent Learning Architecture .............. 6 5. Differential Privacy for Agent Model Updates ................ 7 6. Secure Multi-Tenant Federated Aggregation ................... 8 7. Privacy Compliance and Verification ......................... 9 8. Protocol Message Formats and Flows .......................... 10 9. Security Considerations ..................................... 11 10. IANA Considerations ......................................... 12 11. References .................................................. 13 1. Introduction The rapid deployment of AI agents across organizational boundaries has created an urgent need for collaborative learning mechanisms that preserve privacy while enabling knowledge sharing. Traditional centralized machine learning approaches require data consolidation, which violates privacy regulations and organizational policies in multi-tenant environments where competing organizations must collaborate. Federated learning addresses data centralization concerns but existing protocols lack comprehensive privacy guarantees necessary for cross- organizational AI agent deployments. Current federated learning frameworks are vulnerable to gradient inversion attacks [draft- kale-agntcy-federated-privacy], membership inference attacks, and cross-tenant data reconstruction, making them unsuitable for privacy-sensitive multi-tenant agent learning scenarios. Multi-tenant federated agent learning presents unique challenges beyond traditional federated learning contexts. AI agents often process behavioral data, decision patterns, and strategic information that require stronger privacy protections than conventional machine learning datasets. The heterogeneous nature of agent types across organizations complicates model aggregation while maintaining meaningful learning outcomes. Existing privacy- preserving techniques such as differential privacy and secure aggregation, when applied independently, fail to provide comprehensive protection against sophisticated attacks targeting federated agent systems. Furthermore, regulatory compliance requirements such as GDPR's right to erasure and data processing transparency mandates necessitate cryptographic verification mechanisms that current federated learning protocols do not provide. This specification introduces the Privacy-Preserving Agent Learning Protocol (PPALP) to address critical privacy gaps in federated agent architectures while enabling secure cross- organizational AI collaboration. PPALP combines differential privacy mechanisms specifically calibrated for agent model parameters, secure multi-party computation for cross-tenant aggregation, and zero-knowledge proofs for cryptographic verification of privacy compliance. The protocol builds upon the Privacy-Preserving Reference Architecture defined in [draft-kale- agntcy-federated-privacy] and extends federated averaging mechanisms to support heterogeneous agent types with formal privacy guarantees. PPALP integrates with existing federated learning frameworks through standardized APIs while providing backward compatibility for legacy deployments. The protocol's contribution to AI agent standardization includes formal privacy accounting mechanisms that track privacy budget consumption across multiple learning rounds, tenant isolation enforcement that prevents cross-organizational information leakage, and cryptographic audit trails that enable regulatory compliance verification. PPALP addresses the critical need for standardized privacy-preserving protocols in federated agent learning by providing implementable solutions that balance collaborative learning benefits with stringent privacy requirements. The specification defines concrete message formats, communication flows, and security mechanisms necessary for production deployment of privacy-preserving federated agent learning systems in multi-tenant environments where traditional approaches fail to provide adequate protection. 2. Terminology This document defines terminology for privacy-preserving federated learning protocols in multi-tenant environments. 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 capable of learning and adapting its behavior through machine learning mechanisms, as defined in [draft-berlinai-vera]. In the context of this specification, agents participate in federated learning to improve their models collaboratively. Federated Agent Learning: A distributed machine learning paradigm where multiple AI agents collaboratively train shared models without centralizing their training data. Each agent maintains local data while contributing to global model improvement through privacy-preserving parameter sharing mechanisms. Privacy Budget: A quantitative measure of the privacy cost incurred by releasing information about a dataset through differential privacy mechanisms. The privacy budget, typically denoted as epsilon (ε), bounds the maximum privacy loss across all learning iterations and MUST be carefully managed to maintain formal privacy guarantees throughout the federated learning process. Differential Privacy: A mathematical framework that provides formal privacy guarantees by adding calibrated noise to computation outputs. In federated agent learning, differential privacy mechanisms ensure that the participation of any individual data point cannot be inferred from the released model parameters or gradients. Tenant: An organizational entity participating in federated learning with its own collection of agents, data, and privacy requirements. Tenants represent distinct administrative domains that require isolation guarantees while participating in collaborative learning protocols. Tenant Isolation: The property that agent learning activities of one organizational tenant cannot infer private information about another tenant's data or models. Tenant isolation MUST be maintained through cryptographic mechanisms and differential privacy guarantees to prevent cross-organizational data leakage. Secure Aggregation: A cryptographic protocol that allows computation of aggregate statistics over distributed data without revealing individual contributions. Secure aggregation protocols typically employ techniques such as homomorphic encryption or secure multiparty computation to ensure that only the aggregated result is revealed to participants. Federated Coordinator: The central entity responsible for orchestrating privacy-preserving model aggregation across multiple tenants in federated learning. The coordinator manages communication flows, enforces privacy policies, and coordinates the secure aggregation process while maintaining tenant isolation guarantees. Privacy Compliance Verifier: A system component that cryptographically verifies adherence to differential privacy guarantees and tenant isolation requirements. The verifier employs zero-knowledge proofs and audit mechanisms to ensure that all participants comply with established privacy policies without revealing sensitive information about their contributions. Gradient Inversion Attack: An attack where an adversary attempts to reconstruct training data from shared gradient information in federated learning. Such attacks exploit the information leakage inherent in gradient sharing and represent a primary threat that privacy-preserving protocols MUST defend against. Membership Inference Attack: An attack technique where an adversary attempts to determine whether a specific data point was used in training a machine learning model. In federated settings, these attacks can be used to infer information about individual agents' training data across tenant boundaries. Privacy Accounting: The process of tracking and managing privacy budget consumption across multiple learning rounds and operations. Privacy accounting mechanisms MUST ensure that the cumulative privacy loss remains within acceptable bounds throughout the entire federated learning process. Homomorphic Encryption: A cryptographic technique that allows computation on encrypted data without decrypting it first. In the context of secure aggregation, homomorphic encryption enables the computation of aggregate model parameters while keeping individual contributions encrypted. Zero-Knowledge Proof: A cryptographic protocol that allows one party to prove knowledge of information to another party without revealing the information itself. Zero-knowledge proofs are used in privacy compliance verification to demonstrate adherence to privacy requirements without exposing sensitive details about the verification process. 3. Problem Statement Federated agent learning in multi-tenant environments faces fundamental privacy leakage risks that existing protocols fail to adequately address. The core problem arises when AI agents from different organizations (tenants) participate in collaborative learning while sharing gradient updates or model parameters that inadvertently reveal sensitive information about their private training data. Unlike traditional federated learning scenarios with homogeneous participants, multi-tenant environments amplify privacy risks due to potentially adversarial relationships between tenants and the heterogeneous nature of agent architectures across organizational boundaries. The threat model for privacy-preserving federated agent learning encompasses three primary attack vectors that adversaries MAY exploit to compromise tenant data privacy. First, gradient inversion attacks allow malicious participants to reconstruct approximations of private training samples from shared gradient information, particularly effective when batch sizes are small or when attackers can observe multiple training rounds. Second, membership inference attacks enable adversaries to determine whether specific data points were used in another tenant's training dataset by analyzing model behavior or parameter updates. Third, cross-tenant data reconstruction attacks leverage correlations between multiple tenants' shared information to infer sensitive attributes about datasets belonging to other organizational participants, violating tenant isolation requirements. The privacy leakage problem is quantified through formal privacy metrics that MUST account for composition across multiple learning rounds and tenant interactions. Let ε represent the privacy budget expended per tenant per learning round, and δ represent the probability of privacy violation. The cumulative privacy cost grows with each parameter sharing event, and without proper privacy accounting mechanisms, the total privacy loss (εtotal, δtotal) MAY exceed acceptable thresholds defined by organizational privacy policies. Traditional differential privacy mechanisms designed for single-organization scenarios provide insufficient guarantees in multi-tenant federated settings where privacy budgets must be allocated across tenant boundaries and learning rounds while maintaining utility for collaborative model improvement. Building upon the AI Agent Structured Threat Model framework defined in [draft-berlinai-vera], federated agent learning environments face additional risks including compromised privacy compliance verifiers that MAY provide false attestations of differential privacy adherence, tenant gateway failures that could leak cross-tenant information, and coordination attacks where multiple tenants collude to circumvent privacy protections. The threat model assumes honest-but-curious federated coordinators who follow protocol specifications but MAY attempt to infer private information from aggregated data, and potentially malicious tenants who MAY deviate from prescribed privacy-preserving mechanisms to gain competitive advantages through unauthorized data access. The problem statement also addresses the challenge of maintaining privacy guarantees while supporting heterogeneous agent architectures with varying computational capabilities, privacy requirements, and trust assumptions. Agents operating under different privacy regulations (such as GDPR, CCPA, or sector- specific requirements) MUST be able to participate in federated learning while maintaining compliance with their respective privacy obligations. The protocol MUST provide mechanisms for cryptographic verification of privacy compliance, audit trails for regulatory reporting, and graceful degradation when privacy budgets are exhausted, ensuring that collaborative learning can continue while respecting individual tenant privacy constraints and maintaining the overall utility of the federated learning process. 4. Privacy-Preserving Agent Learning Architecture This section defines the Privacy-Preserving Agent Learning Protocol (PPALP) architecture, which integrates differential privacy, secure aggregation, and zero-knowledge proofs to enable federated learning across organizational boundaries while maintaining formal privacy guarantees. The architecture extends the Privacy-Preserving Reference Architecture framework [draft- kale-agntcy-federated-privacy] to specifically address agent learning scenarios in multi-tenant environments. PPALP employs a layered approach where privacy mechanisms are enforced at multiple architectural levels to provide defense-in-depth protection against information leakage. Tenant A Tenant B Tenant C +--------+ +--------+ +--------+ | Agent | | Agent | | Agent | | Local | | Local | | Local | | Model | | Model | | Model | +---+----+ +---+----+ +---+----+ | | | v v v +---+----+ +---+----+ +---+----+ | DP | | DP | | DP | | Noise | | Noise | | Noise | +---+----+ +---+----+ +---+----+ | | | +-------+-------+-------+------+ | | +----+-----+ +----+------+ | Secure | | Privacy | | Aggre- | | Compliance| | gation | | Verifier | +----------+ +-----------+ Figure 1: PPALP Federated Learning Architecture The PPALP architecture defines four primary component roles that collectively ensure privacy-preserving federated learning operations. The Federated Coordinator serves as the central orchestration entity responsible for managing global model state, coordinating aggregation rounds, and maintaining privacy budget allocations across all participating tenants. Tenant Gateways act as intermediary control plane entities, extending the Agent Gateway Control Plane concept [draft-li-dmsc-mcps-agw] to enforce tenant-specific privacy policies and manage agent authentication within organizational boundaries. Privacy Compliance Verifiers operate as independent auditing entities that cryptographically verify adherence to differential privacy guarantees and tenant isolation requirements through zero-knowledge proofs. Participating Agents represent the distributed learning entities that contribute model updates while consuming privacy budget allocated by their respective tenants. The architectural design enforces strict tenant isolation through cryptographic boundaries and policy enforcement mechanisms. Each tenant maintains an isolated privacy budget that cannot be influenced by other tenants' learning activities, ensuring that cross-tenant privacy guarantees remain intact regardless of adversarial behavior by other participants. Tenant Gateways implement the Federated Policy Enforcement framework [draft-cui- dmsc-agent-cdi] to harmonize local privacy policies with global federated learning requirements while preventing policy conflicts that could compromise privacy guarantees. All inter-component communications MUST use TLS 1.3 [RFC8446] with mutual authentication based on X.509 certificates [RFC5280] to prevent network-level attacks. The protocol supports heterogeneous agent types through a standardized privacy-preserving model update interface that abstracts underlying model architectures while ensuring consistent privacy accounting. Agents MUST register their learning capabilities and privacy requirements with their tenant's gateway, which negotiates appropriate differential privacy parameters with the Federated Coordinator. The architecture maintains backward compatibility with existing federated learning frameworks by implementing standard aggregation interfaces that can be secured through the PPALP privacy mechanisms without requiring modifications to existing agent implementations. Privacy accounting occurs at multiple architectural layers to provide comprehensive protection against composition attacks and privacy budget exhaustion. The Federated Coordinator maintains global privacy budget state and implements composition theorems to track cumulative privacy expenditure across learning rounds. Tenant Gateways enforce local privacy policies and MAY implement additional privacy amplification techniques such as subsampling to reduce privacy costs for their constituent agents. Privacy Compliance Verifiers continuously monitor privacy budget consumption and generate cryptographic proofs of compliance that can be audited by external parties without revealing sensitive learning parameters or model information. 5. Differential Privacy for Agent Model Updates This section specifies the differential privacy mechanisms that MUST be applied to agent model parameter updates to provide formal privacy guarantees in multi-tenant federated learning environments. All participating agents MUST implement differential privacy mechanisms that satisfy ε-differential privacy for a pre- negotiated privacy parameter ε, where smaller values of ε provide stronger privacy guarantees but may reduce model utility. The differential privacy implementation MUST use the Gaussian mechanism for continuous-valued parameters and the exponential mechanism for discrete-valued selections, calibrated to the global sensitivity of the learning algorithm as defined in [draft-kale- agntcy-federated-privacy]. Privacy budget allocation MUST be managed across multiple learning rounds to prevent privacy depletion over time. Each tenant MUST maintain a privacy budget tracker that accounts for the cumulative privacy cost across all federated learning rounds, where the total privacy cost is bounded by composition theorems. The system MUST implement advanced composition using the moments accountant method or Rényi differential privacy to achieve tighter privacy bounds than basic composition would allow. Privacy budgets SHOULD be allocated proportionally to the expected utility gain from each learning round, with mechanisms for tenants to reserve budget for future high-priority learning tasks. Noise calibration for model parameter updates MUST be performed based on the L2 sensitivity of the gradient computation, which is bounded through gradient clipping techniques. Before applying differential privacy noise, gradients MUST be clipped to a maximum norm C, where C is negotiated during protocol initialization based on the trade-off between privacy, utility, and convergence requirements. The Gaussian noise added to each parameter update MUST have variance σ² = 2C²ln(1.25/δ)/ε² for (ε,δ)-differential privacy, where δ represents the probability of privacy failure and MUST be set to be cryptographically negligible (typically δ ≤ 10⁻⁶). The protocol MUST maintain detailed privacy accounting across learning rounds using a standardized privacy ledger format that records the privacy cost of each operation. This ledger MUST track per-tenant privacy expenditure, cross-tenant privacy interactions, and cumulative privacy debt according to the composition theorems. The privacy accounting system MUST provide cryptographic proofs of privacy budget compliance that can be verified by Privacy Compliance Verifiers as specified in Section 7. When a tenant's privacy budget is exhausted, the system MUST either terminate that tenant's participation or implement privacy budget renewal mechanisms with appropriate cooling-off periods to prevent privacy budget laundering attacks. The differential privacy implementation MUST be compatible with the secure aggregation protocols defined in Section 6, ensuring that privacy guarantees are maintained even when combined with cryptographic operations. The noise addition process MUST occur before any cryptographic encoding for secure aggregation, and the protocol MUST verify that the combination of differential privacy and secure aggregation does not introduce additional privacy vulnerabilities through cryptographic side channels or timing attacks. All differential privacy parameters, including ε, δ, and clipping bounds, MUST be negotiated during the protocol handshake phase and cryptographically committed to prevent manipulation during the learning process. 6. Secure Multi-Tenant Federated Aggregation This section defines the cryptographic protocols that enable secure aggregation of model parameters across tenant boundaries while preserving privacy guarantees established in Section 5. The secure aggregation protocol MUST ensure that no individual tenant can learn information about other tenants' model updates beyond what is revealed by the final aggregated result. The protocol combines homomorphic encryption with secure multiparty computation techniques to achieve this property while maintaining computational efficiency suitable for practical federated learning deployments. Agent_i Aggregator Verifier | | | |--local grad--->| | | + DP noise | | | | | | [...N agents contribute...] | | | | | |--aggregate---->| | | model update | | | | | |<--ZK proof-----| | | compliance | |<--global upd---| | | | | Figure 2: Privacy-Preserving Aggregation Flow The Multi-Tenant Federated Averaging mechanism serves as the foundation for secure parameter aggregation. Each tenant's Privacy Compliance Verifier MUST encrypt their differentially-private model updates using a threshold homomorphic encryption scheme before transmission to the Federated Coordinator. The encryption MUST use a (t,n)-threshold scheme where t represents the minimum number of tenants required for decryption and n represents the total number of participating tenants. This ensures that no single tenant or coordinator can decrypt individual updates, while still enabling computation over encrypted parameters. The homomorphic encryption scheme SHOULD support both addition and limited multiplication operations to accommodate various neural network architectures commonly used in agent learning systems. The secure multiparty computation protocol proceeds in three phases: commitment, computation, and verification. During the commitment phase, each tenant generates a cryptographic commitment to their encrypted model update using a computationally-hiding and perfectly-binding commitment scheme. The Federated Coordinator collects all commitments and broadcasts them to participating tenants for verification. In the computation phase, tenants collaboratively execute a secure aggregation protocol that computes the weighted average of model parameters without revealing individual contributions. The protocol MUST be secure against up to t-1 malicious participants and SHOULD provide robustness against participant dropout through verifiable secret sharing techniques. Verification mechanisms ensure correctness of the aggregation process and detect potential manipulation attempts. Each participating tenant MUST verify the integrity of the aggregation using zero-knowledge proofs that demonstrate correct execution of the secure computation protocol. The ZKP-based Agent Attestation mechanism enables tenants to prove their compliance with the differential privacy requirements specified in Section 5 without revealing their actual noise parameters or model updates. These proofs MUST be verified by the Federated Coordinator and recorded in an immutable audit trail as specified in Section 7. Additionally, the protocol includes range proofs to verify that model parameter updates fall within expected bounds, preventing gradient manipulation attacks that could compromise model convergence or extract private information. The aggregation protocol MUST support heterogeneous agent types by normalizing model parameters to a common representation before encryption and aggregation. Tenants with different model architectures encode their updates using a standardized parameter mapping that preserves semantic meaning while enabling secure computation. The protocol SHOULD maintain backward compatibility with existing federated learning frameworks by providing adapter layers that translate between PPALP message formats defined in Section 8 and legacy federated learning APIs. Performance optimizations including parameter compression, selective aggregation of model layers, and asynchronous update mechanisms MAY be implemented provided they do not compromise the privacy guarantees established by the differential privacy and secure aggregation components. 7. Privacy Compliance and Verification Privacy compliance in federated agent learning environments requires cryptographic mechanisms that provide verifiable proof of adherence to differential privacy guarantees while maintaining audit capabilities for regulatory requirements. This section defines the Privacy Compliance and Verification framework that enables tenants to demonstrate privacy compliance without revealing sensitive implementation details or compromising the privacy of their learning processes. The framework combines zero- knowledge proofs, selective disclosure attestations, and cryptographic erasure mechanisms to provide comprehensive privacy verification capabilities. The Privacy Compliance Verifier MUST implement zero-knowledge proof protocols that allow federated agents to demonstrate differential privacy adherence without revealing actual noise values, data distributions, or model parameters. Following the SD- JWT Privacy-Preserving Trust Proof pattern from [draft-drake- email-tpm-attestation], the verifier SHALL use Selective Disclosure JWT mechanisms [RFC7519] to enable privacy-preserving attestation of compliance properties. Each participating agent MUST generate cryptographic proofs that demonstrate: (1) proper calibration of differential privacy noise according to the allocated privacy budget, (2) correct implementation of the Gaussian mechanism or equivalent noise generation, and (3) adherence to composition theorems across multiple learning rounds. These proofs MUST be constructed using non-interactive zero- knowledge proof systems such as zk-SNARKs or zk-STARKs that provide succinctness and efficient verification. Audit trail mechanisms MUST maintain cryptographically verifiable logs of all privacy-relevant operations while preserving the confidentiality of sensitive learning data. The audit system SHALL record privacy budget expenditures, aggregation operations, and tenant isolation boundary enforcement without logging actual model parameters or gradient values. Each audit entry MUST include a timestamp, tenant identifier, privacy budget allocation, and cryptographic hash of the differential privacy parameters used. The audit trail MUST support selective disclosure to authorized auditors while preventing unauthorized access to privacy-sensitive operational details. Privacy budget accounting MUST be maintained across all learning rounds with cryptographic commitments that prevent double-spending of privacy allocations. Cryptographic erasure capabilities MUST be implemented to address regulatory requirements for data deletion and agent memory cleanup as specified in [draft-gaikwad-aps-profile]. The system SHALL support cryptographic erasure of agent memory associated with specific user or agent identities through key destruction mechanisms that render associated encrypted data permanently inaccessible. When a deletion request is received, the Privacy Compliance Verifier MUST coordinate the erasure of all federated learning artifacts associated with the specified identity, including gradient histories, model update records, and privacy budget allocations. The erasure process MUST generate cryptographic proofs of deletion that demonstrate the irreversible destruction of the requested data across all participating federated nodes. Privacy compliance verification MUST support Privacy-Respecting Capability Attestation mechanisms that enable verification of agent privacy capabilities without revealing implementation- specific details. Following patterns from [draft-huang-rats- agentic-eat-cap-attest], agents MUST be able to attest to their differential privacy implementation capabilities, secure aggregation support, and tenant isolation enforcement without disclosing proprietary algorithms or security configurations. The attestation process SHALL use hardware-backed trust anchors where available, with fallback to software-based attestation for environments without trusted execution capabilities. All privacy compliance proofs and attestations MUST be timestamped and include validity periods to prevent replay attacks and ensure freshness of compliance claims. 8. Protocol Message Formats and Flows This section defines the concrete message formats, communication flows, and API definitions for the Privacy-Preserving Agent Learning Protocol (PPALP). All message exchanges MUST use JSON format as specified in [RFC8259] with UTF-8 encoding. Protocol implementations MUST support TLS 1.3 [RFC8446] for transport security and MUST authenticate using OAuth 2.0 [RFC6749] bearer tokens or X.509 certificates [RFC5280]. The protocol defines four primary message categories: initialization messages for establishing privacy parameters, update messages for transmitting differentially private model parameters, aggregation messages for secure multi-tenant computation, and verification messages for privacy compliance validation. The protocol message structure follows a common envelope format with mandatory header fields. Each message MUST include a "version" field specifying the PPALP protocol version, a "type" field indicating the message category, a "tenantid" field for tenant isolation enforcement, and a "timestamp" field using ISO 8601 format. Messages involving privacy budget allocation MUST include a "privacybudget" object containing epsilon and delta values as defined in Section 5. Security-critical messages such as model updates and aggregation requests MUST include a "signature" field containing a JWS signature [RFC7519] for message authentication and integrity verification. The federated learning session begins with a Privacy Parameter Negotiation flow initiated by the Federated Coordinator. The coordinator sends a "privacyinit" message specifying the global privacy budget, differential privacy mechanism, and aggregation method. Each Tenant Gateway responds with a "privacyaccept" message confirming participation and local privacy constraints. Model update flows use "modelupdate" messages containing encrypted differentially private gradients, privacy proof attestations, and secure aggregation shares. The Federated Coordinator processes these through "aggregationrequest" and "aggregation_response" messages that implement the secure multi-tenant aggregation protocol defined in Section 6. Privacy compliance verification occurs through dedicated message flows involving the Privacy Compliance Verifier component. Agents MUST send "privacyproof" messages containing zero-knowledge proofs of differential privacy adherence for each model update. The verifier responds with "compliancestatus" messages indicating verification success or failure with specific error codes. Audit trail generation uses "audit_log" messages that record privacy budget consumption, aggregation participation, and compliance verification events. All audit messages MUST be cryptographically signed and include tamper-evident sequence numbers for regulatory compliance. The protocol defines standardized error handling through HTTP status codes [RFC9110] and structured error responses. Privacy budget exhaustion MUST return HTTP 429 with a "privacybudgetexceeded" error code and remaining budget information. Tenant isolation violations MUST return HTTP 403 with detailed violation descriptions for security monitoring. Implementation-specific extensions MAY add custom message fields using the "extensions" object within the message envelope, provided they do not compromise privacy guarantees or tenant isolation requirements. Reference implementations MUST provide JSON Schema validation files and OpenAPI specifications for all message formats to ensure interoperability across different PPALP implementations. Example message flows demonstrate typical protocol interactions including session establishment, multi-round federated learning with privacy budget management, and graceful session termination with privacy compliance verification. The appendix includes complete JSON Schema definitions for all message types, sample message exchanges showing proper privacy parameter negotiation, and error handling examples covering common failure scenarios such as aggregation timeouts and privacy proof validation failures. 9. Security Considerations PPALP addresses multiple security threats present in multi-tenant federated learning environments through defense-in-depth mechanisms. The protocol MUST implement protections against gradient inversion attacks [RFC8446] by ensuring differential privacy noise addition occurs before any parameter sharing, with privacy budgets calculated according to composition theorems defined in Section 5. Membership inference attacks are mitigated through tenant isolation enforcement, where each tenant's Privacy Compliance Verifier cryptographically verifies that cross-tenant information leakage remains below specified epsilon-delta bounds. Model poisoning attacks are addressed through secure aggregation protocols that include Byzantine-fault-tolerant mechanisms and zero-knowledge proofs of honest participation. Key management in PPALP follows a hierarchical trust model where the Federated Coordinator maintains root cryptographic credentials, while each tenant operates independent key hierarchies for their agent populations. Tenant Gateways MUST establish mutually authenticated channels using TLS 1.3 [RFC8446] with certificate pinning, and rotate encryption keys according to the privacy budget consumption rate to ensure forward secrecy. The protocol supports both pre-shared keys for closed consortium deployments and public key infrastructure integration [RFC5280] for open multi-tenant scenarios. Cross-tenant cryptographic isolation MUST be maintained such that compromise of one tenant's keys cannot affect the privacy guarantees of other tenants' learning processes. Operational security considerations for multi-tenant deployments include audit logging of all privacy budget expenditures, secure deletion mechanisms for ephemeral cryptographic material, and side-channel attack mitigation. The protocol MUST log all differential privacy parameter selections, aggregation events, and privacy compliance verification results to enable post-hoc security analysis while ensuring these logs themselves do not leak private information. Network-level protections SHOULD include traffic analysis resistance through padding and timing obfuscation, particularly for Agent Gateway intercommunication as specified in [draft-han-rtgwg-agent-gateway-intercomm-framework]. Deployments MUST implement secure boot and attestation mechanisms for Privacy Compliance Verifiers to prevent tampering with privacy enforcement logic. The protocol provides resistance to collusion attacks through cryptographic commitment schemes and verifiable privacy budget accounting across multiple learning rounds. When tenant subsets attempt to correlate their local model updates to infer information about non-colluding tenants, the secure aggregation protocol ensures that only differentially private aggregate statistics are revealed. However, the protocol assumes honest-but- curious adversaries and MAY NOT provide protection against active adversaries who deviate from the protocol specification. Deployments requiring protection against malicious adversaries SHOULD implement additional verification mechanisms and consider reduced privacy parameters to account for adaptive attacks over multiple learning epochs. 10. IANA Considerations This document defines new protocol elements that require registration with the Internet Assigned Numbers Authority (IANA) to ensure interoperability and avoid conflicts with existing protocols. The Privacy-Preserving Agent Learning Protocol (PPALP) introduces novel message types, error codes, and protocol identifiers that extend existing federated learning and privacy- preserving computation frameworks as defined in [draft-kale- agntcy-federated-privacy]. IANA SHALL establish a new registry titled "Privacy-Preserving Agent Learning Protocol (PPALP) Parameters" under the "AI Agent Protocol Parameters" registry group. This registry SHALL contain three sub-registries: "PPALP Message Types", "PPALP Error Codes", and "PPALP Privacy Compliance Identifiers". The PPALP Message Types registry SHALL include entries for differential privacy update messages (DPUPDATE), secure aggregation requests (SECAGGREQ), secure aggregation responses (SECAGGRESP), privacy budget allocation messages (PRIVBUDGET), tenant isolation verification messages (TENANTVERIFY), and zero-knowledge proof submission messages (ZKPSUBMIT). Each message type SHALL be assigned a unique 16-bit identifier following the allocation policies specified in [RFC8259] for JSON-based protocol extensions. The PPALP Error Codes registry SHALL define error conditions specific to privacy-preserving federated learning operations. Required error codes include PRIVACYBUDGETEXCEEDED (4001), TENANTISOLATIONVIOLATION (4002), DIFFERENTIALPRIVACYVERIFICATIONFAILED (4003), SECUREAGGREGATIONTIMEOUT (4004), INSUFFICIENTPRIVACYPARAMETERS (4005), and ZKPVERIFICATION_FAILED (4006). These error codes extend the HTTP status code space as defined in [RFC9110] and SHALL follow the expert review allocation policy with designated experts appointed from the privacy-preserving computation and federated learning communities. The PPALP Privacy Compliance Identifiers registry SHALL contain standardized identifiers for privacy mechanisms, verification schemes, and compliance frameworks used within the protocol. This registry SHALL include identifiers for differential privacy mechanisms (DPGAUSSIAN, DPLAPLACE), secure aggregation protocols (SECAGGBFV, SECAGGCKKS), and zero-knowledge proof systems (ZKPBULLETPROOFS, ZKPPLONK). Registration policies for this registry SHALL follow the Specification Required policy as defined in [RFC2119], with specifications requiring formal privacy analysis and security proofs. Updates to these registries SHALL be coordinated with the broader AI agent protocol standardization efforts referenced in [draft-berlinai-vera] to ensure consistency across related privacy-preserving agent communication protocols. 11. References 11.1. Normative References [RFC 2119] RFC 2119 [RFC 8174] RFC 8174 [RFC 8259] RFC 8259 [RFC 7519] RFC 7519 [RFC 8446] RFC 8446 [draft-kale-agntcy-federated-privacy] draft-kale-agntcy-federated-privacy 11.2. Informative References [RFC 6749] RFC 6749 [RFC 9110] RFC 9110 [RFC 5280] RFC 5280 [draft-berlinai-vera] draft-berlinai-vera [draft-huang-acme-scalable-agent-enrollment] draft-huang-acme-scalable-agent-enrollment [draft-messous-eat-ai] draft-messous-eat-ai [draft-li-dmsc-mcps-agw] draft-li-dmsc-mcps-agw [draft-gaikwad-aps-profile] draft-gaikwad-aps-profile [draft-drake-email-tpm-attestation] draft-drake-email-tpm-attestation [draft-huang-rats-agentic-eat-cap-attest] draft-huang-rats-agentic-eat-cap-attest Author's Address Generated by IETF Draft Analyzer Family: agent-ecosystem 2026-03-04