What breaks when AI assistant skills can run code before the model sees the prompt?

The trust boundary breaks because the most privileged actions happen outside the model’s awareness. If a harness can execute shell commands, read files, or call hooks before the LLM reasons, then safety checks inside the model arrive after the data may already be exposed. Governance has to move left into preprocessing and repository review.

Why This Matters for Security Teams

When assistant skills can run code before the model sees the prompt, the real control point shifts away from the LLM and into the skill harness, repository, and execution environment. That means a prompt-layer policy can be technically correct and still be too late. This is why governance for AI assistants has to account for code execution order, not just model outputs. NIST’s control families in NIST SP 800-53 Rev 5 Security and Privacy Controls remain relevant, but only if they are applied to the pre-prompt path as well as the model response path.

Practitioners often assume the model is the decision-maker, yet in these architectures the harness may already have touched files, secrets, or internal APIs before any safety filter runs. That creates an exposure path that looks more like unsafe automation than unsafe chat. NHIMG’s analysis of DeepSeek breach shows how quickly sensitive material can become part of the attack surface once exposed in the surrounding system. In practice, many security teams discover this only after a skill has already executed with more privilege than the model ever needed, rather than through intentional design review.

How It Works in Practice

The break occurs because the agent stack is no longer a single reasoning event. A skill runner may inspect repositories, expand environment variables, invoke shell commands, or call internal hooks before the LLM sees the request. If any of those actions depend on user-controlled input, the model cannot meaningfully “refuse” in time because the side effect has already happened. For this reason, current guidance suggests treating the pre-prompt layer as an execution boundary, not a convenience layer.

That means security design has to move left into the harness. The practical sequence is: validate the request, constrain the tool, check policy, then execute. For systems that need stronger assurance, the emerging pattern is intent-based authorization with runtime policy evaluation rather than static allowlists alone. This aligns with the broader direction described in OWASP and zero-trust guidance, where access is granted only for the specific task and context. In agentic pipelines, that usually means short-lived credentials, workload identity, and per-call policy decisions instead of inherited session trust.

• Use workload identity for the skill runner so the system proves what it is, not just what token it possesses.
• Issue JIT secrets or ephemeral tokens only for the exact task and revoke them on completion.
• Block file reads, shell access, and outbound calls unless the policy engine approves the specific action in context.
• Log the pre-prompt path separately from model logs so investigators can reconstruct what happened before inference.

That operating model is consistent with the agentic risk patterns discussed in LLMjacking: How Attackers Hijack AI Using Compromised NHIs and with NIST SP 800-53 Rev 5 Security and Privacy Controls when those controls are extended to execution-time protections. These controls tend to break down when skills share a broad runtime, because one compromised hook can inherit the same filesystem, network, and secret access as every other tool.

Common Variations and Edge Cases

Tighter pre-execution control often increases latency and engineering overhead, requiring organisations to balance safety against developer velocity and tool usefulness. That tradeoff becomes sharper when skills are meant to be flexible, because every added permission check can feel like friction to product teams. Best practice is evolving, not settled, for how much logic should live in the model, the harness, or an external policy engine.

One edge case is “read-only” skills that still expose secrets through logs, metadata, or prompt assembly. Another is multi-step assistants that chain tools: even if each tool is individually low risk, the combination can create privilege escalation or lateral movement. The safest pattern is to assume the model may reason after the first side effect, not before it. That is why many teams now separate sandboxed tool execution from the LLM, use short TTL credentials, and restrict repository access to the minimum set needed for the task. When the runtime mixes user input, shared tokens, and broad filesystem access, the guidance breaks down quickly because one pre-prompt action can contaminate the entire session.

Related resources from NHI Mgmt Group

• What breaks when an AI service loads model code before authentication?
• What breaks when a web API allows code execution before authentication?
• What does AI model abuse reveal about the current NHI threat surface?
• Why do attackers often check model availability before trying to generate content?