Federated Agent Learning Privacy and Cross-Protocol Migration

3.2.1. Differential Privacy for Model Updates

Participant agents MUST apply differential privacy to model updates before transmission. Each update is clipped to a maximum L2 norm S and perturbed with calibrated Gaussian noise:¶

• Clipping bound S: limits the influence of any single data point¶

• Noise scale sigma: calibrated to achieve (epsilon, delta)- differential privacy for each round¶

• Composition: total privacy loss across T rounds is tracked using the moments accountant or Renyi differential privacy¶

The privacy parameters MUST be declared in the federation configuration and enforced by each participant agent.¶

3.2.2. Secure Aggregation Protocol

The aggregation server MUST implement a secure aggregation protocol such that:¶

1. Each participant agent secret-shares its update using pairwise keys established with other participants.¶

2. The aggregation server collects masked updates from all participants.¶

3. After a configurable threshold of participants have submitted updates, the server reconstructs only the aggregate sum.¶

4. Individual updates are never available to the server in plaintext.¶

Dropped participants are handled by reconstructing their masking contributions from the shares held by surviving participants.¶

3.2.3. Privacy Budget Tracking and Enforcement

Each federation MUST maintain a privacy budget tracker that records cumulative epsilon expenditure per participant. The tracker MUST:¶

• Record the epsilon cost of each federated learning round¶

• Refuse to include a participant whose cumulative epsilon would exceed the configured maximum budget¶

• Support budget refresh after a configurable cooldown period¶

• Report remaining budget to participants upon request¶

Privacy budget state MUST be recorded in ECTs (see Section 5) to provide a cryptographic audit trail of privacy expenditure.¶

3.2.4. Gradient Compression with Privacy Preservation

To reduce communication overhead, participants MAY compress model updates using techniques such as top-k sparsification or random sparsification. Compression MUST NOT reduce the effective privacy guarantee below the declared epsilon -- noise MUST be added after compression, calibrated to the compressed update's sensitivity.¶

3.3.1. Membership Inference Attack Mitigation

Federation participants MUST apply differential privacy at sufficient epsilon levels to bound the success rate of membership inference attacks. The aggregation server SHOULD monitor update distributions for anomalous patterns indicative of membership inference attempts.¶

3.3.2. Model Inversion Attack Prevention

To prevent reconstruction of training data from model updates:¶

• Updates MUST be clipped and noised per the differential privacy mechanism defined above.¶

• The aggregation server MUST NOT release per-participant update statistics.¶

• Participants SHOULD limit the number of rounds in which they participate with unchanged local data.¶

3.3.3. Update Poisoning Detection

The aggregation server MUST implement poisoning detection to identify malicious updates that attempt to corrupt the global model:¶

• Statistical outlier detection on update norms and directions¶

• Byzantine-robust aggregation (e.g., coordinate-wise median or trimmed mean) as an alternative to simple averaging¶

• Participants submitting suspected poisoned updates SHOULD be flagged and excluded from subsequent rounds pending review¶

3.3.4. Privacy Attestation via ECT

Each federated learning round MUST produce an ECT [I-D.nennemann-wimse-ect] attesting to the privacy mechanisms applied. The ECT ext claim MUST include:¶

{
  "ext": {
    "fed.round_id": "round-42",
    "fed.epsilon": 1.5,
    "fed.delta": 1e-5,
    "fed.participants": 12,
    "fed.aggregation": "secure_aggregation",
    "fed.poisoning_detected": false
  }
}

4.2.1. Migration Trigger Events and Conditions

A migration MAY be triggered by any of the following events:¶

• Operator-initiated domain transfer¶

• Load balancing across infrastructure providers¶

• Disaster recovery failover¶

• Protocol deprecation requiring protocol change¶

• Policy-driven relocation (e.g., data sovereignty requirements)¶

The migration trigger MUST be recorded in an ECT with exec_act set to "migration_start".¶

4.2.2. Pre-Migration Capability Check

Before initiating migration, the source environment MUST verify that the destination environment supports the agent's required capabilities:¶

1. Query the destination's capability advertisement endpoint.¶

2. Verify that all required agent capabilities can be mapped to the destination protocol.¶

3. Verify that the destination accepts the agent's identity format (e.g., SPIFFE ID).¶

4. Confirm sufficient resources at the destination for the agent's state size.¶

If any check fails, the migration MUST be aborted and an error reported to the triggering entity.¶

4.2.3. State Serialization Format

Agent state MUST be serialized using CBOR (Concise Binary Object Representation) with the following top-level structure:¶

