NetInjectBench exposes prompt injection in network agents
New research puts tool-using Large Language Model (LLM) agents through 130 network-ops scenarios and shows how indirect prompt injection in tickets, logs and chat can drive unsafe actions. Naive agents fail badly. Prompt tweaks help but leave gaps. A runtime, metadata-aware policy gate nearly eliminates unsafe actions without blocking approved changes.
Network operations are full of artefacts that no one fully trusts: tickets copied from chat, alerts with vendor blurb, runbooks edited at 3 a.m. Tool-using Large Language Model (LLM) agents sit in the middle of this mess and decide what to execute. NetInjectBench asks a blunt question: when the artefact text tells the agent to do something risky, does it obey.
The benchmark packages 130 scenarios that keep untrusted artefact text separate from trusted policy metadata. It covers 40 benign, 40 weak-attack and 40 strong-attack cases, plus 10 approved high-impact changes. The agent can call mock tools for low-risk reads, sensitive reads and high-impact writes. Two standout risky operations are apply_config_change and query_topology. Three local models face the trials: Qwen2.5-7B, Llama3.1-8B and Mistral-7B.
How the attacks land
The attacker controls only the artefact text. That is enough. Instructions embedded in a ticket, fake approvals, claims of urgent vendor guidance or a tweaked runbook nudge the agent into unsafe choices. In 240 attack instances, a naive agent ran unsafe final tool actions 82.50% of the time. Blocking writes alone does not save you. Sensitive reads like topology queries still spill the goods, and static allowlisting that looks tough on paper backfires in practice.
Prompt-level hygiene reduces but does not close the gap. Prompt-only safety brought unsafe actions down to 25.63%, Self-Reminder to 21.67%, and Spotlighting to 18.33%. A simple Two-Pass LLM Judge halved risk again to 10.00%. Static allowlisting of dangerous tools cut unsafe actions to 5.00% on attacks but blocked every approved high-impact change, delivering 0.00% usefulness and 100.00% overblocking in those cases.
Why the gate helps
The finding that matters for operations is the execution-time boundary. A deterministic, metadata-aware policy gate checks integrity-protected approval fields before it lets high-impact operations run. Under the stated assumption that metadata and the gate are not compromised, it recorded 0 unsafe actions out of 240 attacks, with a 95% Wilson upper bound of 1.58%, while preserving 99.17% usefulness in attack scenarios and 100.00% in approved-change scenarios.
Model behaviour diverged. Qwen2.5-7B and Mistral-7B were notably brittle when naive; Llama3.1-8B responded better to prompt guidance. Strong attacks stayed hard for prompt-only setups across the board.
There are limits. These are synthetic scenarios with mock tools, single-step plans and deterministic decoding. The threat model assumes clean metadata and a trustworthy gate. Real systems accumulate multi-step state and messy integrations. The policy question sits right there: can we keep the authorisation channel independent, auditable and hard to spoof when the artefact stream is hostile. If not, clever text will keep steering agents into real changes and sensitive reads, and your change-control story will be fiction.
Additional analysis of the original ArXiv paper
📋 Original Paper Title and Abstract
NetInjectBench: Benchmarking Indirect Prompt Injection in Tool-Using Large Language Model Agents for Network Operations
🔍 ShortSpan Analysis of the Paper
Problem
This paper examines indirect prompt injection in tool-using large language model agents applied to network and communication operations. Operational artefacts such as tickets, alerts, logs, runbooks and chat messages can contain untrusted natural-language instructions that an LLM agent may treat as executable intent, producing unsafe high-impact actions (for example applying configuration changes or exposing sensitive topology). The core issue is the missing boundary between evidence in untrusted artefacts and authoritative approval or authorisation metadata that should govern execution.
Approach
The authors introduce NetInjectBench, a benchmark of 130 structured scenarios that separates operator intent, untrusted artefact text, trusted policy metadata and evaluation labels. The sample comprises 40 benign, 40 weak-attack, 40 strong-attack and 10 approved high-impact change scenarios. Three local LLMs were evaluated: Qwen2.5-7B, Llama3.1-8B and Mistral-7B. The environment defines six mock tools representing low-risk reads, sensitive reads and high-impact writes, with apply_config_change and query_topology as prominent risky operations. Seven execution settings were compared: naive execution, three prompt-level defences (prompt-only safety, Self-Reminder, Spotlighting), a Two-Pass LLM Judge, static allowlisting of the dangerous tool, and a deterministic metadata-aware policy gate that validates trusted authorisation fields before permitting high-impact operations. Metrics include unsafe tool-action rate (UTAR), useful action rate (UAR), block rate, overblocking rate and reliability measures; confidence intervals and paired statistical tests are reported. The threat model allows an attacker to control artefact text but not trusted metadata, tools or gate code.
Key Findings
- Naive execution is highly vulnerable: across 240 attack instances the naive agent produced 82.50% unsafe final tool actions.
- Prompt-level defences reduce but do not eliminate unsafe actions: prompt-only safety 25.63% UTAR, Self-Reminder 21.67%, Spotlighting 18.33%.
- A lightweight LLM-only post-check helps: Two-Pass LLM Judge reduced UTAR to 10.00%.
- Static allowlisting appears strong on attacks (5.00% UTAR) but blocks all approved high-impact changes, yielding 0.00% usefulness and 100.00% overblocking on approved cases.
- Metadata-aware policy gate under the metadata-integrity assumption produced 0 observed unsafe actions out of 240 attacks (95% Wilson upper bound 1.58%), while preserving 99.17% usefulness on attack scenarios and 100.00% usefulness on approved-change scenarios.
- Model variability matters: Qwen2.5-7B and Mistral-7B were especially vulnerable in the naive setting, while Llama3.1-8B responded better to prompt-level guidance; strong attacks remained harder for prompt-only baselines.
- Sensitive-read exposures (for example topology queries) persist under narrow write-blocking policies, demonstrating that blocking writes alone is insufficient.
Limitations
Key constraints include the metadata-integrity assumption (the gate relies on uncompromised trusted metadata), synthetic scenarios and mock tools rather than live infrastructure, a compact single-step tool set, evaluation on three local models with deterministic decoding, and exclusion of multi-step tool-output poisoning. External and construct validity are therefore limited and future work should expand models, real artefacts, multi-step agents and degraded metadata scenarios.
Implications
From an offensive-security viewpoint, an adversary who can plant or modify operational artefacts may induce a tool-using LLM agent to select unsafe operations: embedding direct instructions, fake approvals, fake vendor or security authority claims, poisoned runbook updates or emergency assertions can cause unauthorised configuration changes or sensitive-information disclosure. Narrow defences such as static blocking of writes can be bypassed to expose sensitive reads and will prevent legitimate authorised changes, so attackers can both trigger harmful actions and exploit overblocking to disrupt operations. The benchmark demonstrates that successful attacks exploit the absence of an execution-time authorisation boundary; maintaining separate, integrity-protected metadata channels for approval is therefore critical to prevent artefact-born manipulation from becoming executed infrastructure changes.
