Secure AI Atlas mark Secure AI Atlas SECURITY & GOVERNANCE

Article

Beyond the Leaderboard: A Synthesis of Tool-Use, Planning, and Reasoning Failures in Large Language Model Agents

A synthesis of known failure modes in LLM-based agents, covering tool-use errors, planning breakdowns, and reasoning vulnerabilities that compound into systemic security risks.

llm-agents tool-invocation planning reasoning prompt-injection excessive-agency auditability insecure-tool-invocation arxiv

Overview

Benchmark scores dominate the narrative around large language model (LLM) agents. Models are ranked on static question-answering datasets, code generation suites, and multi-turn dialogue tasks. But these leaderboards tell only a partial story. When an LLM is placed inside an agentic loop — given tools to call, long-running plans to execute, and real-world consequences to manage — a new class of failures emerges.

A recent synthesis of failure modes in LLM-based agents, published on arXiv in July 2026, draws together findings from across the AI safety and security literature to map how these breakdowns occur and compound. The work connects three failure families — tool-use errors, planning failures, and reasoning vulnerabilities — and traces their implications for building trustworthy autonomous systems.

Why Agent Failures Deserve a Closer Look

LLM agents differ from stateless chatbots in a critical way: they act. An agent receives a goal, formulates a plan, selects tools, invokes them, observes outcomes, and iterates. Each step in that loop introduces surface area for error — and for exploitation.

Traditional LLM evaluation measures how well a model answers a single prompt. Agent evaluation must measure how well a model handles stateful, multi-step interaction with external systems. A model that scores 90% on a reasoning benchmark may still fail catastrophically when given a tool that can edit files, call APIs, or execute code — especially if the environment is adversarial or underspecified.

The Three Failure Families

Tool-Use Failures

When an agent is equipped with tools — APIs, database queries, file system operations, shell commands — it must decide which tool to call, with what arguments, in what order, and whether the outcome is valid. Failures in this domain include:

  • Tool selection errors: The agent chooses the wrong tool for the task, either because the tool description is ambiguous, the goal is misinterpreted, or the agent lacks a model of tool side effects.
  • Argument grounding errors: The agent constructs syntactically valid but semantically incorrect arguments — for example, passing a user ID where a document ID is expected.
  • Tool invocation under adversarial input: Prompt injection and indirect prompt injection can hijack tool selection. If an attacker embeds instructions in data that the agent reads, the agent may be steered into calling tools it should not.
  • Tool output misinterpretation: Even when a tool returns correct data, the agent may misinterpret the result, leading to downstream errors or repeated incorrect calls.

Work on insecure tool invocation has shown that agents often lack the ability to validate tool outputs or detect when a tool has been called maliciously. The tool itself becomes an attack surface.

Planning Failures

Agents that operate over multiple steps must maintain and execute a plan. Planning failures in LLM agents include:

  • Plan rigidity: The agent commits to a plan and fails to revise it when new information contradicts the original assumptions.
  • Subgoal decomposition errors: The agent breaks a task into subgoals that are incomplete, redundant, or impossible to satisfy.
  • State tracking failures: The agent loses track of what it has already done, leading to repeated actions, infinite loops, or irreversible operations.
  • Resource management errors: The agent exhausts context windows, rate limits, or time budgets without completing the task, and may terminate in an inconsistent state.

These failures are especially dangerous in contexts where an agent has excessive agency — the ability to take actions that are costly, destructive, or irreversible without human oversight. An agent that cannot revise its plan when a tool returns a warning may delete files, overwrite records, or trigger financial transactions before a human can intervene.

Reasoning Vulnerabilities

Reasoning failures are the most studied of the three families, but their manifestation in agentic systems has distinct characteristics:

  • Chain-of-thought brittleness: Agents prompted to reason step-by-step may produce plausible but incorrect chains, especially under distribution shift or adversarial prompting.
  • Confirmation bias in multi-step reasoning: The agent prioritizes evidence that supports its current hypothesis and discards contradictory tool outputs.
  • Over-reliance on learned patterns: The agent generalizes from training data in ways that are inappropriate for the current task, particularly when tool interfaces or environmental conditions differ from those seen during training.
  • Failure to recognize uncertainty: Agents rarely express calibrated confidence. They may proceed with low-confidence reasoning as if it were certain, acting on flawed conclusions.

