Indirection injection is an attack technique that inserts an extra layer of lookup or routing so a system follows attacker-controlled references instead of the intended ones. In AI and software workflows, it can redirect tool calls, data fetches, or prompts through a misleading pointer, which can change behaviour or expose unintended resources.
How indirection injection works
Indirection injection exploits a system’s willingness to follow pointers, aliases, references, or routing metadata. Instead of sending a request directly to the intended target, the attacker supplies an extra lookup step that changes where the system reads, calls, or routes next.
This technique is dangerous because the dangerous action often looks legitimate at the first hop. The application may validate the initial input while the second hop, such as a referenced resource, callback, tool selector, or retrieval pointer, bypasses the original trust assumptions.
Why extra lookup layers create security exposure
The core weakness is not the pointer itself, but the trust placed in what the pointer resolves to. If the system treats indirection as a safe internal convenience, an attacker can steer execution toward unexpected data, privileged endpoints, or untrusted content.
That can turn ordinary workflow logic into a control bypass. In AI systems, for example, a prompt or tool reference may be redirected to a different resource than the one the operator intended; in software systems, a reference can resolve to internal objects, files, or services that were never meant to be reachable through that path.
When indirection is accepted from untrusted input, the security boundary moves from the original request to the resolver. That boundary is usually weaker, less visible, and harder to monitor.
Common patterns where it appears
Indirection injection can show up in pointer fields, redirect parameters, resource identifiers, configuration references, retrieval chains, or tool-routing metadata. The exact syntax varies, but the underlying pattern is the same: a first-level request is made to fetch or invoke something else.
It is especially risky when a workflow supports dynamic composition, because one component may assume another component already authenticated or vetted the target. That assumption is often false once attacker-controlled references enter the path.
For broader application-security context, organisations often compare this class of problem with the baseline issues tracked in the OWASP Top 10, even though indirection injection itself is a more specific workflow and routing abuse pattern.
Prevention and verification priorities
The safest design is to separate untrusted references from direct execution decisions. Systems should resolve pointers through allowlisted, canonicalised mappings rather than accepting arbitrary destinations, and they should validate both the original input and the resolved target before use.
Practitioners should also treat indirect lookups as a distinct trust boundary. That means reviewing where reference resolution happens, what authority it runs under, and whether the resolved object can change behaviour, access scope, or data exposure.
In AI and agentic workflows, the same principle applies to tool selection and retrieval chains: do not allow a user-controlled reference to determine the next action unless the system explicitly constrains the destination set and checks it at runtime.
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, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while OWASP ASVS and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V15 — Secure Coding and Architecture | Indirection injection exploits unsafe architectural trust in resolved references. |
| Recommendation — Design reference resolution so untrusted indirection cannot change execution targets. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Attacker-controlled routing can redirect calls into functions the caller should not invoke. |
| Recommendation — Authorize the resolved action, not just the initial request. | ||
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | In agentic systems, indirection can redirect tool invocation to an unintended target. |
| Recommendation — Constrain tool routing so indirect references cannot select unsafe tools. | ||
| NIST CSF 2.0 | PR.AA-05 — Least Privilege | Limiting what resolved targets can do reduces the blast radius of a bad reference. |
| Recommendation — Limit the privileges available to any indirectly resolved target. | ||
| MITRE ATT&CK | T1204 — User Execution | The technique relies on influencing a system to follow attacker-supplied references or actions. |
| Recommendation — Hunt for suspicious reference-following activity in execution telemetry. | ||