Cisco Systems, Inc.

San Jose CA United States of America nikkal@cisco.com

Security federated learning differential privacy secure aggregation AI agents privacy This document describes an architecture for privacy-preserving federated learning in multi-tenant agent systems. The architecture is intended for deployments in which agents, tools, services, or model operators need to learn from distributed operational data without centralizing tenant data. The architecture separates agent communication from learning coordination. Existing or emerging agent protocols can provide discovery, messaging, authentication, and transport. This document defines the privacy and security requirements for the learning layer: cohort formation, update submission, secure aggregation, differential privacy, privacy accounting, auditability, and model distribution. The document is scoped to cross-tenant and cross-organization settings. It does not define a new agent protocol, a new transport protocol, or a new machine learning algorithm.

Introduction Agent systems increasingly operate across tenants, organizations, services, and trust domains. In these settings, agents often produce operational traces that can improve later behavior. Examples include tool invocation outcomes, retrieval quality signals, planner decisions, task completion signals, safety intervention results, and user feedback. Centralizing these traces can conflict with tenant isolation requirements, contractual restrictions, data protection law, and enterprise security policy. Training only inside each tenant boundary avoids centralization, but it prevents learning from patterns that appear across tenants. Federated learning can reduce the need to centralize raw data by allowing each tenant to compute model updates locally . Differential privacy can bound the information revealed through updates or aggregate outputs . Secure aggregation can prevent an aggregation service from observing individual tenant updates. Used together, these mechanisms can support cross-tenant learning while reducing privacy risk. These mechanisms do not remove all risk. Model updates can leak information. Multi-round training can increase leakage. Small cohorts can expose participants. Malicious tenants can poison a model. Agent traces can contain sensitive user data, tool outputs, credentials, instructions, and policy decisions. A deployment that uses federated learning still needs explicit privacy accounting, access control, update validation, and audit procedures. This document describes an architecture and a set of requirements for such deployments.

Scope This document covers:

• Cross-tenant and cross-organization federated learning for agent systems.
• Learning from local traces without sending raw traces to a central service.
• Secure aggregation of model updates.
• Differential privacy and privacy accounting for repeated training rounds.
• Protocol metadata needed to coordinate training rounds.
• Security and privacy risks specific to agent-generated data.

This document does not cover:

• A new wire protocol for agent communication.
• A replacement for MCP, A2A, SLIM , ADS , HTTP APIs, gRPC, or other transports.
• A new training algorithm.
• A complete compliance program for GDPR, HIPAA, CCPA, or other legal regimes.
• Claims that federated learning alone makes a model or deployment private.

Relationship to Agent Protocol Work This document is intended to complement agent protocol work rather than replace it. Agent communication protocols can provide discovery, addressing, session management, authentication, authorization, tool invocation, and message delivery. A privacy-preserving learning layer needs additional semantics that are not usually defined by those protocols:

• Training task identity.
• Model and model-version identity.
• Cohort eligibility.
• Minimum cohort size.
• Round number and round deadline.
• Update format and size limits.
• Clipping and noise parameters.
• Secure aggregation parameters.
• Privacy accounting state.
• Audit log requirements.
• Model release policy.

When an agent protocol supports extension metadata, these fields can be carried as protocol extensions. When it does not, they can be carried in a separate coordination API. In either case, the learning layer needs consistent semantics across implementations. This document is also related to privacy-preserving measurement work. Privacy-preserving measurement protocols are useful for aggregate statistics and telemetry . Federated learning has different requirements because model updates are high-dimensional, repeated over many rounds, and may influence later agent behavior.

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 when, and only when, they appear in all capitals, as shown here.

Agent:

A software component that uses a model, tools, memory, policies, or other services to perform tasks on behalf of a user, application, or organization.

Aggregation Service:

A service that combines model updates from multiple participants.

Cohort:

The set of participants selected for a training round.

Coordinator:

A service that creates training tasks, selects cohorts, distributes model parameters, and records privacy accounting metadata.

Differential Privacy:

A mathematical definition that bounds the effect that a privacy unit can have on the output of a computation.

Federated Learning:

A training approach in which participants compute updates using local data and send updates, or shares of updates, for aggregation.

Learning Task:

A configured federated training activity for a specific model, objective, privacy unit, privacy budget, and participant population.

Model Update:

Parameters, gradients, statistics, low-rank adapters, or other values produced by a participant during a training round.

Parameter-Efficient Fine-Tuning (PEFT):

