Safety Without the Data Lake: Federating the Guard, Not the Traces

TL;DR for operators

Suppose several business units or partner organizations run different agent workflows. Each has its own prompts, tools, communication patterns, and failure cases. They want a common safety layer, but centralizing those interaction traces would expose precisely the operational data they are trying to protect.

The harder problem is that a guard trained elsewhere may not transfer well enough to solve this. In the reported experiments, an architecture-matched topology guard scores 0.512 AUROC when transferred off the shelf to Agent-SafetyBench, but 0.695 after in-domain retraining. Local adaptation helps, yet isolated local training is also weaker than collaborative training and becomes fragile when client labels are highly skewed.

FGLGuard¹ treats this as a federated learning problem over multi-agent communication graphs. Raw episode graphs remain with each participant; the system exchanges model updates, balances influence across domains, calibrates blocking against an explicit benign false-positive budget, considers upstream-agent risk, and gives a blocked output one guarded rewrite before refusing it.

For operators, the main lesson is not simply “use federated learning.” It is that shared safety infrastructure needs a policy for whose data shapes the guard, how much legitimate work may be blocked, and when a local deployment has contributed enough evidence to trust the shared model. The paper provides a plausible architecture for that problem, but not yet evidence from independently operated production organizations or a formal privacy guarantee for the exchanged model updates.

A guard trained elsewhere may not know your failure distribution

Multi-agent safety is often framed as a model-selection problem: find a sufficiently capable detector, deploy it beside the agent system, and reuse it across environments.

The paper’s distribution-shift results make that assumption difficult to sustain. On Agent-SafetyBench, the architecture-matched G-Safeguard detector rises from 0.512 AUROC off the shelf to 0.695 after centralized in-domain retraining. The architecture did not change. The deployment data did.

That difference matters because the observable surface of an agent system includes more than the final answer. Agents pass messages, call tools, and influence one another through a communication topology. FGLGuard represents each episode as a directed graph, encodes agents and their incoming communication histories, and uses a small edge-featured graph attention network to assign risk scores.

The operational interpretation is narrower than “every organization needs its own safety model.” Local-only training scores 0.666, 0.762, and 0.584 AUROC on Agent-SafetyBench, R-Judge, and AgentDojo, below the corresponding FGLGuard results of 0.726, 0.895, and 0.680. Under extreme label skew, isolated clients can deteriorate toward chance.

So the design problem has two constraints at once: the guard needs local evidence, but any one deployment may not have enough representative safety data to learn reliably by itself.

Federation shares adaptation without pooling the raw episodes

FGLGuard’s answer is to let each participant train on its private episode graphs while exchanging model parameters rather than the underlying prompts, messages, and tool outputs.

The local training objective adds a FedProx-style penalty that discourages a client from drifting too far from the current global model. That choice becomes more relevant as client data become non-IID. At fully pure client splits in the paper’s label-skew test, FedAvg reaches 0.522 AUROC while the proximal version reaches 0.578.

This is a stress test rather than the paper’s main deployment result, but it explains why federation here is more than a transport mechanism. If participating organizations observe different proportions or kinds of unsafe behavior, unconstrained local optimization can pull the shared detector in incompatible directions.

The cross-domain experiment makes the other requirement visible. A federated guard trained across four domains reaches AUROC values of 0.998, 0.673, 0.797, and 0.589. Matched multi-domain centralized training records 0.998, 0.662, 0.798, and 0.619. Federation stays within 0.03 AUROC on every domain in that experiment.

But single-domain specialists do not provide the same coverage: average off-domain performance is only about 0.537–0.573. A participant cannot simply consume another organization’s safety knowledge and assume its own environment is covered. In the reported setting, each domain still needs to contribute local traces.

Aggregation is also a governance decision

Ordinary federated averaging can give the largest dataset the greatest influence. That is reasonable when all records are samples from roughly the same target distribution. It is more questionable when the participants represent distinct safety domains.

