Code or commands that run before a user has approved a workspace, repository, or project context. In agentic tools, this creates a hidden execution channel because safety prompts arrive too late to block malicious configuration or helper logic.
Expanded Definition
Pre-trust execution describes code paths that activate before a person has explicitly approved a workspace, repository, or project context. In agentic tools, that timing matters because the system may already have parsed configuration, loaded helper logic, or started actions that shape what the user later sees. The risk is not limited to traditional malware; it also includes benign-looking bootstrap scripts, project templates, and automation hooks that can quietly establish control before any trust decision is made.
This concept is especially relevant where an AI agent, developer tool, or build environment can execute instructions during initial setup. It differs from ordinary post-approval automation because the execution occurs before the user’s decision point, which weakens any prompt-based safeguard. For a governance lens, the key question is whether the tool is capable of running unreviewed code prior to trust establishment, not merely whether it asks for confirmation later. NIST Cybersecurity Framework 2.0 is useful here because it emphasizes governance, access control, and secure implementation practices that should constrain early execution paths through NIST Cybersecurity Framework 2.0.
The most common misapplication is treating a later approval prompt as if it retroactively neutralises code that already ran during initialization, which occurs when teams assume the prompt is the control boundary rather than the actual execution point.
Examples and Use Cases
Implementing safeguards against pre-trust execution rigorously often introduces setup friction, requiring organisations to weigh faster onboarding against stronger control over what can run before trust is granted.
- A repository template launches a bootstrap script that fetches dependencies and edits local files before the user reviews the project, creating an execution path that precedes approval.
- An agentic coding assistant reads project instructions from hidden files and executes helper logic during import, even though the workspace has not yet been accepted by the user.
- A local development environment auto-runs initialization hooks that load secrets, tokens, or certificates from the filesystem before the operator confirms the repository should be trusted.
- A plugin system evaluates configuration on startup and triggers outbound network calls before the user has validated the source of the extension or workspace.
- A security team reviews agent startup behaviour against baseline platform guidance such as the OWASP Top 10 for Large Language Model Applications, because hidden execution paths can function as prompt-injection enablers in agentic workflows.
These scenarios often arise in development tooling, code assistants, and AI-enabled orchestration platforms where convenience features are designed to reduce clicks but can also reduce the time available for human judgement. The operational pattern is the same even when the payload differs: code runs first, trust is asked for later. That sequencing is what makes the term security-relevant.
Why It Matters for Security Teams
Security teams care about pre-trust execution because it can invalidate assumptions about sandboxing, review workflows, and human approval. If code is allowed to run before a workspace is trusted, then policy enforcement, prompt-based warnings, and manual inspection all happen after the initial exposure. That creates a blind spot for supply-chain abuse, malicious project scaffolding, and agentic tool compromise.
The identity connection is strong in environments where non-human identities, tokens, or developer credentials are made available during startup. A pre-trust path can expose secrets, mint sessions, or establish persistence before IAM or PAM controls are fully applied. That is why secure defaults, least privilege, and explicit trust boundaries matter in agentic systems as much as they do in traditional software delivery. The NIST Secure Software Development Framework is also relevant when organisations assess whether build and runtime steps are separated well enough to prevent early execution risk, and the broader control logic aligns with OWASP guidance for LLM-based systems.
Organisations typically encounter the impact only after a workspace has already been opened and a harmful helper has run, at which point pre-trust execution becomes operationally unavoidable to contain.
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 OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01 | Governance and access controls help constrain actions before trust is established. |
| OWASP Agentic AI Top 10 | Agentic systems can execute tools before approval, matching this hidden-execution risk. | |
| OWASP Non-Human Identity Top 10 | Pre-trust execution can expose secrets and NHI credentials during bootstrap flows. |
Define trust boundaries so code cannot execute before access decisions are enforced.
