Pre-model execution exposure

What Pre-Model Execution Exposure Means in an Agentic System

Pre-model execution exposure sits in the control path before the model itself produces output. The danger is not the model’s answer, but the opportunity for untrusted data to influence what the agent, orchestrator, or tool layer decides to fetch, route, remember, or invoke. In practice, that makes the pre-run layer part of the attack surface, not just plumbing.

This is especially important where the system treats retrieved content, conversation state, workflow instructions, or tool metadata as if they were trustworthy. A malicious prompt fragment, poisoned memory entry, or manipulated routing signal can shape the next action long before any model reasoning is visible to the user.

Where the Exposure Appears

The exposure most often emerges at ingestion and control points: retrieval pipelines that pull in external text, memory stores that persist prior context, routing layers that choose which tool or agent runs next, and orchestration logic that turns instructions into execution. If those layers do not separate trusted policy from untrusted input, attacker-controlled content can quietly influence downstream behaviour.

OWASP LLM Top 10 LLM03 Supply Chain Guide is a useful companion for understanding how model-adjacent supply chain trust can be abused before execution. The same pre-run pattern can also appear when teams overestimate the safety of internal memory or orchestration state.

Why It Is Dangerous

The main risk is that the system may appear to be acting normally while its inputs have already been shaped by an attacker. That can redirect tool calls, cause unsafe retrieval, bias agent planning, or smuggle policy-breaking instructions into later steps. In agentic systems, this can be enough to create data exposure, unauthorized actions, or trust boundary collapse without the model itself “doing” the malicious act in a visible way.

Because the harmful influence happens upstream, traditional model output filtering may miss it. The security problem is therefore broader than prompt injection alone: it includes poisoned context, malicious retrieval content, and untrusted orchestration signals that are treated as if they were part of the agent’s operating state.

For teams measuring exposure across attack paths, Exposure Management Maturity Model is a practical lens for thinking about how far visibility extends from discovery to validation and remediation.

How Teams Reduce Pre-Execution Exposure

Defensive design starts by treating pre-model inputs as hostile until proven otherwise. Retrieval results should be isolated from executable instructions, tool-routing decisions should be policy-governed rather than content-governed, and memory should be validated, scoped, and sanitised before reuse. High-value actions should require stronger checks than ordinary conversational flow.

Teams should also verify whether their orchestration layer can distinguish source trust, instruction trust, and action trust. If those are blended together, a single poisoned input can influence multiple downstream decisions. The safest designs minimise implicit trust and make every transition from content to action explicit.

Detection and Review After Exposure

Detection should focus on abnormal control-flow, not just malicious model text. Suspicious indicators include unexpected tool selection, unusual retrieval dependencies, altered agent routing, inconsistent memory reuse, and actions that do not align with the original user intent. Post-incident review should reconstruct the full pre-run path, not only the final model response.

If a compromise is suspected, review the inputs that influenced retrieval, memory, orchestration, and tool invocation, then determine whether those inputs were able to shape action before the model produced output. That is the core diagnostic question for this term: where did the trust boundary fail, and what was accepted too early?

Risk and Threat Considerations

Pre-model execution exposure creates a narrow but high-impact attack window, because the system may commit to a route, tool, or memory state before any human-visible output exists. That makes it attractive for adversaries who want to steer agent behaviour, trigger unsafe actions, or hide malicious influence inside apparently ordinary inputs.

Failure mechanism: Untrusted retrieval content, memory entries, or orchestration signals are treated as actionable context, allowing attacker-controlled material to shape later decisions before the model runs.

Impact: The result can be misrouting, unsafe tool invocation, policy bypass, data exposure, or persistent poisoning of later agent steps, even when the final model output looks benign.

Practitioner Guidance

What to watch for: Give special attention to any design where content and control are mixed in the same pre-run channel. The most common failure is assuming that “pre-model” means “safe to trust”; in reality, it is often the earliest and most influenceable point in the chain.

Practitioner takeaway: The right defence is not to harden the model alone, but to harden the entire pre-execution path that decides what the model will be allowed to see, remember, and do.

Related resources from NHI Mgmt Group

• Execution (MITRE ATT&CK Tactic)
• Why do open AI model ecosystems increase the risk of secrets exposure and malicious code execution?
• How should security teams reduce pre-task execution risk in AI agent harnesses before the model starts?
• Pre-model Exposure Control