migration_state = {
  "version": uint,            ; serialization format version
  "agent_id": tstr,           ; agent SPIFFE ID
  "source_protocol": tstr,    ; source protocol identifier
  "dest_protocol": tstr,      ; destination protocol identifier
  "timestamp": uint,          ; Unix timestamp of serialization
  "state": {
    "context": bstr,          ; conversation/task context
    "memory": bstr,           ; long-term memory store
    "learned_params": bstr,   ; model parameters or embeddings
    "active_tasks": [* task]  ; in-progress task descriptors
  },
  "ect_chain": [* tstr],      ; ECT JWS chain for identity
  "integrity": tstr            ; HMAC-SHA256 of state fields
}

4.2.4. Identity Transfer and Re-Attestation

During migration, the agent's identity MUST be preserved through the ECT chain:¶

1. The source environment issues a migration ECT with the full ECT chain as the par claim.¶

2. The destination environment verifies the ECT chain back to a trusted root.¶

3. The destination environment issues a new ECT for the agent with exec_act set to "migration_complete" and par referencing the migration transfer ECT.¶

4. The agent's SPIFFE ID remains unchanged; only the issuing authority for new ECTs changes.¶

4.2.5. Post-Migration Verification

After migration completes, the destination environment MUST:¶

1. Verify state integrity using the HMAC in the migration payload.¶

2. Deserialize and load the agent state.¶

3. Execute a capability self-test to confirm operational readiness.¶

4. Issue the "migration_complete" ECT.¶

5. Notify the source environment of successful migration so it can release resources.¶

If verification fails, the destination MUST notify the source environment, which SHOULD retain the agent in its original state for retry or rollback.¶

4.3.1. Agent State Components

An agent's transferable state consists of four components:¶

Context:

The current conversation or task execution context, including recent message history and active reasoning chains.¶

Memory:

Long-term memory stores such as retrieval-augmented generation (RAG) indices, episodic memory, or key-value caches.¶

Learned Parameters:

Fine-tuned model weights, adapter layers, embeddings, or reinforcement learning policies specific to the agent's role.¶

Active Tasks:

In-progress task descriptors including task ID, current step, dependencies, and expected outputs.¶

4.3.2. Incremental State Transfer for Large State

For agents with state exceeding 10 MB, incremental transfer MUST be supported:¶

1. The source environment transmits a state manifest listing all state chunks with their SHA-256 hashes.¶

2. The destination environment requests only chunks it does not already possess (delta transfer).¶

3. Each chunk transfer is individually acknowledged.¶

4. After all chunks are received, the destination assembles the complete state and verifies the root hash.¶

4.3.3. State Integrity Verification

State integrity MUST be verified at each stage:¶

• Before transmission: source computes HMAC-SHA256 over the serialized state using a key derived from the migration ECT.¶

• During transmission: TLS provides transport integrity.¶

• After reception: destination recomputes and verifies the HMAC.¶

• After deserialization: destination runs a state consistency check (e.g., verifying that active task references resolve).¶

4.4.1. Bridge Architecture for Common Protocols

Protocol bridges translate agent communication between protocols while preserving semantic equivalence. A bridge MUST support bidirectional translation for each protocol pair it advertises.¶

[Agent (A2A)] <--A2A--> [Bridge] <--MCP--> [Agent (MCP)]
                           |
                      [ECT Logger]

Each bridge instance MUST:¶

• Maintain a mapping table for message types between protocols.¶

• Preserve task identifiers across protocol boundaries.¶

• Record each translation as an ECT with exec_act set to "bridge_translate".¶

4.4.2. Context Translation Rules

When translating context between protocols, bridges MUST:¶

• Map equivalent fields (e.g., A2A "task" to MCP "resource").¶

• Preserve all metadata as extension fields where direct mapping is not available.¶

• Flag semantic mismatches in the translation ECT's ext claim under bridge.warnings.¶

4.4.3. Capability Re-Mapping

Agent capabilities expressed in the source protocol MUST be re-mapped to the closest equivalent in the destination protocol. Capabilities with no equivalent MUST be listed in the migration state as unmapped_capabilities so the destination environment can handle them appropriately (e.g., by loading additional tooling or reporting reduced functionality).¶

4.5.1. Context Sanitization Before Transfer

Before state serialization, the source environment MUST sanitize the agent's context by:¶

• Removing credentials, API keys, and session tokens.¶

• Redacting PII unless the destination is authorized to receive it per the agent's privacy policy.¶

• Stripping environment-specific configuration (e.g., internal hostnames, file paths).¶

4.5.2. Selective State Disclosure

The migration protocol supports selective state disclosure: the source environment MAY omit state components that the destination is not authorized to receive. The migration state manifest indicates which components are included and which are withheld, allowing the destination to request missing components through an authorized channel if needed.¶

4.5.3. No-Context-Leakage Guarantees to New Host

The destination environment MUST NOT have access to state components that were excluded during selective disclosure. The migration protocol provides the following guarantees:¶

• State components are individually encrypted with component- specific keys.¶

• Only authorized components have their keys transmitted to the destination.¶

• The destination cannot derive keys for withheld components from the keys it receives.¶

• The migration ECT records which components were transferred, enabling audit of information flow.¶