Workflow Disruption via Dependency Exploitation

Definition

The RPA agent is part of a larger Agent-to-Agent (A2A) workflow involving an approval agent, a payment processing system, and an external bank API. An attacker disrupts the workflow by targeting a dependent system rather than the RPA agent directly. The RPA agent continues to function correctly, but the pipeline it depends on is unavailable or degraded, causing denial of service for legitimate claims. This is distinct from T2 Tool Misuse, which requires direct interaction with the primary agent.

What it looks like in practice

An attacker floods the approval agent (a downstream service in the A2A pipeline) with a high volume of fabricated approval requests. The approval agent becomes overwhelmed and begins queuing or dropping requests. The RPA agent submits legitimate claims and waits for approval responses that never arrive within the configured timeout. Claims expire and must be resubmitted manually, degrading throughput and creating an operational backlog.

The attack need not target the most hardened component; it targets the weakest link in the dependency chain. A shared approval microservice that is less hardened than the primary RPA agent becomes the effective attack surface for the entire workflow.

Why it’s dangerous in multi-agent context

Multi-agent workflows create dependency chains. Each agent in the chain is a single point of failure for every agent upstream of it. Because the RPA agent trusts its downstream dependencies to be available and responsive, no individual agent detects that the system-wide denial of service is adversarial rather than a transient outage. Without circuit-breaker patterns and independent retry budgets, the cascading failure propagates silently: claims accumulate in the RPA agent’s queue while the approval backlog grows.

Detection signals

The attack presents as a dependency availability problem; detection requires distinguishing adversarial flood from organic load increase by examining the source and shape of requests hitting the approval agent.

• A spike in the approval agent’s inbound request rate that is not correlated with a corresponding rise in RPA-agent claim submission events. If requests arriving at the approval agent exceed the volume the RPA agent could plausibly have generated, the excess is from a fabricated source.
• Approval agent queue depth crossing a defined ceiling (e.g. > 500 pending requests) while the approval agent’s CPU and memory utilisation remain low. This is indicative of a connection-exhaustion or head-of-line-blocking attack rather than genuine processing load.
• A sustained rise in timeout events logged by the RPA agent for approval responses, without any corresponding error events from the approval agent itself. The approval agent may be healthy but overwhelmed at the queue layer; alert when RPA-side timeout rate exceeds 5 % of submissions over a 5-minute window.
• A high proportion of fabricated approval requests sharing identical or templated payload structures (e.g. all using the same submitter_id, all with identical claim amounts). Inspect inbound request diversity at the approval agent and alert on low payload entropy.
• The circuit-breaker counter incrementing at a rate that exceeds its historical maximum (baseline from normal operations). A sudden burst of consecutive timeouts that opens the breaker faster than any known peak-load event is a strong indicator of adversarial flooding.

Mitigations

• Map the full dependency graph of the A2A workflow; assign a maximum acceptable latency and an availability SLA to each dependency.
• Implement circuit-breaker patterns: after a defined number of consecutive timeouts from a downstream agent, the RPA agent stops forwarding new requests and enters a degraded mode rather than accumulating queue depth.
• Rate-limit inbound requests to the approval agent to prevent flood-based exhaustion; enforce admission control before the request reaches the processing queue.
• Design fallback paths: claims that cannot be approved within the SLA window should route to a human reviewer queue rather than silently expiring.

Relation to base threat (T1–T17)

T25 extends T4 Resource Overload. Where T4 targets the primary agent’s own resources, T25 targets a dependent agent or system, achieving denial of service indirectly. T32 (Runaway Agent on Solana) and T39 (Unintended Resource Consumption via MCP) are the self-inflicted resource exhaustion variants: the agent itself is the source of the overload rather than an external attacker.