Detects LLM tool definitions without parameter validation, allowing prompt injection to escalate into file/shell/network access. Use when writing LLM tool definitions, function schemas for tool use, plugin or extension handlers, or any code that defines what actions an LLM can take via tools. Also invoke when implementing tool parameter validation.
Detects LLM tool definitions without parameter validation, allowing prompt injection to escalate into file/shell/network access. Use when writing LLM tool definitions, function schemas for tool use, plugin or extension handlers, or any code that defines what actions an LLM can take via tools. Also invoke when implementing tool parameter validation.
Insecure Plugin Design (OWASP LLM07:2025)
What this checks
Prevents LLM tools and plugins from being abused via malicious or malformed inputs
driven by prompt injection or jailbreaks. Unvalidated tool parameters let an attacker
escalate from a chat window to arbitrary file access, command execution, or data
exfiltration.
Vulnerable patterns
Tool handler accepts an unconstrained string parameter (path, URL, query) with no allowlist, regex, or length cap
Tool schema declares parameters with no enum, maxLength, pattern, or additionalProperties: false constraints
Authorization decision delegated to the LLM rather than enforced inside the tool handler against the invoking principal
Single tool multiplexes read, write, and delete behind an action parameter instead of separate handlers
Tool invocation produces no audit record naming the principal, tool, and sanitized arguments
Fix immediately
Flag the vulnerable code and explain the risk. Translate the principles below to the
audited file's language, tool-definition schema, and authorization framework — use
that stack's documented validation and access-control APIs.
For each finding, establish these properties:
Every tool input is constrained at the tool boundary. JSON Schema keywords
(maxLength, pattern, enum, additionalProperties: false), a typed enum
or sealed class, runtime validation at the top of the handler, or an allowlist
lookup — the goal is that a malformed value never reaches the handler body.
Authorization runs inside the handler against the invoking principal — not
outsourced to the LLM's judgment, not inferred from the caller, not handled
only by an outer framework layer. The LLM is an attacker in the threat model;
it cannot be trusted to gate its own actions.
File and path identifiers are canonicalized and verified against an explicit
root. Resolve the path, then check that the resolved target falls inside the
allowed directory. Path traversal, symlink escape, and absolute-path injection
all fail this check.
Tools expose the narrowest capability that satisfies their purpose. Read,
write, and delete live in separate handlers, not multiplexed behind an
action parameter. Narrow tools are easier to audit and harder to weaponize.
Every invocation produces an audit record containing the principal, the
tool name, and sanitized parameters — written before the side-effecting
operation returns.
Verification
Confirm the following properties hold (language-agnostic):
Every tool input is constrained at the tool boundary by some concrete mechanism — JSON Schema keywords (maxLength/pattern/enum/additionalProperties: false), a typed enum or sealed class in the method signature, runtime regex/length validation at the top of the handler, or an allowlist lookup against a static set — before the value is used
Authorization is enforced inside the tool handler itself against the invoking principal — not delegated to the LLM's judgment, not assumed from the caller, and not handled only by an outer framework layer
File, path, or resource identifiers supplied by the LLM are canonicalized and verified to fall within an explicit allowed root or allowlist before any I/O — path traversal, symlink escape, and absolute-path injection are all rejected
Each tool exposes the narrowest capability that satisfies its purpose — read, write, and destructive operations are separated into distinct tools/handlers rather than multiplexed behind a single action parameter
Every tool invocation produces an audit record containing the invoking principal, the tool name, and the (sanitized) parameter values, written before the side-effecting operation returns