A family of methods that adapt a large pre-trained model by training a small set of additional or selected parameters while the base parameters stay fixed. Low-Rank Adaptation (LoRA) is a common example.

Participant:

A tenant, organization, service, device group, or other entity that performs local training.

Privacy Accountant:

A component or process that tracks privacy loss across training rounds and model releases.

Privacy Budget:

Parameters that bound privacy loss, commonly expressed as epsilon and delta for differential privacy.

Privacy Unit:

The entity protected by a privacy guarantee. Examples include an event, record, user, session, tenant, organization, or device.

Secure Aggregation:

A protocol by which an aggregation service learns an aggregate value without learning individual participant updates.

Tenant:

An administrative domain with its own users, data, policies, and operational boundary.

Training Round:

One iteration in which selected participants receive model parameters, train locally, and contribute updates to an aggregate result.

Problem Statement Consider an agent deployment with multiple tenants. Each tenant has local traces from agent activity. These traces may include prompts, tool calls, retrieval results, generated content, user feedback, safety decisions, and task outcomes. The operator wants to improve one or more models or policies using signals from multiple tenants. At the same time, the operator must preserve tenant isolation and limit disclosure of sensitive data. A centralized approach sends traces to a shared service. That approach can expose sensitive content and can violate data handling requirements. A local-only approach keeps data inside each tenant, but it prevents learning from cross-tenant patterns. A federated approach keeps raw traces local, but it still exposes updates that may leak information. The architecture in this document addresses the following requirements:

• Raw tenant data remains within the tenant boundary.
• Individual participant updates are not visible to the aggregation service in normal operation.
• The privacy unit is stated before training begins.
• Privacy loss is tracked across rounds and model releases.
• Small cohorts are rejected or delayed.
• Participants authenticate the coordinator, aggregation service, and task configuration.
• The coordinator authenticates participants and enforces eligibility.
• Model updates are bound to a specific task, model version, round, and participant.
• The final model is released only if privacy, security, and policy checks pass.

Architecture

Participants The architecture has the following participants:

Tenant Participant:

Performs local training on tenant-controlled data.

Coordinator:

Creates learning tasks, selects cohorts, distributes model parameters, and maintains task state.

Aggregation Service:

Aggregates participant updates.

Privacy Accountant:

Tracks privacy loss for the configured privacy unit.

Model Registry:

Stores model versions and release metadata.

Audit Log:

Records task configuration, round state, participant events, privacy accounting output, and model release decisions.

Policy Authority:

Defines tenant eligibility, data-use constraints, privacy limits, and release rules.

Verifier:

Optionally evaluates attestation evidence for participants or services, and optionally checks aggregation integrity evidence as described in .

These roles can be implemented by separate services or combined in a deployment. Combining roles can simplify operations, but it changes the trust model.

Data Categories Agent systems can produce data categories that are different from ordinary application telemetry. A deployment SHOULD classify data before using it for learning. Relevant categories include:

• User prompts and requests.
• Agent plans and intermediate reasoning artifacts.
• Tool names, tool inputs, and tool outputs.
• Retrieval queries and retrieved content.
• Memory reads and memory writes.
• Safety policy decisions.
• Human approval or rejection events.
• Task outcome labels.
• Latency, error, and resource-use metrics.

Some of these categories can contain secrets, regulated data, business records, or third-party content. Local preprocessing SHOULD remove or transform data that is not needed for the learning task. Local preprocessing SHOULD NOT rely on the model being trained to decide what is safe to expose.

Learning Task Configuration Each learning task MUST define:

• A task identifier.
• The model or policy being trained.
• The initial model version.
• The allowed participant population.
• The privacy unit.
• The privacy budget and accounting method.
• The update type, as described in .
• The clipping rule.
• The noise mechanism, if differential privacy is used.
• The secure aggregation method, if used.
• The minimum cohort size.
• The maximum number of rounds.
• The update schema.
• The model release criteria.
• The retention policy for updates, aggregate values, logs, and model checkpoints.

Participants MUST be able to inspect the task configuration before contributing an update. A participant MUST reject a task if the configuration is missing required fields or conflicts with local policy.

Training Round Flow A typical round proceeds as follows:

