Pre-LLM Execution

The processing that happens before a language model receives the final prompt. In this architecture, the harness can expand variables, run commands, and prepare tool context before the AI is aware of any of it, which creates a hidden security boundary that must be governed separately.

Expanded Definition

Pre-LLM execution refers to the harness-side work completed before a model receives its final prompt: variable expansion, command execution, tool-context assembly, policy checks, and request shaping. In agentic systems, this layer is not just plumbing. It is a security boundary that can change what the model is allowed to see and do without the model itself being aware.

Definitions vary across vendors because some stacks treat this as orchestration, while others treat it as prompt preprocessing or agent bootstrap. NHI Management Group treats it as a distinct control surface because secrets, environment data, and execution intent may be introduced here before any model-level guardrail can apply. That makes it relevant to OWASP Agentic AI Top 10 guidance and to governance models such as the NIST AI Risk Management Framework.

The most common misapplication is assuming that a prompt filter alone governs risk, which occurs when sensitive variables are expanded or commands are run before the prompt is evaluated.

Examples and Use Cases

Implementing pre-LLM execution rigorously often introduces latency and architectural complexity, requiring organisations to weigh safer tool preparation against faster agent response times.

• An agent harness expands a customer ID into a database query before the model sees the task, so the execution layer must validate whether that query can touch restricted records.
• A workflow injects API keys into a tool wrapper to let the model call an external service, which means secret handling must be governed as a pre-prompt event, not as a model prompt issue. This is consistent with findings in the AI Agents: The New Attack Surface report.
• An automation agent runs shell commands to collect system context, then sends the output to the model for reasoning. The command path needs separate approval and logging, aligned to the NIST AI 600-1 Generative AI Profile.
• A security team reviews the OWASP NHI Top 10 alongside the Analysis of Claude Code Security to identify where execution prep can leak credentials into agent context.
• Developers precompute tool outputs for speed, but the harness must still confirm provenance and freshness before the model consumes those results.

Why It Matters in NHI Security

Pre-LLM execution matters because hidden execution paths can bypass the controls teams assume are protecting the model. If a harness expands secrets, launches commands, or assembles privileged context unsafely, the model becomes the last place to look for the problem, not the first. That is why NHI governance has to cover the orchestration layer, not only the agent’s visible prompt or output.

NHIMG research shows how quickly hidden exposure turns into active abuse: in the LLMjacking research, publicly exposed AWS credentials were accessed by attackers in an average of 17 minutes. The same risk pattern applies when pre-LLM execution stages expose tokens, keys, or internal context before the model is invoked. The result is often silent misuse, incomplete audit trails, and security teams who cannot prove what the agent actually touched. The AI Agents: The New Attack Surface report also found that only 52% of companies can track and audit the data their AI agents access, leaving 48% with a compliance blind spot.

Organisations typically encounter the operational impact only after a secret leak, unauthorised action, or forensic gap, at which point pre-LLM execution becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What is the difference between prompt injection and LLM remote code execution?
• Pre-execution Authorization
• LLM Remote Code Execution
• Pre-authentication execution surface