FGLGuard therefore gives each domain equal total aggregation mass, then weights clients within that domain by their node counts. When the paper replaces this rule with conventional size-weighted aggregation, R-Judge AUROC falls from 0.797 to 0.713 and AgentDojo from 0.589 to 0.519.

For a consortium, this is not merely an optimization detail. Cognaptus inference: the aggregation rule becomes part of the governance design. A high-volume participant can otherwise exert disproportionate influence even when a smaller participant represents a failure mode the shared guard still needs to recognize.

That does not establish that equal domain weighting is universally correct. It shows that training volume and safety importance are not automatically the same quantity.

Better detection is not yet a deployment policy

AUROC tells operators how well a detector ranks risky versus benign cases across thresholds. It does not tell them where to place the threshold.

FGLGuard makes that decision explicit. It selects the threshold that maximizes unsafe recall while requiring benign false positives to remain below a chosen budget $\rho$:

At $\rho=0.05$, the reported benign block rate across six capability workloads remains between 0 and 0.05. By comparison, the tested LLM judge blocks 17%–54% of benign traffic and can produce substantially larger capability losses.

The guard also uses topology at intervention time. An acting agent’s score is corroborated with the maximum score among its direct upstream senders. Because this raises both true-positive and false-positive blocking at a fixed threshold, the paper calibrates the threshold on the same corroborated statistic used at deployment.

Finally, a flagged final answer is not immediately discarded. The system allows one safety-oriented rewrite, re-scores it, and releases it only if it passes. In the intervention ablations, guarding intermediate tool calls as well as final answers lowers completion without improving safety, while final-answer guarding with a corroborated rewrite preserves more task completion.

This is the part of the architecture most directly tied to product behavior: detection, thresholding, and remediation are separate decisions.

Live results connect the detector to security and utility

The paper’s strongest runtime evidence comes from AgentDojo’s programmatic evaluation harness. Targeted attack success falls from 0.401 without the guard to 0.230 with FGLGuard, a reported 43% relative reduction. Clean utility rises from 0.575 to 0.650.

Those numbers matter more operationally than another AUROC increment because they measure whether the intervention changes the outcome operators actually care about: attacks succeeding and legitimate tasks completing.

The detector itself is also small—about 0.5 million parameters—and the reported guard check takes roughly 50 ms on CPU without an inference-time API call. Cognaptus inference: that makes a graph guard plausible as a sidecar safety component where invoking a large language model as judge on every action would impose larger latency, cost, or availability dependencies.

The privacy and deployment boundaries are substantial

“Privacy-preserving” has a specific meaning here. Raw episode graphs stay local, but model updates and scalar calibration information are still shared. The paper does not provide a differential-privacy guarantee or a cryptographic argument that those updates cannot leak information.

The federation is also simulated rather than run across independently administered organizations. Threshold guarantees hold by construction on calibration data, not distribution-free on future traffic, so each deployment still needs representative validation traffic.

Several conclusions also depend on supervised safety labels, whether from benchmarks, programmatic checks, or judges. And although the paper tests topology changes, larger teams, label skew, and a Qwen3-8B agent backbone, these are robustness checks around the studied system—not evidence that one learned guard is invariant to arbitrary orchestration changes.

For an organization evaluating this design, those boundaries point to the next validation work: test the guard on its own communication structure, model stack, benign traffic, and attack distribution; recalibrate its operating point locally; and assess whether sharing model updates satisfies the organization’s actual privacy requirements.

Shared safety still needs local evidence

The paper changes the decision from “centralize the safety data or train alone” to a more useful third option: collaborate on the detector while keeping raw interaction traces inside each deployment.

Its deeper contribution is showing why that collaboration cannot be treated as generic model sharing. Local distributions matter. Participant weighting matters. Blocking tolerance matters. The communication graph matters. And a new domain cannot assume that somebody else’s traces are an adequate substitute for its own.

That makes federated multi-agent safety as much a problem of operating policy and evidence coverage as one of model architecture.

Cognaptus: Automate the Present, Incubate the Future.