# Tool Parameter Injection Payload

- **Severity:** High
- **Signature ID:** `6f3b1a94-2d7c-4e58-9b21-c05a7f8e3d16`
- **OWASP:** LLM05 (Improper Output Handling)

## Summary

This rule watches what an AI agent sends to the tools it controls, looking for text shaped like shell escape sequences, SQL injection, path traversal, or template injection. If that same suspicious pattern later shows up in a command actually spawned by the agent, it confirms the payload reached a real execution context, not just a log entry.

## How the attack works

An attacker (or a compromised upstream data source feeding the agent) crafts input that looks like a normal request but contains injection syntax - quote breakouts, chained shell operators, encoded traversal sequences, or template expressions. This input ends up in the arguments the agent passes to a tool backend. The rule flags this as a suspected event. If, within the same process session, a command line is then spawned carrying the same injection shape, the rule upgrades the verdict to confirmed, meaning the payload didn't just sit in a tool call - it reached something that executes code.

## Why it matters

An attacker who can steer an agent's tool arguments may achieve command injection, SQL injection, or path traversal through the agent's own execution pipeline, potentially running arbitrary commands, reading unintended files, or corrupting a database using the agent as the delivery mechanism.

## What you can do

- Sanitize and validate all tool arguments before they reach shell, SQL, filesystem, or template execution contexts, treating agent-generated input the same as untrusted user input.
- Restrict which tools an agent can invoke with raw string arguments; prefer structured, parameterized calls over string concatenation.
- Review confirmed alerts first since they indicate a payload actually reached an execution context, not just a tool call.
- Expect noise from legitimate uses like writing detection rules, grep/sed patterns, or shell one-liners with command substitution, and tune review workflows to distinguish these from real attacks rather than blocking them outright.

## Known benign look-alikes

- Security engineers using an agent to author or edit detection rules, WAF signatures, or pentest payload fixtures - the literal payload strings appear in the tool arguments of the Write/Edit call. Expected; the rule only reports.
- Agents running grep/rg/sed where the SEARCH PATTERN argument itself contains shell metacharacters or SQL keywords.
- Legitimate shell one-liners passed to a bash-style tool that use command substitution with a network binary, e.g. VERSION=$(curl -s .../version). Mitigated by requiring a quote break-out for the chaining patterns, so plain 'make && ./deploy.sh' does not match.
- Database tooling issuing a genuine column-probing UNION query. Mitigated by requiring either a NULL/integer column-count probe or a catalog table (information_schema, sqlite_master, pg_catalog, mysql.user) in the same statement - ordinary application UNION SELECT does not match.
- Monorepo build tooling using deep relative paths. Mitigated by never matching bare '../../' - traversal requires URL/overlong encoding, a null byte, or a sensitive target (etc/passwd, .ssh, .aws, .env, proc/self, system32).
- Front-end templating work using {{ }} or ${ }. Mitigated by requiring an SSTI gadget accessor (__class__, __globals__, lipsum, jndi:, T(, getRuntime).
- When the spawning event has not yet been written to the event log, proc_instance() returns None and the rule reports with an explicit 'attribution degraded' marker and no kill chain.

## References

- https://genai.owasp.org/llmrisk/llm05-improper-output-handling/
- https://owasp.org/Top10/A03_2021-Injection/
- https://cwe.mitre.org/data/definitions/78.html
- https://cwe.mitre.org/data/definitions/89.html
- https://cwe.mitre.org/data/definitions/22.html
- https://cwe.mitre.org/data/definitions/1336.html

---
Source: https://www.netzilo.com/threats/tool-parameter-injection