Injection threats are attacks that place malicious instructions or data into a system so it behaves in an unsafe way. In AI and software contexts, this includes prompt injection, code injection, SQL injection, and command injection, where untrusted input alters logic, exposes data, or triggers unauthorized actions across identity and application controls.
What Injection Threats Are
Injection threats arise when untrusted input is interpreted as instructions rather than data. The danger is not just malformed input, but a trusted system boundary collapsing so external text, commands, or queries can change execution, access data, or trigger actions.
Why Injection Threats Are Dangerous
Injection is dangerous because it turns ordinary input channels into control channels. In software, that can mean SQL, command, template, or code execution. In AI systems, prompt injection can steer model behaviour, override intended constraints, or cause unsafe tool use and data disclosure.
What makes the class especially persistent is that it often exploits design assumptions, not just bugs. A system may validate inputs at one layer, yet still expose a downstream parser, runtime, or agent tool interface that treats the same content as executable instructions.
Where Injection Appears Across Systems
Classic injection includes SQL injection and command injection, where attacker-controlled strings alter database logic or shell execution. Modern AI systems add prompt injection, where adversarial content can influence model responses, retrieval paths, or tool selection when the system fails to separate instructions from untrusted content.
Injection also appears in templating engines, deserialisation flows, email or document parsers, and API integrations. The common pattern is the same: a parser, interpreter, or orchestrator trusts input that should have remained inert.
What Defenders Need to Protect
Defence focuses on reducing the ways untrusted content can become executable. That usually means strict input handling, context separation, allowlisting, parameterisation, output encoding, and limiting the authority of the component that processes the input.
For AI and agentic systems, the same principle applies to prompts, retrieved content, and tool outputs. If an assistant can read untrusted text and then act on it with powerful permissions, injection becomes an integrity and privilege problem as much as a parsing problem.
Risk and Threat Considerations
Injection threats matter because they can produce direct compromise, silent data exposure, or unintended actions without any obvious sign of a login failure or malware implant. They are especially risky when the injected content reaches an application, database, or agent with elevated authority.
Failure mechanism: The system treats attacker-controlled text as executable or decision-shaping input, so the malicious payload is evaluated inside a trusted execution path rather than being isolated as data.
Impact: Attackers can alter logic, read restricted data, execute commands, hijack workflows, or cause AI systems to reveal information or perform unsafe actions across application and identity controls.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V1 — Encoding and Sanitization | Injection threats rely on unsafe interpretation of untrusted input. |
| V4 — API and Web Service | API request handling is a common injection path for commands, queries, and payloads. | |
| V8 — Authorization | Injection often converts input manipulation into unintended actions beyond the caller's authority. | |
| Recommendation — Apply V1 controls to encode, sanitise, and constrain all untrusted input before interpretation. Apply V4 controls to validate and constrain API inputs before they reach executors or back-end queries. Apply V8 controls to ensure injected input cannot trigger actions outside the user's authorised scope. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Misconfigured APIs and runtimes often make injection paths easier to exploit. |
| Recommendation — Harden API configurations so untrusted input cannot reach dangerous interpreters or debug paths. | ||
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Command injection is a direct example of attacker-controlled input reaching a command interpreter. |
| T1190 — Exploit Public-Facing Application | Many injection exploits target exposed applications to gain initial access or execute logic remotely. | |
| Recommendation — Map command-injection indicators to T1059 and hunt for unexpected interpreter execution. Correlate public-facing injection attempts with T1190 and review exposed services for exploitable input handling. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | This control directly addresses validating untrusted input before processing. |
| Recommendation — Implement SI-10 to validate and reject malicious or malformed input before it is processed. | ||
Practitioner Guidance
Why practitioners should care: Injection is rarely one control failure. It is usually a boundary failure between untrusted content and a trusted interpreter, which means the fix must protect the entire data path, not just one input field.
What to watch for: Treat any feature that lets external content influence queries, commands, prompts, or tool calls as a high-risk boundary. The most dangerous cases are those where the affected component can also access credentials, sessions, or production data.
Practitioner takeaway: The safest design assumption is that all external input is hostile until it has been constrained, separated from instructions, and prevented from inheriting privileged execution context.