HARP: Measuring Harm Amplification in Multi-Agent LLM Systems

Direct Answer

The paper introduces HARP (Harm Amplification through Role Perturbation), a trace‑first methodology that quantifies how a localized compromise in a multi‑agent LLM workflow can cascade into system‑wide damage. By measuring both local and global deviations, HARP reveals the amplification factor that traditional attack‑success metrics miss, offering a concrete way to evaluate and harden agent orchestration pipelines.

Background: Why This Problem Is Hard

Multi‑agent LLM systems have become the de‑facto architecture for complex AI applications—think automated financial advisors, customer‑service bots, or autonomous research assistants. These pipelines split a high‑level goal into a sequence of specialist agents, each equipped with tools, memory stores, and decision gates. While modularity improves interpretability and scalability, it also creates a propagation surface: a single perturbed output can be re‑ingested by downstream agents, magnifying the original error.

Current safety evaluations focus on binary outcomes—did an attack bypass a guard or not? Such “bypass‑only” metrics ignore the nuanced ways that a small deviation can be amplified through shared context, tool calls, or persistent memory. Moreover, most defenses are tested in isolation, without accounting for the feedback loops inherent in orchestrated agents. This gap leaves practitioners blind to a class of systemic harms that only emerge when the whole trace is considered.

What the Researchers Propose

HARP reframes the safety problem as a trace‑first analysis. Instead of looking at a single decision point, the methodology records a full execution trace for both a clean run and a deliberately perturbed run. The trace captures:

• Specialist agent outputs (text, tool arguments, etc.)
• Tool invocation logs and responses
• Memory reads and writes across the workflow
• Guard events (pre‑tool checks, step‑level filters)
• Oracle annotations that label intended vs. malicious behavior
• Latency and token‑cost metrics for performance context

From these traces, HARP defines two complementary metrics:

1. Local Harm (H_local): the deviation observed at the directly attacked component (e.g., a compromised specialist or corrupted shared context).
2. Global Harm (H_global): the cumulative deviation measured over the entire trace, reflecting how downstream agents react to the polluted input.

The harm amplification factor is then computed as H_global / H_local. A factor greater than one indicates that the system magnifies the original breach, while a factor near one suggests containment.

How It Works in Practice

To illustrate HARP, the authors built a finance‑oriented orchestration consisting of seven agents:

1. Market Analyst – parses market news.
2. Risk Evaluator – computes risk scores.
3. Portfolio Optimizer – suggests asset allocations.
4. Compliance Checker – validates regulatory constraints.
5. Trade Executor – formats orders for a broker API.
6. Memory Store – persists intermediate calculations.
7. Decision Gate – a deterministic rule that either approves or rejects the final trade plan.

Each agent communicates through a shared context object and may invoke external tools (e.g., a price‑feed API). HARP injects perturbations at four distinct points:

• Specialist Compromise – directly overwriting an agent’s output.
• Collusion – multiple agents coordinated to reinforce a malicious narrative.
• Shared‑Context Corruption – tampering with the global data structure that all agents read.
• Temporal Persistence – planting malicious data that survives across multiple workflow executions.

During each run, the system logs the full trace, then computes H_local and H_global. The approach differs from prior work in two key ways:

• Trace‑Centricity: Instead of a snapshot, HARP evaluates the entire causal chain, exposing hidden feedback loops.
• Amplification Metric: By normalizing global impact with the local breach size, HARP isolates the orchestration’s contribution to harm, independent of attack potency.

Evaluation & Results

The authors evaluated HARP across five defensive configurations:

1. Prompt‑Only Guard – static prompts that discourage harmful requests.
2. Pre‑Tool Guard – filters before any external tool call.
3. Step‑Level Guard – checks after each agent’s output.
4. IntegrityGuard – a trace‑consistency validator that flags deviations from an expected execution pattern.
5. No Guard (baseline).

Key observations include:

• Single‑Specialist Compromise produced the highest amplification (average factor ≈ 3.2), showing that a lone corrupted expert can mislead the entire pipeline.
• Shared‑Context Corruption achieved the highest attack success rate (≈ 78 % of runs bypassed the decision gate), but its amplification factor was modest (≈ 1.5) because downstream agents performed limited additional processing.
• Temporal Persistence generated the largest absolute global harm, as malicious data persisted across multiple workflow cycles, compounding losses.
• Among defenses, IntegrityGuard reduced both attack success and amplification the most, but introduced a latency overhead of ~ 250 ms per trace and a modest drop in benign utility.
• Prompt‑Only guards preserved performance and utility but failed to curb amplification, highlighting the insufficiency of static prompt engineering for systemic safety.

Overall, the experiments demonstrate that measuring only whether an attack succeeds hides a richer picture: some defenses may stop a breach outright, while others merely limit its spread. HARP makes that distinction quantifiable.

Why This Matters for AI Systems and Agents

For practitioners building production‑grade AI agents, HARP offers a concrete diagnostic tool that goes beyond “did the guard fire?” It answers the more operational question: how much damage could a compromised component cause if it slips through? This insight drives three practical shifts:

• Design‑time Hardening: Engineers can prioritize integrity checks around components that historically exhibit high amplification (e.g., specialist outputs that feed many downstream agents).
• Continuous Monitoring: By logging full traces in real time, teams can compute live amplification scores and trigger alerts when a spike is detected.
• Benchmarking Defenses: HARP’s normalized metric enables apples‑to‑apples comparison of guard strategies, informing cost‑benefit analyses for latency versus safety.

These capabilities align directly with the needs of enterprises adopting the Enterprise AI platform by UBOS, where orchestrated agents handle sensitive financial or regulatory workflows. Embedding HARP‑style trace analysis into the platform’s Workflow automation studio would give product managers a safety dashboard that quantifies systemic risk in real time.

What Comes Next

While HARP establishes a solid foundation, several open challenges remain:

• Scalability: Full trace logging can be storage‑intensive for large‑scale deployments. Future work should explore summarization techniques that preserve amplification signals while reducing overhead.
• Adaptive Defenses: Current guards are static. Integrating reinforcement‑learning agents that adjust guard thresholds based on observed amplification could yield smarter, context‑aware protection.
• Cross‑Domain Generalization: The paper’s finance scenario is a useful testbed, but other domains (healthcare, legal, autonomous robotics) have different toolsets and risk profiles. Extending HARP to heterogeneous tool ecosystems will broaden its applicability.
• User‑Facing Transparency: Providing end‑users with understandable explanations of why a particular trace was flagged (e.g., “Your request altered the risk score beyond safe limits”) can improve trust and compliance.

Addressing these gaps will likely involve tighter integration with platform‑level observability stacks. For teams already leveraging the UBOS platform overview, adding a “HARP module” could be as simple as enabling trace export to the built‑in analytics engine, then visualizing amplification heatmaps alongside existing performance metrics.

Illustration of the HARP Workflow

The diagram below visualizes the end‑to‑end trace collection and amplification calculation process. It highlights where perturbations are injected, how logs are aggregated, and where the IntegrityGuard sits in the pipeline.

Call to Action

If you’re building multi‑agent solutions and need a systematic way to assess systemic risk, explore the UBOS templates for quick start or reach out via the UBOS partner program. Our About UBOS page provides more context on how we help enterprises secure AI orchestration pipelines.

For the full technical details, see the original arXiv paper.