Security teams should treat the agent harness as part of the attack surface, not just the model. The safest approach is to separate workspace trust from execution, require explicit trust for project-local configuration, sanitize environment variables before any child process starts, and avoid shell-based command construction for startup paths. If attacker-controlled files can influence bootstrapping, prompt defenses arrive too late.
Why Pre-task Execution Risk Starts Before the Model Runs
Pre-task execution risk is the gap between a user launching an agent and the point where the model has had a chance to reason about the request. In agent harnesses, that gap often includes workspace discovery, project-local configuration loading, environment inheritance, and startup command construction. If attacker-controlled files or variables can shape those steps, the harness can be manipulated before any prompt-level safety check becomes relevant.
That is why security teams should treat the harness as part of the attack surface. The model may be the visible interface, but the startup path is where trust is often decided, and in practice the first failure is usually an unsafe default rather than an obvious exploit attempt.
How to Reduce Risk in the Harness Path
The safest design separates workspace trust from execution trust. A harness should not assume that because a repository is opened, its local configuration, scripts, or environment are safe to consume. Explicit trust should be required for project-local startup inputs, especially when the harness auto-loads configuration files, shell fragments, or dependency hooks.
Before any child process starts, sanitize the environment so the agent inherits only what it actually needs. That means removing untrusted variables, narrowing path resolution, and avoiding ambient secrets or tokens unless they are intentionally scoped for that run. If a startup step must pass data to a child process, prefer structured argument passing over shell-based command construction, because shell expansion turns many small input mistakes into command execution risk.
- Keep project metadata and execution permissions separate.
- Load only the minimum environment required for the task.
- Use direct process invocation rather than string-built shell commands.
- Treat local files, hooks, and bootstrap scripts as untrusted until explicitly approved.
For broader AI agent risk modeling, the OWASP Agentic AI Top 10 and the OWASP Agentic AI Top 10 are useful references for where tool use, permissions, and execution boundaries fail. These controls tend to break down when the harness is optimized for developer convenience and silently trusts repository state by default.
Common Variations and Edge Cases
Tighter startup controls often add friction, so teams need to balance convenience against blast-radius reduction. That tradeoff becomes more visible in fast-moving developer environments, where agents are expected to launch inside arbitrary repositories and inherit existing local state. The answer is usually not to block automation entirely, but to define which inputs are allowed to affect bootstrap decisions.
There are a few cases that need special handling. First, when a harness must read project files to determine task context, it should read them as data, not as instructions or executable configuration. Second, if a workflow relies on environment variables for legitimate integration, those variables should be allowlisted and reset on a per-task basis. Third, if an agent needs startup hooks, those hooks should be signed, versioned, or otherwise controlled outside the workspace it is about to inspect.
Security teams also need to watch for the common assumption that prompt injection is the main risk. In startup paths, the earlier failure is often trust inversion: the system trusts the repository before it knows whether the repository is trustworthy. That distinction matters because the model cannot defend against bootstrap-time compromise after the process has already started.
Risk and Threat Considerations
Pre-task execution risk creates a supply-side attack path into agent harnesses, where malicious workspace contents, environment variables, or startup arguments can alter behavior before policy enforcement at the model layer. The threat is strongest when harnesses auto-discover config, inherit ambient credentials, or build commands through the shell.
Failure mechanism: An attacker plants or influences files that the harness reads during bootstrap, causing unsafe code paths, poisoned environment state, or unexpected child-process execution. Because this happens before the model sees the task, downstream prompt defenses and content filters arrive too late to stop the initial abuse.
Impact: The result can be unauthorized command execution, secret exposure, altered tool behavior, or a compromised execution context that persists for the rest of the agent run.
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 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 — Agentic Input and Context Integrity | Startup state and workspace inputs can poison agent execution before task handling. |
| A4 — Tool and Execution Boundary Control | Harness command construction and child-process launch are the core execution boundary. | |
| A6 — Agent Permissions and Privilege Control | Pre-task risk increases when the harness inherits broad ambient privileges or secrets. | |
| Recommendation — Separate trusted bootstrap inputs from workspace-controlled data before launching the agent. Avoid shell-built startup commands and invoke child processes with explicit arguments. Minimise inherited privileges and scope startup environment variables to the task. | ||
| NIST CSF 2.0 | PR.AC — Access Control | Reducing startup trust and inherited access is an access-control problem at process launch. |
| Recommendation — Restrict what the harness can inherit or execute before the model begins work. | ||
| CIS Controls v8 | 5.1 — Establish and Maintain an Inventory of Enterprise Assets | Safe harness startup depends on knowing which local assets and configs can influence execution. |
| 8.2 — Audit Log Management | Pre-task compromise is easier to detect when bootstrap and process creation are logged. | |
| Recommendation — Inventory the files, hooks, and startup paths that can affect agent execution. Log startup decisions, environment loading, and child-process launches for review. | ||
Practitioner Guidance
What to prioritise: Put the first control boundary at process start, not at prompt review. If the harness can launch with attacker-influenced state, treat that as a higher-risk condition than ordinary prompt manipulation.
Decision rule: If a bootstrap input can change command execution, file loading, or inherited credentials, move it behind explicit trust or remove it from startup entirely. If it is only needed later in the workflow, delay it until the harness is already in a controlled state.
What good looks like: The harness starts from a minimal, known environment, rejects unsafe project-local execution defaults, and only imports workspace-specific behavior after the trust decision is made. The key test is whether a malicious repository can still shape startup without being explicitly approved.
Practitioner takeaway: The most effective pre-task control is to make startup deterministic and boring, because once the harness has accepted untrusted execution state, the model is already defending too late.
Related resources from NHI Mgmt Group
- How should security teams reduce the risk of remote code execution in AI agent toolchains that rely on MCP?
- How should security teams reduce the risk of AI jailbreaks in model-enabled workflows?
- How should security teams reduce the risk of public AI workflow endpoints being exploited for remote code execution?
- How should security teams reduce the risk of stolen AI coding agent credentials on macOS endpoints?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 14, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
