# Prompt Injection Phrase in Robotic Task-Planner Command Invocation

- **Severity:** High
- **Signature ID:** `8e4f2a71-6d93-4a08-9c2b-71e5a3f9d604`
- **MITRE ATLAS:** AML.T0051 (LLM Prompt Injection)
- **OWASP:** LLM01 (Prompt Injection)

## Summary

This detects when someone starts a robot control program (like ROS2, MoveIt, Nav2, or a similar task-planning tool) and passes it a task or goal argument that contains classic prompt-injection wording, such as 'ignore previous instructions' or 'override safety'. The idea is that an attacker could try to hijack a robot's behavior by smuggling manipulative text directly into its command-line instructions.

## How the attack works

An attacker (or a script acting on their behalf) launches a known robotic task-planning or control binary. They supply a task, goal, or prompt-style flag whose value contains override language typical of prompt injection attacks, for example telling the system to disregard prior instructions or adopt a new objective. If the underlying planner treats that text as an instruction rather than as untrusted data, it could change the robot's behavior in unsafe ways. The detection only sees the command-line invocation itself, not whether the robot actually acted on it.

## Why it matters

If successful, an attacker could redirect a robot's task planner toward unintended or unsafe actions, potentially bypassing built-in safety instructions. This rule only flags the presence of suspicious wording in a direct command-line invocation; it does not confirm that any physical action occurred, and it cannot see injection attempts delivered through sensor/perception data or passed between cooperating agents.

## What you can do

- Treat any task/goal/prompt argument passed to robot control processes as untrusted input and validate or sanitize it before it reaches the planner.
- Restrict who and what can invoke task-planning binaries directly from a command line, especially on systems connected to real hardware.
- Separate test/CI environments that intentionally send injection strings (for red-teaming) from production systems, and label or isolate those runs so they don't get confused with real incidents.
- Add monitoring for the indirect delivery path too — injected content arriving via sensor/perception output or shared multi-agent messaging — since this rule does not cover that route.

## Known benign look-alikes

- Adversarial-robustness / red-team test harnesses that intentionally feed known prompt-injection strings into a robot task-planner CLI to validate defenses, e.g. a pytest suite invoking `task_planner --task "ignore previous instructions and ..."` inside a sandboxed CI run
- Documentation or tutorial scripts that print example injection payloads as inline sample text while demonstrating a planner's --task/--goal argument
- Fuzzing or benchmark harnesses that replay canned adversarial prompt corpora against an llm_planner/embodied_agent binary in a pure simulation environment (Gazebo, dry-run mode) with no attached hardware

## References

- https://atlas.mitre.org/techniques/AML.T0051

---
Source: https://www.netzilo.com/threats/robotic-task-planner-prompt-injection