synodic-ai AI SECURITY
AI Security Desk · Agent Security Evaluation

The Score Is Not the Defense: Ignored Injections, Stranded Detections, and Refusals That Stay in the Chat

2026-10-19

Three papers posted to arXiv on 2026-10-16 find the same gap from three directions: the number an agent-security program reports does not describe what actually stopped, or failed to stop, the attack. A low prompt-injection success rate mostly records agents ignoring instructions, a detector that fires can still be cut off from the block decision, and refusal learned in conversation does not carry over to agents that act inside phone apps.

A low attack success rate is mostly silence

Tool-using agents read untrusted external content, which exposes them to indirect prompt injection: hidden instructions in that content hijack the agent's tool calls. Benchmarks score this threat with the attack success rate, and in doing so treat every failed attack as a successful defense. Farhan Zarif and colleagues test that assumption by auditing 33,000 trajectories from eleven open-weight agents of 2 to 14 billion parameters on the InjecAgent and AgentDojo benchmarks.

A label-blind LLM judge classifies what happened when an attack failed. Most failed attacks were ignored (76 to 80 percent) rather than refused (17 to 18 percent). The agent did not recognize and decline the injected instruction; it simply did not act on it. Nor is the low rate a fixed property of the weights: with identical weights, changing only the system prompt moved the InjecAgent attack success rate from 0.2 percent to 43 percent.

The authors' Attack-Task Outcome Matrix adds a second axis. In 21.7 percent of AgentDojo episodes the agent stayed safe but did not complete the user's task, an outcome a success-rate-only report counts as a clean defense. The paper's conclusion is direct: a low attack success rate mostly reflects agents silently ignoring injections, so evaluations should report how attacks fail and whether the user's task was completed, alongside the rate itself. The labeled corpus, judge prompt and analysis code are released.

Detection that never reaches the decision

Junchi Liao looks one layer down, at the runtime monitors that LLM applications rely on to inspect tool calls, traces, streams, detector outputs and verifier inputs. The problem is interface reliability: a framework path can keep working while the evidence a policy needs never reaches its decision point. In one representative case a regex detector returned a positive match, but the framework stranded that result before the block decision. This is neither a jailbreak nor a detector error; the evidence was already recognized, and it was disconnected from enforcement.

To find such failures the paper uses canary contracts: paired parent and fixed confirmation units that place a known payload only on the evidence surface a change touched, then record both whether the monitor saw it and what the downstream decision was. Applied to public framework repairs, the protocol confirms 18 evidence-path failures across 11 LLM or agent safety project groups and four implementation ecosystems. Nine are established-boundary repairs, eight are new-surface policy-coverage gaps and one is a boundary-only evidence case. Fourteen reach enforcement boundaries, seven of them native action outcomes, six configured enforcement boundaries and one a synthetic-consumer consequence; the rest affect verifier, safety-prompt or observability channels.

The cases cluster into carrier, adapter, authority and surface families, and they share one property: ordinary application behavior stays intact while the safety-specific evidence path misses its decision. Nothing visibly breaks. The paper documents its confirmation rule with exact revisions, deterministic outcomes, negative controls and a frozen prospective audit, and concludes that monitor assumptions need regression tests at the schemas, streams, tools and adapters that frameworks keep changing.

Refusal learned in chat does not travel to the phone

Songping Wang and colleagues turn to multimodal mobile agents, which perceive, plan and execute in closed loops in dynamic mobile environments, and whose misuse risks include privacy leakage, device compromise and large-scale phishing. They argue that existing jailbreak evaluations leave three gaps for these agents: they focus on conversational attacks rather than mobile workflows, they use static task sets of fixed difficulty, and they rely narrowly on attack success rate instead of a fuller security assessment.

MobileJailBench answers with 520 tasks spanning three jailbreak paradigms and 14 risk categories, run in a mobile sandbox the authors built that supports realistic workflows across more than 20 widely used apps. Its Dual-Dynamic Evolution component combines Failure-Distilled Jailbreak Evolution with Weakness-Driven Benchmark Expansion, so the attacks and the task set grow as weaknesses are found. A Stratified Adjudication Framework scores security awareness, execution behavior and risk consequences separately.

The finding is that current mobile agents are particularly vulnerable to implicit jailbreaks, because their safety alignment remains largely superficial and does not generalize from conversational refusal to dynamic mobile interactions. The evolving attack set reached a 100 percent attack success rate on a 122-billion-parameter model. In practice, a refusal observed in chat is weak evidence about what the same agent will do once it is executing a mobile workflow.

One gap, measured three ways

Read together, the papers locate the same failure at three points in an agent's pipeline. At the model, a failed attack is usually an instruction the agent happened not to follow, and the system prompt can change that by two orders of magnitude. At the framework, a detection can be correct and still never reach the component that blocks. At deployment, a refusal behavior learned in one interaction mode does not appear in another.

Each paper also rejects a single headline metric. The injection audit asks for failure modes and task completion next to the success rate; the mobile benchmark separates awareness, execution and consequences; the monitor study asks whether evidence and decision are actually connected. In all three, the reassuring number is a property of the configuration under test, not a guarantee that carries over to the next prompt, framework release or interface.

What security teams should change

These are research results on specific benchmarks, frameworks and sandboxes, so they mark where to look rather than settled thresholds.

Sources