Privacy-Preserving Federated Learning Architecture for Multi-Tenant Agent Systems
draft-kale-agntcy-federated-privacy-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Nik Kale | ||
| Last updated | 2026-07-02 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-kale-agntcy-federated-privacy-02
Network Working Group N. Kale
Internet-Draft Cisco Systems, Inc.
Intended status: Informational July 2026
Expires: 3 January 2027
Privacy-Preserving Federated Learning Architecture for Multi-Tenant
Agent Systems
draft-kale-agntcy-federated-privacy-02
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 2 January 2027.
Kale Expires 3 January 2027 [Page 1]
Internet-Draft Privacy-Preserving FL for Agent Systems July 2026
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Relationship to Agent Protocol Work . . . . . . . . . . . 5
1.3. Relationship to DAP and VDAF . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Participants . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Data Categories . . . . . . . . . . . . . . . . . . . . . 10
4.3. Learning Task Configuration . . . . . . . . . . . . . . . 11
4.4. Training Round Flow . . . . . . . . . . . . . . . . . . . 12
4.5. Secure Aggregation . . . . . . . . . . . . . . . . . . . 13
4.6. Differential Privacy Model . . . . . . . . . . . . . . . 14
4.7. Privacy Accounting . . . . . . . . . . . . . . . . . . . 15
4.8. Cohort Controls . . . . . . . . . . . . . . . . . . . . . 16
4.9. Model Update Types and Parameter-Efficient Fine-Tuning . 16
4.10. Aggregation Integrity and Verifiability . . . . . . . . . 17
5. Protocol Metadata . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Task Metadata . . . . . . . . . . . . . . . . . . . . . . 18
5.2. Round Metadata . . . . . . . . . . . . . . . . . . . . . 19
5.3. Update Metadata . . . . . . . . . . . . . . . . . . . . . 20
5.4. Release Metadata . . . . . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
6.1. Adversary Model . . . . . . . . . . . . . . . . . . . . . 21
6.2. Gradient and Update Leakage . . . . . . . . . . . . . . . 22
6.3. Membership and Property Inference . . . . . . . . . . . . 22
6.4. Model Inversion . . . . . . . . . . . . . . . . . . . . . 23
6.5. Poisoning and Backdoors . . . . . . . . . . . . . . . . . 23
6.6. Sybil Participants . . . . . . . . . . . . . . . . . . . 23
6.7. Replay and Round Confusion . . . . . . . . . . . . . . . 23
6.8. Agent-Specific Data Risks . . . . . . . . . . . . . . . . 24
6.9. Prompt Injection and Tool Poisoning . . . . . . . . . . . 24
Kale Expires 3 January 2027 [Page 2]
Internet-Draft Privacy-Preserving FL for Agent Systems July 2026
6.10. Collusion . . . . . . . . . . . . . . . . . . . . . . . . 24
6.11. Logging . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.12. Tension Between Update Privacy and Update Inspection . . 25
6.13. Coordinator Compromise and Cohort Manipulation . . . . . 25
7. Operational Considerations . . . . . . . . . . . . . . . . . 26
7.1. Deployment Modes . . . . . . . . . . . . . . . . . . . . 26
7.2. Model Registry . . . . . . . . . . . . . . . . . . . . . 26
7.3. Attestation . . . . . . . . . . . . . . . . . . . . . . . 27
7.4. Retention . . . . . . . . . . . . . . . . . . . . . . . . 27
7.5. Data Heterogeneity . . . . . . . . . . . . . . . . . . . 27
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 28
8.1. Mapping to RFC 6973 Threat Categories . . . . . . . . . . 29
8.2. Deletion, Tenant Departure, and Unlearning . . . . . . . 29
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.1. Normative References . . . . . . . . . . . . . . . . . . 30
10.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. Example Configuration . . . . . . . . . . . . . . . 33
Appendix B. Worked Privacy Accounting Example . . . . . . . . . 35
Appendix C. Open Issues for Discussion . . . . . . . . . . . . . 36
Appendix D. Changes from -01 . . . . . . . . . . . . . . . . . . 36
Appendix E. Changes from -00 . . . . . . . . . . . . . . . . . . 37
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 38
1. 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 [McMahan17]
[Kairouz21]. Differential privacy can bound the information revealed
through updates or aggregate outputs [Dwork14]. 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.
Kale Expires 3 January 2027 [Page 3]
Internet-Draft Privacy-Preserving FL for Agent Systems July 2026
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.
1.1. 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 [SLIM], ADS [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.
Kale Expires 3 January 2027 [Page 4]
Internet-Draft Privacy-Preserving FL for Agent Systems July 2026
1.2. Relationship to Agent Protocol Work
This document is intended to complement agent protocol work [AIPROTO]
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,
which is discussed in Section 1.3.
1.3. Relationship to DAP and VDAF
The IETF has standardization work for privacy-preserving measurement:
the Distributed Aggregation Protocol (DAP) [DAP] and Verifiable
Distributed Aggregation Functions (VDAF) [VDAF]. A reasonable
question is whether federated learning for agent systems can simply
use DAP. This section states why DAP is not sufficient on its own
for the problem in this document, and which parts of that work this
Kale Expires 3 January 2027 [Page 5]
Internet-Draft Privacy-Preserving FL for Agent Systems July 2026
architecture can reuse.
DAP is designed for aggregate statistics over user measurements: each
measurement is submitted once, aggregated in a batch, and the output
is a low-dimensional aggregate. Federated learning differs in three
ways that matter for privacy:
* Model updates are high-dimensional. An update can contain
millions of values, or a structured object such as a low-rank
adapter (Section 4.9), rather than a small measurement.
* Training is iterative. The same participants contribute across
many rounds against an evolving model, so privacy loss composes
over rounds and must be accounted for (Section 4.7). DAP tasks do
not carry cross-round accounting state.
* The output is a model, not a statistic. A released model can be
queried indefinitely, so release evaluation and model-level
leakage (Section 6.4) are part of the privacy analysis.
At the same time, two ideas from that work map directly onto this
architecture:
* VDAF-style validity proofs allow an aggregator to check a property
of a submission, such as a bounded norm, without seeing the
submission in the clear. This is one concrete instantiation of
the hybrid approach in Section 6.12, where clipping claims are
verified rather than trusted.
* The DAP task model, in which a task binds parameters that all
parties can verify, matches the requirement in Section 4.3 that
participants inspect and reject task configurations.
Feedback on whether existing VDAFs, or new VDAFs, can serve as the
update-validity mechanism for federated learning updates is
specifically invited (see Appendix C).
2. 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.
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.
Kale Expires 3 January 2027 [Page 6]
Internet-Draft Privacy-Preserving FL for Agent Systems July 2026
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.
Kale Expires 3 January 2027 [Page 7]
Internet-Draft Privacy-Preserving FL for Agent Systems July 2026
Training Round: One iteration in which selected participants receive
model parameters, train locally, and contribute updates to an
aggregate result.
3. 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.
Kale Expires 3 January 2027 [Page 8]
Internet-Draft Privacy-Preserving FL for Agent Systems July 2026
4. Architecture
4.1. 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 Section 4.10.
Figure 1 shows the relationships between these roles.
Kale Expires 3 January 2027 [Page 9]
Internet-Draft Privacy-Preserving FL for Agent Systems July 2026
Tenant A Tenant B Tenant C
+---------+ +---------+ +---------+
| Local | | Local | | Local |
| Data + | | Data + | | Data + |
| Training| | Training| | Training|
+----+----+ +----+----+ +----+----+
| updates or | |
| shares | |
v v v
+-----------------------------------------+
| Aggregation Service |
+---------------------+-------------------+
| aggregate only
v
+-------------+ +---------+ +----------+
| Coordinator |<->| Privacy | | Model |
| (tasks, | | Account.|-->| Registry |
| cohorts) | +---------+ +----------+
+------+------+ | |
| v v
| +---------------------+
+--------->| Audit Log |
+---------------------+
Policy Authority and Verifier constrain
task creation, eligibility, and release.
Figure 1: Architecture Roles
These roles can be implemented by separate services or combined in a
deployment. Combining roles can simplify operations, but it changes
the trust model.
4.2. 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.
Kale Expires 3 January 2027 [Page 10]
Internet-Draft Privacy-Preserving FL for Agent Systems July 2026
* 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.
4.3. 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 Section 4.9.
* 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.
Kale Expires 3 January 2027 [Page 11]
Internet-Draft Privacy-Preserving FL for Agent Systems July 2026
* 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.
4.4. 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.
Figure 2 summarizes the flow for one participant.
Kale Expires 3 January 2027 [Page 12]
Internet-Draft Privacy-Preserving FL for Agent Systems July 2026
Coordinator Participant Aggregation Svc
| round metadata, | |
| model version | |
|--------------------->| |
| | verify task config |
| | local training |
| | clip update |
| | add noise share |
| | update / shares |
| |-------------------->|
| | | aggregate
| aggregate (only, for valid cohort) |
|<-------------------------------------------|
| accountant update | |
| release decision | |
| registry record | |
Figure 2: Training Round Flow (Distributed DP Variant)
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.
4.5. Secure Aggregation
For cross-tenant or cross-organization deployments, secure
aggregation [Bonawitz17] 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
[RFC9420].
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.
Kale Expires 3 January 2027 [Page 13]
Internet-Draft Privacy-Preserving FL for Agent Systems July 2026
* 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 [SECAGG-INV]. Cohort-size
controls (Section 4.8) and differential privacy are therefore needed
in addition to secure aggregation, not as alternatives to it.
4.6. 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
[USERDP].
A deployment MUST also state the differential privacy model:
* Local differential privacy, where participants perturb updates
before submission.
Kale Expires 3 January 2027 [Page 14]
Internet-Draft Privacy-Preserving FL for Agent Systems July 2026
* 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.
4.7. 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 [Abadi16] [DPFL-REVIEW]. The chosen method MUST
be documented.
Kale Expires 3 January 2027 [Page 15]
Internet-Draft Privacy-Preserving FL for Agent Systems July 2026
Training MUST stop, or the task MUST be reauthorized, when the
configured privacy budget is exhausted.
4.8. 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.
4.9. 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 [FEDLLM].
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.
Kale Expires 3 January 2027 [Page 16]
Internet-Draft Privacy-Preserving FL for Agent Systems July 2026
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 [FFA-LoRA] [FLORA].
* 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
[FLORA].
* 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.
4.10. Aggregation Integrity and Verifiability
Secure aggregation as described in Section 4.5 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:
Kale Expires 3 January 2027 [Page 17]
Internet-Draft Privacy-Preserving FL for Agent Systems July 2026
* 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 Section 4.7.
* Model release report: a signed record linking a released model
version to the rounds, cohorts, and accounting state that produced
it, as described in Section 5.4.
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.
5. Protocol Metadata
This document does not define a new wire protocol. It defines
metadata that any carrying protocol or coordination API needs to
represent.
5.1. Task Metadata
Task metadata SHOULD include:
* task_id
* task_purpose
* model_id
* initial_model_version
Kale Expires 3 January 2027 [Page 18]
Internet-Draft Privacy-Preserving FL for Agent Systems July 2026
* 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
5.2. Round Metadata
Round metadata SHOULD include:
* task_id
* round_id
* model_version
* round_deadline
* cohort_id
* minimum_required_updates
Kale Expires 3 January 2027 [Page 19]
Internet-Draft Privacy-Preserving FL for Agent Systems July 2026
* dropout_policy
* aggregation_parameters
* replay_protection_nonce
5.3. 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.
5.4. Release Metadata
A model release SHOULD record:
* model_id
* model_version
Kale Expires 3 January 2027 [Page 20]
Internet-Draft Privacy-Preserving FL for Agent Systems July 2026
* 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.
6. Security Considerations
6.1. 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.
Kale Expires 3 January 2027 [Page 21]
Internet-Draft Privacy-Preserving FL for Agent Systems July 2026
* 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.
6.2. 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
[DP-GLA] [FL-INFERENCE]. 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.
6.3. 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.
Kale Expires 3 January 2027 [Page 22]
Internet-Draft Privacy-Preserving FL for Agent Systems July 2026
6.4. 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.
6.5. 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 Section 6.12.
6.6. 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.
6.7. 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.
Kale Expires 3 January 2027 [Page 23]
Internet-Draft Privacy-Preserving FL for Agent Systems July 2026
6.8. 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.
6.9. 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 [AGENTRFC].
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.
6.10. 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.
6.11. 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.
Kale Expires 3 January 2027 [Page 24]
Internet-Draft Privacy-Preserving FL for Agent Systems July 2026
6.12. 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 (for example, VDAF-style validity proofs [VDAF], see
Section 1.3), 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.
6.13. Coordinator Compromise and Cohort Manipulation
The coordinator selects cohorts. A compromised or malicious
coordinator can use that position against a specific participant even
when secure aggregation is in use. A concrete attack: the
coordinator selects a cohort of the minimum size in which every
participant except the target is controlled by, or colluding with,
the attacker. The attacker's own contributions are known, so the
target's contribution can be recovered from the aggregate by
subtraction. Repeating this across rounds defeats the purpose of
secure aggregation without breaking its cryptography.
Mitigations include:
Kale Expires 3 January 2027 [Page 25]
Internet-Draft Privacy-Preserving FL for Agent Systems July 2026
* Cohort selection SHOULD be verifiable or constrained, for example
by deriving cohorts from a committed random seed, so that a
coordinator cannot silently hand-pick cohorts.
* Participants SHOULD be able to observe the participant-set
commitment for rounds they contributed to (Section 4.10) and
detect repeated placement in small or unusual cohorts.
* Sybil controls (Section 6.6) limit an attacker's ability to
populate cohorts with controlled identities in the first place.
* Distributed noise contributions ensure that even a fully
adversarial cohort remainder faces differentially private, not
exact, residuals.
Combining the coordinator and aggregation service roles in one
operator increases the impact of this adversary and SHOULD be
reflected in the trust analysis for the deployment mode
(Section 7.1).
7. Operational Considerations
7.1. 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.
7.2. 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.
Kale Expires 3 January 2027 [Page 26]
Internet-Draft Privacy-Preserving FL for Agent Systems July 2026
7.3. Attestation
Some deployments may require evidence that a participant or service
is running approved code in an approved environment. Remote
attestation, following the RATS architecture [RFC9334], can support
that requirement. In RATS terms, the participant or service acts as
the Attester, and the Verifier role in this architecture
(Section 4.1) evaluates the attestation evidence.
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.
7.4. 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.
7.5. Data Heterogeneity
Tenant data in agent systems is rarely identically distributed.
Tenants differ in industry, workload mix, tool sets, languages, and
user populations. Training over non-IID data is known to slow
convergence and degrade the quality of a single global model [NonIID]
[Kairouz21].
Heterogeneity interacts with privacy. Slower convergence means more
rounds, and more rounds consume more privacy budget for the same
utility. Distinctive tenants are also easier targets for membership
and property inference because their contributions are more
separable. Deployments SHOULD consider heterogeneity when setting
Kale Expires 3 January 2027 [Page 27]
Internet-Draft Privacy-Preserving FL for Agent Systems July 2026
the maximum number of rounds and the privacy budget, and SHOULD treat
highly distinctive participant populations as a factor in minimum
cohort size (Section 4.8).
Techniques such as personalization layers or per-tenant adapters can
address heterogeneity, but they change what is shared and therefore
what leaks. If per-tenant components are kept local and only shared
components are aggregated, the privacy analysis applies to the shared
components. The task configuration MUST identify which parameters
are shared.
8. 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 [RFC6973].
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.
Kale Expires 3 January 2027 [Page 28]
Internet-Draft Privacy-Preserving FL for Agent Systems July 2026
8.1. Mapping to RFC 6973 Threat Categories
The privacy threats in this document map onto the categories of
[RFC6973] as follows. Disclosure and identification arise through
update leakage, membership inference, and model inversion
(Section 6.2, Section 6.3, Section 6.4). Correlation arises when
participant identifiers, round metadata, or per-round metrics allow
activity linking across rounds and domains; pseudonymous update
metadata (Section 5.3) and restraint in releasing per-round metrics
reduce it. Surveillance corresponds to a curious coordinator or
aggregation service observing contribution patterns over time,
addressed by secure aggregation and cohort controls. Secondary use
arises when traces collected for agent operation are used for
training beyond the stated task purpose; the task_purpose field and
local policy checks (Section 4.3) are the controls. Exclusion arises
when participants cannot see how their data was used; release
metadata availability (Section 5.4) and aggregation integrity
evidence (Section 4.10) reduce it.
8.2. Deletion, Tenant Departure, and Unlearning
Retention policies (Section 7.4) govern stored artifacts. They do
not remove a participant's influence from a trained model. When a
tenant departs the platform, withdraws consent, or invokes a legal
deletion right after contributing to training rounds, deleting the
tenant's updates and local data does not undo the effect those
updates had on released model versions.
A deployment MUST decide, before training begins, how contribution
removal is handled. Available approaches, each with limits:
* Retraining from a checkpoint that predates the participant's first
contribution. This is the only approach that fully removes
influence. Its cost grows with the number of rounds since that
checkpoint, and it consumes additional privacy budget for the
remaining participants.
* Approximate unlearning techniques that adjust the model to reduce
a participant's influence without full retraining [FedEraser].
These reduce, but do not provably eliminate, influence, and the
residual influence is difficult to quantify.
* Differential privacy as a bound. If the privacy unit is the
tenant and the budget is meaningful, the released model's
dependence on any single tenant is already bounded. This is an
argument that removal is unnecessary in a formal sense; whether it
satisfies a legal obligation is a question for counsel, not for
this document.
Kale Expires 3 January 2027 [Page 29]
Internet-Draft Privacy-Preserving FL for Agent Systems July 2026
* Contractual handling, in which participation terms state that
contributions to released models are not removable and departure
affects only future rounds.
The chosen approach SHOULD be recorded in the task configuration and
disclosed to participants before enrollment. Model registry records
(Section 7.2) SHOULD retain enough lineage to identify which released
versions include a given participant's rounds, since every removal
approach depends on that information.
9. IANA Considerations
This document has no IANA actions.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>.
[RFC9420] Barnes, R., Beurdouche, B., Robert, R., Millican, J.,
Omara, E., and K. Cohn-Gordon, "The Messaging Layer
Security (MLS) Protocol", RFC 9420, DOI 10.17487/RFC9420,
July 2023, <https://www.rfc-editor.org/info/rfc9420>.
[Abadi16] Abadi, M., Chu, A., Goodfellow, I., McMahan, H.B.,
Mironov, I., Talwar, K., and L. Zhang, "Deep Learning with
Differential Privacy", ACM CCS, 2016.
Kale Expires 3 January 2027 [Page 30]
Internet-Draft Privacy-Preserving FL for Agent Systems July 2026
[Bonawitz17]
Bonawitz, K., Ivanov, V., Kreuter, B., Marcedone, A.,
McMahan, H.B., Patel, S., Ramage, D., Segal, A., and K.
Seth, "Practical Secure Aggregation for Privacy-Preserving
Machine Learning", ACM CCS, 2017.
[Dwork14] Dwork, C. and A. Roth, "The Algorithmic Foundations of
Differential Privacy", Foundations and Trends in
Theoretical Computer Science, 2014.
[Kairouz21]
Kairouz, P., McMahan, H.B., and B. Avent, "Advances and
Open Problems in Federated Learning", Foundations and
Trends in Machine Learning, 2021.
[McMahan17]
McMahan, H.B., Moore, E., Ramage, D., Hampson, S., and B.
Aguera y Arcas, "Communication-Efficient Learning of Deep
Networks from Decentralized Data", AISTATS, 2017.
[DAP] Geoghegan, T., Patton, C., Pitman, B., Rescorla, E., and
C.A. Wood, "Distributed Aggregation Protocol for Privacy
Preserving Measurement", Work in Progress, Internet-Draft,
draft-ietf-ppm-dap-17, January 2026,
<https://datatracker.ietf.org/doc/draft-ietf-ppm-dap/>.
[VDAF] Barnes, R.L., Cook, D., Patton, C., and P. Schoppmann,
"Verifiable Distributed Aggregation Functions", Work in
Progress, Internet-Draft, draft-irtf-cfrg-vdaf-19, April
2026,
<https://datatracker.ietf.org/doc/draft-irtf-cfrg-vdaf/>.
[SLIM] Muscariello, L., Papalini, M., Sardara, M., and S. Betts,
"Secure Low-Latency Interactive Messaging (SLIM)", Work in
Progress, Internet-Draft, draft-mpsb-agntcy-slim, 2025,
<https://datatracker.ietf.org/doc/html/draft-mpsb-agntcy-
slim>.
[ADS] Papalini, M. and L. Muscariello, "Agent Directory
Service", Work in Progress, 2025.
[AIPROTO] Rosenberg, J. and C. Jennings, "Framework, Use Cases and
Requirements for AI Agent Protocols", Work in Progress,
Internet-Draft, draft-rosenberg-aiproto-framework, 2025,
<https://datatracker.ietf.org/doc/html/draft-rosenberg-
aiproto-framework>.
Kale Expires 3 January 2027 [Page 31]
Internet-Draft Privacy-Preserving FL for Agent Systems July 2026
[DPFL-REVIEW]
Fu, J., Hong, Y., Ling, X., Wang, L., Ran, X., Sun, Z.,
Wang, W.H., Chen, Z., and Y. Cao, "Differentially Private
Federated Learning: A Systematic Review",
arXiv 2405.08299, 2024,
<https://arxiv.org/abs/2405.08299>.
[FL-INFERENCE]
Montana-Fernandez, P. and I. Ortega-Fernandez, "An
Efficient Gradient-Based Inference Attack for Federated
Learning", arXiv 2512.15143, 2025,
<https://arxiv.org/abs/2512.15143>.
[AGENTRFC] Zheng, S. and Q. Zhang, "AgentRFC: Security Design
Principles and Conformance Testing for Agent Protocols",
arXiv 2603.23801, 2026,
<https://arxiv.org/abs/2603.23801>.
[FEDLLM] Wu, Y., "A Survey on Federated Fine-tuning of Large
Language Models", arXiv preprint. Verify arXiv identifier
before submission., 2025.
[FFA-LoRA] Sun, Y., "Improving LoRA in Privacy-preserving Federated
Learning", arXiv preprint. Verify arXiv identifier before
submission., 2024.
[FLORA] Wang, Z., "FLoRA: Federated Fine-Tuning Large Language
Models with Heterogeneous Low-Rank Adaptations", arXiv
preprint. Verify arXiv identifier before submission.,
2024.
[USERDP] Charles, Z., "Fine-Tuning Large Language Models with User-
Level Differential Privacy", arXiv preprint. Verify arXiv
identifier before submission., 2024.
[DP-GLA] Hu, J., "Does Differential Privacy Really Protect
Federated Learning From Gradient Leakage Attacks?", IEEE
Transactions on Mobile Computing, 2024.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/info/rfc9334>.
[NonIID] Zhao, Y., Li, M., Lai, L., Suda, N., Civin, D., and V.
Chandra, "Federated Learning with Non-IID Data",
arXiv:1806.00582. Verify identifier before submission.,
2018.
Kale Expires 3 January 2027 [Page 32]
Internet-Draft Privacy-Preserving FL for Agent Systems July 2026
[FedEraser]
Liu, G., Ma, X., Yang, Y., Wang, C., and J. Liu,
"FedEraser: Enabling Efficient Client-Level Data Removal
from Federated Learning Models", IEEE/ACM IWQoS. Verify
before submission., 2021.
[SECAGG-INV]
Sun, Y., "Client-Side Gradient Inversion Attack in
Federated Learning Using Secure Aggregation", IEEE
Internet of Things Journal, 2024.
Appendix A. Example Configuration
The following example is illustrative. Values are not
recommendations.
Kale Expires 3 January 2027 [Page 33]
Internet-Draft Privacy-Preserving FL for Agent Systems July 2026
{
"learning_task": {
"task_id": "agent-tool-ranking-2026-07",
"task_purpose": "Improve tool ranking from local outcome labels",
"model_id": "tool-ranker",
"initial_model_version": "2026.07.01",
"participant_population": "enterprise-tenants",
"privacy_unit": "tenant",
"dp_model": "distributed",
"update_type": "lora_adapter",
"privacy_budget": {
"epsilon": 3.0,
"delta": 0.000001,
"accounting_method": "renyi-dp"
},
"training": {
"maximum_rounds": 100,
"local_epochs": 3,
"clipping_rule": {
"type": "l2",
"bound": 1.0
},
"noise_multiplier": 2.0,
"lora": {
"rank": 8,
"aggregation": "rank-aware"
}
},
"aggregation": {
"method": "secure-aggregation",
"integrity_method": "signed-round-manifest",
"minimum_cohort_size": 25,
"dropout_policy": "fail-below-threshold"
},
"release_policy": {
"requires_privacy_budget_available": true,
"requires_security_evaluation": true,
"requires_model_registry_record": true
},
"retention": {
"plaintext_updates": "not-retained",
"aggregate_updates": "30-days",
"privacy_accounting_state": "life-of-model",
"audit_logs": "365-days"
}
}
}
Kale Expires 3 January 2027 [Page 34]
Internet-Draft Privacy-Preserving FL for Agent Systems July 2026
Appendix B. Worked Privacy Accounting Example
This appendix shows one composed privacy-loss calculation for the
configuration in Appendix A, to make the accounting requirement in
Section 4.7 concrete. The numbers below were computed with a Renyi
differential privacy accountant for the subsampled Gaussian
mechanism. They are illustrative, not normative, and any
implementation MUST compute its own values with a maintained
accountant library.
Assume: privacy unit is the tenant; each round selects a cohort of 25
from a population of 250 eligible tenants (sampling rate 0.1);
training runs the maximum 100 rounds; each tenant update is clipped
to L2 norm 1.0; Gaussian noise with noise multiplier sigma (noise
standard deviation as a multiple of the clipping bound) is applied to
each contribution or as combining shares; delta is 1e-6.
Composed epsilon at delta = 1e-6 over 100 rounds:
* sigma = 1.1 composes to epsilon of approximately 7.5.
* sigma = 1.5 composes to epsilon of approximately 4.4.
* sigma = 2.0 composes to epsilon of approximately 2.9.
Two observations. First, a noise multiplier that looks reasonable
for a single round (1.1 is common in the literature for one-shot
training) exceeds a budget of epsilon = 3.0 more than twofold when
composed over 100 rounds at this sampling rate. A per-round
intuition about noise is not a substitute for composed accounting,
and a task configuration that states a budget without a consistent
noise multiplier, round count, and sampling rate is incoherent. This
is why Section 4.7 requires the accountant to track all of these
inputs together. Second, the configuration in Appendix A uses sigma
= 2.0, which stays within its stated budget of epsilon = 3.0 with a
small margin; training MUST stop before any round that would exceed
the budget.
Utility at tenant-level privacy with sigma = 2.0 depends on the
update dimension and the model; for high-dimensional full-gradient
updates it may be poor, which is one motivation for parameter-
efficient updates (Section 4.9) and for distributed rather than local
noise placement (Section 4.6).
Kale Expires 3 January 2027 [Page 35]
Internet-Draft Privacy-Preserving FL for Agent Systems July 2026
Appendix C. Open Issues for Discussion
The following questions are open, and input is invited on each.
Responses on the mailing list where this document is discussed,
referencing the issue number, are welcome.
1. Can existing VDAFs, or a new VDAF, serve as the update-validity
mechanism for high-dimensional or low-rank-adapter updates, so
that clipping claims are verified rather than trusted
(Section 1.3, Section 6.12)?
2. What is the right default privacy unit for multi-tenant agent
platforms: tenant, user, or session? Tenant-level protects the
organization but may be too coarse to protect individual users
within a tenant (Section 4.6).
3. Should contribution removal (unlearning) be a requirement with
specified mechanisms, or a documented limitation with disclosure
obligations (Section 8.2)?
4. Is verifiable cohort selection (for example, committed-randomness
cohorts) worth its complexity as a normative requirement, given
the coordinator attack in Section 6.13?
5. Which carrying protocol is the natural home for the metadata in
this document: extension metadata in agent protocols, a separate
coordination API, or a profile of an existing task-provisioning
mechanism?
6. For LoRA updates, should this document standardize an update
schema (factor layout, rank field, quantization) or leave the
schema entirely to the task configuration (Section 4.9)?
7. Do the aggregation integrity objects (Section 4.10) need a
defined verification procedure to be useful, or is naming the
objects and their signers sufficient at the architecture level?
8. Should per-round release of evaluation metrics be prohibited
below a cohort-size threshold, rather than merely discouraged
(Section 6.2)?
Appendix D. Changes from -01
This version:
Kale Expires 3 January 2027 [Page 36]
Internet-Draft Privacy-Preserving FL for Agent Systems July 2026
* Adds a section on the relationship to DAP and VDAF, stating why
privacy-preserving measurement is not sufficient for federated
learning and which mechanisms are reusable, including VDAF-style
validity proofs as an instantiation of the hybrid validation
approach.
* Adds architecture and training-round figures.
* Adds a coordinator compromise and cohort manipulation attack with
mitigations, including verifiable cohort selection.
* Adds an operational considerations section on data heterogeneity
and its interaction with privacy budgets and cohort controls.
* Maps the document's threats to the RFC 6973 privacy threat
categories.
* Adds a section on deletion, tenant departure, and unlearning,
stating that retention policies do not remove influence from
trained models and enumerating the available approaches and their
limits.
* Grounds the attestation discussion in the RATS architecture (RFC
9334).
* Adds a worked privacy accounting appendix with composed epsilon
values, and corrects the example configuration to use a noise
multiplier consistent with its stated budget.
* Adds an open issues appendix inviting discussion on specific
questions.
* Updates the DAP and VDAF references to the current draft versions
and adds references for RATS, non-IID federated learning, and
federated unlearning.
Appendix E. 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.
Kale Expires 3 January 2027 [Page 37]
Internet-Draft Privacy-Preserving FL for Agent Systems July 2026
* 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.
Author's Address
Kale Expires 3 January 2027 [Page 38]
Internet-Draft Privacy-Preserving FL for Agent Systems July 2026
Nik Kale
Cisco Systems, Inc.
San Jose, CA
United States of America
Email: nikkal@cisco.com
Kale Expires 3 January 2027 [Page 39]