⭐ Star on GitHub

Summary: Manipulating an agent into abusing tools it is legitimately authorised to hold (T2), and exploiting AI-generated code execution environments (T11) — the action half of OWASP’s two key agentic attack vectors.

Sources: raw/Agentic/Agentic-AI-Threats-and-Mitigations-1.1.pdf

Last updated: 2026-07-29


T2 — Tool Misuse

“Tool Misuse occurs when attackers manipulate AI agents into abusing their authorized tools through deceptive prompts and operational misdirection, leading to unauthorized data access, system manipulation, or resource exploitation while staying within granted permissions” (source: Agentic-AI-Threats-and-Mitigations-1.1.pdf, p. 25).

That last clause is the whole problem. No permission boundary is crossed. Every individual action is authorised. What makes the sequence malicious is intent, and intent is not a property any access control system can evaluate.

OWASP identifies chaining as the amplifier: the attack “leverages AI’s ability to chain tools and execute complex sequences of seemingly legitimate actions, making detection difficult.” Natural language flexibility is the delivery mechanism — attackers “exploit natural language flexibility to bypass security controls.”

Agent Hijacking is named as a sub-case in the T1–T17 table: an agent “ingests adversarially manipulated data and subsequently executes unintended actions, potentially triggering malicious tool interactions” (p. 16), citing NIST’s technical blog.

Relation to Excessive Agency

The threat is “partially covered by LLM06:2025 Excessive Agency” (p. 25) — partially, and OWASP explains the gap:

Unlike traditional LLM applications which constraint tools integration within a session, agents maintain memory adding to increased autonomy and can delegate execution to other agents increasing the risk of unintended operations.

Two things break the LLM06 model: memory (the action’s justification can be planted in a prior session) and delegation (the acting agent is not the agent that was manipulated). Also related: LLM03 Supply Chain, and LLM08 when RAG runs through a tool.

Six scenarios

From pp. 25–26:

  1. Parameter Pollution — manipulating a booking function call to reserve 500 seats instead of one. The tool worked correctly; the argument was wrong.
  2. Tool Chain Manipulation — chaining a customer-service agent’s actions to extract high-value records and email them out.
  3. Automated Tool Abuse — a document-processing agent tricked into generating and mass-distributing malicious documents, executing a phishing campaign unknowingly.
  4. Via Memory Poisoning — injecting into persistent memory so the agent acts on manipulated data across sessions (T1 as delivery for T2).
  5. Via Vector Database — adversarial content in the vector store poisons long-term memory and drives unsafe retrieval.
  6. Via Prompt Injection — goal manipulation leading the agent to misuse a shell tool.

Scenarios 4–6 are notable for being composed — T2 is reached through T1, LLM08 and T6 respectively. Tool misuse is rarely the initial access; it is the payload.

T11 — Unexpected RCE and Code Attacks

“Attackers exploit AI-generated execution environments to inject malicious code, trigger unintended system behaviors, or execute unauthorized scripts” (p. 27).

OWASP distinguishes it from LLM01 Prompt Injection and LLM05 Improper Output Handling on the grounds that “agentic AI with function-calling capabilities and tool integrations can be directly manipulated to execute unauthorized commands” — there is no human or downstream system between the model output and execution.

Scenarios (p. 27):

  1. DevOps Agent Compromise — a DevOps agent generates Terraform containing hidden commands that extract secrets and disable logging.
  2. Workflow Engine Exploitation — an automation system executes AI-generated scripts with embedded backdoors, bypassing validation.
  3. Exploiting Linguistic Ambiguities — ambiguous natural-language commands to an email agent cause exfiltration via POP3.

Scenario 1 is the one to internalise: the malicious payload is infrastructure-as-code, so it inherits deploy-time privilege and disables the very logging that would catch it.

Mitigations

T2 and T11 share Playbook 3 with T3, T4, T16 and T17 (pp. 37–38).

Proactive

  • Strict tool access control; limit which tools an agent may execute at all
  • Function-level authentication before any tool use
  • Execution sandboxes — isolated containers, no sensitive system or network access; CPU/memory limits and syscall restriction; sandbox destroyed or reset after each execution to block persistence and lateral movement
  • Sandboxing enforced especially for tools invoked via A2A or MCP, since those calls “may bypass user interfaces, consent flows, or direct human oversight”
  • Rate-limiting for API calls and expensive tasks
  • Just-in-time access — grant on demand, revoke immediately after
  • Real-time risk scoring to gate execution
  • Version control and peer review for prompt/script repositories, “just as for code”
  • Digitally sign agent cards, prompt templates and tool definitions; verifiable AI SBOM / AIBOM / Agent SBOM

Reactive

  • Log all tool interactions with forensic traceability
  • Detect command chaining that circumvents policy
  • Explicit user approval for financial, medical or administrative executions
  • Human verification before executing AI-generated code with elevated privileges
  • Flag abnormal tool execution frequency and unintended side effects

Detective

  • Monitor workload; auto-suspend processes exceeding thresholds
  • Track cumulative consumption across agents
  • Limit concurrent system-modification requests
  • Monitor supply chain dependencies via SBOM; red-team with simulated poisoned components

The sandbox controls are the only ones here specified concretely enough to implement without further design. Everything addressing chaining — the actual novelty of T2 — remains detective and heuristic.