Indirect execution happens when a process cannot run code directly but can still cause another trusted component to run it on its behalf. That pattern is central to sandbox bypasses, because the compromise often comes from shaping inputs that host tools later execute automatically.
Expanded Definition
Indirect execution describes a control-flow pattern where an untrusted actor cannot execute code in a target environment directly, but can influence a trusted interpreter, host application, or automation layer to do it. In security analysis, the distinction matters because the privileged component is the one performing the action, even though the triggering input came from elsewhere. That makes indirect execution especially relevant in sandbox escapes, command injection chains, document macro abuse, browser exploitation, and agentic AI workflows that call tools on a user’s behalf.
In practice, the term is broader than classic code injection. It can include file parsing behavior, template rendering, formula evaluation, script engines, task schedulers, and orchestration pipelines that treat attacker-controlled data as executable instructions. This is why NHI Management Group treats indirect execution as a design-pattern issue as much as a vulnerability class. Where organisations govern AI systems, the same pattern can appear when an agent turns a prompt, attachment, or retrieved artifact into an action without adequate validation. For a governance-oriented baseline, NIST Cybersecurity Framework 2.0 helps frame the need for controlled execution paths and monitored trust boundaries.
The most common misapplication is assuming a filter or sandbox is sufficient protection, which occurs when trusted components still auto-process attacker-shaped inputs.
Examples and Use Cases
Implementing protections against indirect execution rigorously often introduces workflow friction, requiring organisations to weigh automation speed against stricter inspection and approval steps.
- A document viewer loads a crafted file that causes an embedded parser or script engine to execute instructions as part of normal rendering.
- A web application passes unsanitised user input into a shell command, allowing the operating system to run attacker-influenced actions through a trusted service.
- An AI agent receives a prompt that instructs it to open a file, query a tool, or send data onward, effectively converting text into delegated execution.
- A build pipeline consumes a repository artifact that triggers a helper utility or post-processing step, turning a supply-chain input into code execution.
- A browser or browser extension interprets a payload through a plugin, macro, or automation hook, creating execution through the host rather than the attacker.
These patterns are often discussed in terms of sandbox bypass, but the useful lens is trust delegation: who is actually allowed to interpret the instruction. Guidance from NIST Cybersecurity Framework 2.0 is relevant here because it emphasises protective controls around application behavior, monitoring, and response. In AI-driven environments, OWASP Top 10 for LLM Applications captures adjacent risks where untrusted inputs are turned into tool use or side effects.
Why It Matters for Security Teams
Security teams need to understand indirect execution because the visible source of the action is often not the real security failure. The failure is the trust boundary being crossed by a component that should have treated the input as data, not instructions. That distinction affects secure coding, sandbox design, content filtering, email and document handling, agent permissions, and incident response. If teams only look for direct malware execution, they can miss the upstream trigger that caused a trusted service to perform the harmful action.
This matters even more in identity-heavy environments, where a process may inherit the permissions of a user, service account, or NHI and then execute on their behalf. When indirect execution involves agents, the risk is not just code execution but unauthorised action within a broader operating context, including secrets access, API calls, and workflow manipulation. NHI Management Group recommends treating execution authority as a first-class control point rather than assuming all automation is equally safe. Practitioners typically encounter the operational impact only after a sandbox escape, malicious attachment, or agent misuse, at which point indirect execution becomes the explanation for how trusted access was turned against the organisation.
For defensive maturity, CISA Secure by Design reinforces the need to reduce dangerous default behaviors, while ISO/IEC 27001 supports governance over software and access pathways that can be abused for delegated execution.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access limits which trusted component can be induced to execute. |
| OWASP Agentic AI Top 10 | Agentic AI guidance covers tool-use abuse where prompts trigger indirect actions. | |
| NIST AI RMF | AI RMF addresses governance and oversight for risky model-driven actions. | |
| CSA MAESTRO | MAESTRO maps agentic workflows and execution boundaries relevant to this pattern. |
Restrict execution paths so only approved services can act on untrusted inputs.
Related resources from NHI Mgmt Group
- How should security teams reduce indirect prompt injection risk in AI systems?
- When does indirect prompt injection become a business risk rather than a technical curiosity?
- When should organisations sandbox code execution in agentic platforms?
- What is the difference between prompt injection and LLM remote code execution?