Prompt injection — both direct and indirect — exploits these reasoning vulnerabilities. An injected instruction that bypasses the agent’s reasoning guardrails can cause it to generate a seemingly logical argument for a dangerous action.

How the Families Compound

The synthesis emphasizes that these failure families do not operate in isolation. They compound in practice.

A planning failure leads the agent to call a tool at the wrong time. A reasoning vulnerability causes it to misinterpret the tool’s output. A tool-use error then executes the wrong operation because the agent misreads the next step. The combination of excessive agency and lack of auditability means that by the time a human reviews the log, the damage has already occurred.

For example, consider an agent tasked with updating a customer record:

  1. The agent’s plan includes reading the record, applying the update, and sending a confirmation. But it fails to include a validation step.
  2. The tool invocation is hijacked by an indirect prompt injection hidden in the customer’s notes field, which instructs the agent to add an unauthorized admin user.
  3. The agent’s reasoning accepts the injected instruction as part of the legitimate task, producing a chain of thought that justifies the action.
  4. Because the agent has excessive agency, it executes the admin creation without requesting human approval.
  5. Because of lack of auditability, the sequence of events is difficult to trace after the fact.

Connections to Established Security Frameworks

The failure modes described in this synthesis map directly to established AI security taxonomies:

  • OWASP LLM Top 10: The tool-use and reasoning failures align with categories such as Prompt Injection (LLM01), Insecure Output Handling (LLM02), and Excessive Agency (LLM08).
  • MITRE ATLAS: The planning and state-tracking failures map to techniques under Persistence, Privilege Escalation, and Impact.
  • NIST AI RMF: The compounding nature of failures across all three families relates directly to the Measure and Manage functions — particularly in understanding model behavior under adversarial conditions.

The synthesis reinforces that agent security is not a single-vulnerability problem. It emerges from the interaction of model capabilities, tool design, planning logic, and oversight mechanisms.

What This Means for Building Safer Agents

The findings point toward several practical priorities for anyone building or deploying LLM agents:

  • Constrain tool access by principle, not convenience: Grant each agent only the tools it needs for its specific task. Use read-only tools where write access is unnecessary. Require human-in-the-loop confirmation for any tool that can cause irreversible change.
  • Implement visibility and audit trails: Every tool invocation, plan step, and reasoning trace should be logged in a tamper-evident format. Auditability is not optional for agents that operate on sensitive data or critical systems.
  • Design for plan reversibility: Where possible, ensure that an agent’s actions can be rolled back. Version-controlled file systems, staged database transactions, and approval gates for destructive operations limit the blast radius of a failure.
  • Test under adversarial conditions: Evaluate agents not only on happy-path benchmarks but on adversarial prompts, injected instructions, tool failures, and ambiguous state. The standard should be robustness, not leaderboard position.
  • Establish confidence thresholds: Build agents that can detect when their own reasoning confidence is low and pause for human input. Explicit uncertainty handling reduces the risk of acting on flawed conclusions.

Conclusion

Leaderboard performance is a poor proxy for agent safety. The synthesis of tool-use, planning, and reasoning failures shows that LLM agents break in ways that benchmarks do not capture. These failures are not theoretical edge cases — they are systemic patterns that emerge when models are given agency.

Building trustworthy agents requires looking beyond the leaderboard. The real benchmark is whether an agent can detect when it is uncertain, decline an instruction it cannot safely execute, and leave an auditable trace of every action it takes. Until agents can do all three, human oversight, constrained tool access, and rigorous adversarial testing remain the most important safety measures.


This analysis is based on “Beyond the Leaderboard: A Synthesis of Tool-Use, Planning, and Reasoning Failures in Large Language Model Agents” (arXiv:2607.05775, July 2026).