1. The coordinator creates a round for a configured learning task.
2. The coordinator selects eligible participants.
3. Each participant authenticates the coordinator and verifies the task configuration.
4. The coordinator sends the current model version and round metadata.
5. Each participant trains locally using data permitted by local policy.
6. Each participant clips its update according to the task configuration.
7. Each participant applies the configured privacy mechanism, if required at the participant.
8. Each participant submits an update, or a share of an update, for aggregation.
9. The aggregation service computes the aggregate.
10. The privacy accountant updates privacy-loss state.
11. The coordinator determines whether the aggregate can update the global model.
12. The model registry records the new model version and release metadata.

The order of steps can vary. For example, distributed differential privacy can require participants to add calibrated noise before secure aggregation. Central differential privacy can require the aggregation service or a trusted component to add noise after aggregation. The chosen model MUST be recorded in the task configuration.

Secure Aggregation For cross-tenant or cross-organization deployments, secure aggregation is RECOMMENDED. Without secure aggregation, the aggregation service can observe each participant update. That creates a direct leakage path. Group communication among cohort members can be secured using existing mechanisms such as MLS . Secure aggregation SHOULD provide the following properties:

• The aggregation service learns only an aggregate value for a valid cohort.
• A participant update is bound to one task, one round, and one model version.
• A failed participant does not cause disclosure of another participant's update.
• The protocol handles participant dropout within configured limits.
• The protocol rejects replayed or duplicated updates.
• The protocol authenticates participants and aggregation messages.

Secure aggregation does not by itself provide differential privacy. The aggregate can still leak information, especially with small cohorts, repeated rounds, or correlated updates. Secure aggregation also protects individual updates only under its stated trust and collusion assumptions. Reconstruction of an individual contribution from an aggregate has been demonstrated even when updates are quantized, in settings where the cohort is small and a participant in the cohort is curious . Cohort-size controls () and differential privacy are therefore needed in addition to secure aggregation, not as alternatives to it.

Differential Privacy Model A deployment MUST state the privacy unit. It is not enough to state epsilon and delta without saying what entity is protected. The privacy unit MAY be:

• A record.
• A user.
• A session.
• A device.
• A tenant.
• An organization.

For agent systems, user-level or tenant-level privacy is often more relevant than record-level privacy. Record-level privacy can understate risk when many records belong to the same user or tenant. User-level accounting methods exist for this purpose and SHOULD be used when a single user or tenant can contribute many records . A deployment MUST also state the differential privacy model:

• Local differential privacy, where participants perturb updates before submission.
• Central differential privacy, where a trusted component adds noise after aggregation.
• Distributed differential privacy, where participants add shares of noise that combine to the required distribution.

Local differential privacy reduces trust in the coordinator or aggregation service, but it can reduce utility. Central differential privacy can improve utility, but it requires trust in the component that sees the unnoised aggregate. Distributed differential privacy can reduce trust while preserving more utility, but it adds protocol complexity.

Privacy Accounting Federated learning is usually iterative. A single training round does not describe the full privacy risk. The privacy accountant MUST track:

• Task identifier.
• Model identifier and version.
• Round number.
• Cohort size.
• Sampling rate or participant selection method.
• Clipping bound.
• Noise multiplier or noise distribution.
• Privacy unit.
• Accounting method.
• Cumulative privacy loss.
• Release decision for each model version.

Implementations SHOULD use an accountant suitable for iterative training, such as Renyi differential privacy or another accepted composition method . The chosen method MUST be documented. Training MUST stop, or the task MUST be reauthorized, when the configured privacy budget is exhausted.

Cohort Controls Small cohorts increase disclosure risk. A deployment MUST configure a minimum cohort size for each task. The coordinator MUST NOT complete a round if the number of valid participants is below the configured minimum. The coordinator SHOULD delay, merge, or cancel such a round rather than lowering the threshold at runtime. The minimum cohort size SHOULD reflect:

• The privacy unit.
• The model-update dimension.
• Expected participant correlation.
• The number of rounds.
• The secure aggregation method.
• Whether differential privacy is applied before or after aggregation.

Model Update Types and Parameter-Efficient Fine-Tuning The architecture does not assume a single update type. A model update can be a full gradient, a full set of model parameters, a set of sufficient statistics, or a set of parameter-efficient fine-tuning (PEFT) adapters. For agent systems, the model being trained is often a large language model or a component built on one. Full fine-tuning of such models across tenants is rarely practical because of update size and cost. In these deployments the update is usually a parameter-efficient adapter, most commonly a Low-Rank Adaptation (LoRA) adapter, rather than a full gradient . The update type changes how clipping, noise, secure aggregation, and accounting apply. A deployment MUST record the update type in the task configuration. Clipping and noise MUST be applied to the values that are actually transmitted, not to a notional full gradient. When LoRA or similar low-rank adapters are used, implementations need to account for the following:

• Clipping and noise apply to the adapter parameters that are transmitted. The sensitivity bound and noise scale MUST be computed against those parameters.
• A LoRA adapter is a product of two matrices. Adding noise to both factors and then averaging the factors independently does not produce the average of the intended updates, and it can amplify the added noise. Implementations SHOULD use an aggregation method that is correct for the adapter structure. Freezing one factor and training only the other, or aggregating the reconstructed update rather than the separate factors, are two approaches that avoid this problem .
• Heterogeneous adapter ranks across participants require an aggregation method that supports different ranks. Element-by-element averaging of adapters with different ranks is not defined .
• The privacy unit and accounting method do not change because the update is an adapter. A deployment still MUST state the privacy unit and track cumulative privacy loss across rounds.

Parameter-efficient updates reduce communication cost and can reduce the surface for some reconstruction attacks, but they do not remove the need for the privacy controls in this document. Adapter updates can still leak information about local data, and a malicious participant can still use an adapter update to poison a model or to attempt to alter safety behavior.

Aggregation Integrity and Verifiability Secure aggregation as described in limits what the aggregation service can observe. It does not by itself let participants confirm that the aggregation service behaved correctly. A participant generally cannot tell whether its update was included, whether other eligible updates were dropped, whether the reported aggregate matches the updates that were submitted, or whether the released model is the one the round produced. For high-assurance deployments, the architecture supports aggregation integrity through commitments and a signed record of each round. The following objects MAY be produced for a round:

• Round manifest: a signed record of the task identifier, round identifier, model version, cohort identifier, round parameters, and deadlines.
• Participant-set commitment: a commitment to the set of participants whose updates were accepted for the round.
• Aggregate commitment: a commitment to the aggregate value used to update the model.
• Privacy accountant report: a signed record of the privacy parameters and cumulative privacy loss applied to the round, as described in .
• Model release report: a signed record linking a released model version to the rounds, cohorts, and accounting state that produced it, as described in .

When these objects are produced, participants SHOULD be able to verify that the round manifest, participant-set commitment, and aggregate commitment are consistent with the model version they are asked to use in a later round. A deployment that claims aggregation integrity MUST state which objects are produced, who signs them, and how a participant or auditor verifies them. Verifiable aggregation does not replace differential privacy or cohort controls. It addresses the correctness of the aggregation process, not the information content of the aggregate or the released model.

Protocol Metadata This document does not define a new wire protocol. It defines metadata that any carrying protocol or coordination API needs to represent.

Task Metadata Task metadata SHOULD include:

• task_id
• task_purpose
• model_id
• initial_model_version
• participant_population
• privacy_unit
• dp_model
• epsilon
• delta
• accounting_method
• update_type
• clipping_rule
• noise_parameters
• secure_aggregation_method
• aggregation_integrity_method
• minimum_cohort_size
• maximum_rounds
• update_schema
• release_policy
• retention_policy

Round Metadata Round metadata SHOULD include:

• task_id
• round_id
• model_version
• round_deadline
• cohort_id
• minimum_required_updates
• dropout_policy
• aggregation_parameters
• replay_protection_nonce

Update Metadata Update metadata SHOULD include:

• task_id
• round_id
• model_version
• participant_id_or_pseudonym
• update_type
• update_schema_version
• clipping_claim
• dp_claim
• secure_aggregation_share_id
• signature

The update_type field identifies the form of the update, for example full_gradient, full_parameters, statistics, or lora_adapter. When the update is a low-rank adapter, the update schema SHOULD also carry the adapter rank so that the aggregation service can apply a rank-aware aggregation method. Participant identifiers in update metadata SHOULD be pseudonymous where possible. The coordinator can still require an authenticated channel or credential for eligibility enforcement.

Release Metadata A model release SHOULD record:

• model_id
• model_version
• source_task_id
• included_rounds
• privacy_unit
• cumulative_epsilon
• cumulative_delta
• accounting_method
• cohort_summary
• evaluation_summary
• aggregation_integrity_evidence
• release_approver
• release_time
• retention_policy

Release metadata SHOULD be available to participants and auditors subject to access-control policy.

Security Considerations

Adversary Model A deployment SHOULD consider at least the following adversaries:

• A curious coordinator.
• A curious aggregation service.
• A malicious participant.
• A group of colluding participants.
• A participant colluding with the aggregation service.
• An attacker who can replay or delay messages.
• An attacker who can register many participants.
• An attacker who can inject malicious content into agent traces.
• An attacker who can modify tool metadata, retrieval content, or policy inputs.
• An attacker who can compromise a model registry or release process.

The task configuration MUST state which of these adversaries are in scope.

Gradient and Update Leakage Model updates can reveal information about local data. This remains true even when raw data never leaves a tenant. Multi-round training can increase leakage because an attacker can observe how updates change over time. Deployments SHOULD use secure aggregation, differential privacy, cohort-size limits, clipping, and privacy accounting to reduce this risk. Deployments SHOULD avoid releasing per-round metrics that allow differencing across small cohorts. The protection offered by these mechanisms is not absolute, and the protection can be weaker than assumed. Differential privacy applied by clipping and adding noise has been shown to reduce reconstruction risk for shallow models while providing weaker protection for deeper models at usable privacy budgets, and clipping-aware reconstruction attacks have been demonstrated against central differential privacy . Deployments SHOULD treat differential privacy as a measured reduction in risk under a stated privacy unit and budget, not as a guarantee that updates cannot be inverted. The privacy unit and budget MUST be chosen with the model architecture and update dimension in mind.

Membership and Property Inference An attacker may try to infer whether a user, record, tenant, or property was present in training. The risk is higher with small cohorts, rare features, high-dimensional updates, and repeated rounds. Deployments SHOULD define the privacy unit before training. User-level or tenant-level accounting SHOULD be used when the protected entity can contribute many records.

Model Inversion The final model can leak information even if individual updates are hidden. Secure aggregation does not prevent leakage through the trained model. Deployments SHOULD evaluate released models for memorization and sensitive-output behavior. A model release SHOULD be blocked when evaluation indicates unacceptable disclosure risk.

Poisoning and Backdoors Malicious participants can submit updates that degrade model quality, insert a backdoor, or affect behavior for selected prompts, tools, users, or tenants. This risk applies to full updates and to parameter-efficient adapter updates. Deployments SHOULD apply update validation, anomaly detection, contribution limits, and release evaluation. Byzantine-resilient aggregation can help, but it is not a substitute for model evaluation. Update validation and anomaly detection require some visibility into updates, which can conflict with secure aggregation and differential privacy. This tension is discussed in .

Sybil Participants An attacker who can create many participants can influence cohort selection and aggregation. This can reduce privacy and damage model quality. The coordinator MUST authenticate participants and enforce eligibility. Cohort selection SHOULD prevent one administrative entity from appearing as many independent participants unless that behavior is intended and accounted for.

Replay and Round Confusion A model update from one task, round, or model version MUST NOT be accepted for another. Each update MUST be bound to a task identifier, round identifier, model version, and participant credential or pseudonym. Implementations SHOULD use nonces, timestamps, signatures, and round deadlines to prevent replay.

Agent-Specific Data Risks Agent traces can include sensitive content that ordinary telemetry does not contain. Examples include tool credentials, retrieved documents, customer records, approval decisions, policy prompts, and generated content. Local preprocessing SHOULD remove fields not required for the learning task. Tool outputs and retrieved content SHOULD NOT be included in training data unless the task has an explicit policy allowing that use.

Prompt Injection and Tool Poisoning Agent traces can be influenced by prompt injection, malicious documents, tool metadata, compromised tools, and adversarial retrieval content. If those traces are used for learning, the attack can move from one tenant into a shared model. Security analyses of agent protocols discuss related risks . Deployments SHOULD separate trusted labels from untrusted content. They SHOULD record provenance for training examples and SHOULD reject training data from sources that do not meet task policy.

Collusion Secure aggregation usually assumes limits on collusion. If the aggregation service colludes with enough participants, or if too many participants drop out, individual updates can become exposed. The task configuration MUST state the collusion and dropout assumptions of the secure aggregation method. A round MUST fail if those assumptions are not met.

Logging Audit logs are needed for accountability, but logs can also expose sensitive data. Logs SHOULD record events, identifiers, policy decisions, and accounting outputs. Logs SHOULD NOT include raw training data or plaintext model updates. Access to logs MUST be controlled.

Tension Between Update Privacy and Update Inspection Two goals in this architecture pull in opposite directions. Privacy mechanisms, in particular secure aggregation and local differential privacy, are designed to prevent any party from seeing an individual participant update. Defenses against poisoning and backdoors usually rely on inspecting individual updates to detect anomalies. A deployment cannot fully satisfy both with the same mechanism. A deployment SHOULD make this trade-off explicit and choose an approach that matches its threat model:

• An approach that prioritizes update privacy relies on secure aggregation and differential privacy, and limits poisoning defense to checks on the aggregate and to evaluation of the released model.
• An approach that prioritizes update inspection allows a trusted component to examine individual updates for anomaly detection. This weakens update privacy and requires a stronger trust assumption about that component.
• A hybrid approach uses techniques that allow limited validation without exposing raw updates, such as range or norm proofs on updates, validation inside a trusted execution environment, or anomaly checks that operate on protected values. These techniques add complexity and their assumptions MUST be stated.

The chosen approach MUST be recorded in the task configuration, and the residual poisoning risk under that approach SHOULD be stated in the privacy and security analysis.

Operational Considerations

Deployment Modes This architecture can be deployed in at least three modes:

• Single operator, many tenants.
• Multiple organizations with a shared coordinator.
• Multiple organizations with separate coordinators and a shared aggregation service.

Each mode has different trust assumptions. The deployment mode MUST be documented.

Model Registry The model registry SHOULD store model versions, release metadata, and rollback state. Participants SHOULD be able to verify the model version used for a training round. The registry SHOULD prevent a model trained under one policy from being released under another policy without review.

Attestation Some deployments may require evidence that a participant or service is running approved code in an approved environment. Remote attestation can support that requirement. Attestation is OPTIONAL in this architecture. If used, the task configuration SHOULD state what evidence is required, who verifies it, and how verification results affect eligibility.

Retention Retention periods SHOULD be defined for:

• Local training data.
• Intermediate updates.
• Aggregate values.
• Failed round state.
• Privacy accounting state.
• Model checkpoints.
• Audit logs.

Retaining intermediate data can improve debugging, but it increases exposure. Deployments SHOULD retain the minimum data needed for security, accountability, and policy obligations.

Privacy Considerations Federated learning reduces the need to move raw data, but it is not a privacy guarantee by itself. Privacy depends on the full system: participant selection, update design, secure aggregation, privacy accounting, model release policy, and operational controls. General guidance on privacy in protocols is given in . Deployments SHOULD perform a privacy analysis before enabling a learning task. The analysis SHOULD identify:

• The privacy unit.
• The data categories used.
• The party that can observe each artifact.
• The expected number of rounds.
• The minimum cohort size.
• The differential privacy model.
• The accounting method.
• The release criteria.
• The remaining risks.

Claims about compliance SHOULD be limited. This architecture can support a compliance program, but it does not by itself establish compliance with any law or regulation.

IANA Considerations This document has no IANA actions.

References Normative References Informative References ACM CCS ACM CCS Foundations and Trends in Theoretical Computer Science Foundations and Trends in Machine Learning AISTATS Work in Progress Work in Progress Work in Progress Work in Progress Work in Progress arXiv preprint. Verify arXiv identifier before submission. arXiv preprint. Verify arXiv identifier before submission. arXiv preprint. Verify arXiv identifier before submission. arXiv preprint. Verify arXiv identifier before submission. IEEE Transactions on Mobile Computing IEEE Internet of Things Journal

Example Configuration The following example is illustrative. Values are not recommendations.

Changes from -00 This version:

• Narrows the document to privacy architecture for federated learning in agent systems.
• Clarifies that the document does not define a new agent protocol or transport.
• Adds agent-specific data categories and risks.
• Adds a stronger threat model.
• Makes secure aggregation a recommended baseline for cross-tenant deployments.
• Distinguishes local, central, and distributed differential privacy.
• Requires explicit privacy-unit selection, and recommends user-level or tenant-level accounting when one entity can contribute many records.
• Adds privacy accounting requirements.
• Adds cohort-size and dropout controls.
• Adds handling of parameter-efficient fine-tuning updates, including LoRA, with clipping and noise applied to the transmitted parameters and aggregation methods that are correct for the adapter structure.
• Adds aggregation integrity and verifiability objects for high-assurance deployments.
• States the tension between update privacy and update inspection and the approaches for resolving it.
• Strengthens the description of the limits of differential privacy and secure aggregation against reconstruction.
• Adds protocol metadata for task, round, update, and release state, including update type and aggregation integrity fields.
• Adds operational considerations for registry, attestation, and retention.
• Revises compliance language to avoid overstatement.
• Updates references with recent work on parameter-efficient federated fine-tuning, user-level differential privacy, and reconstruction attacks against differential privacy and secure aggregation.