Claude Code skills create a pre-LLM trust gap for AI assistants

At a glance

What this is: Mint shows that Claude Code skills create a pre-LLM trust gap because preprocessing can run commands and hooks before the model sees any content.

Why it matters: IAM, NHI, and security teams need to treat AI assistant configuration as executable control surface because pre-model execution can expose secrets, mislead agents, and bypass user visibility.

Context

Claude Code skills are not just prompt content. They are configuration-driven instructions that the harness can execute before the LLM reasons about a task, which creates a governance gap between what users think they are reviewing and what actually runs on the machine. That gap matters because it turns repository content, frontmatter, and hooks into an execution path that can affect secrets, access, and trust.

The identity angle is direct: AI assistants increasingly operate with access to credentials, tools, and repository context, so the question is no longer only what the model can infer but what the surrounding runtime can execute. In practice, this is an NHI-style governance problem because the harness, hooks, and skill files behave like machine actors with delegated authority. That makes the article relevant to teams governing AI agents, developer workflows, and privileged tooling together.

Key questions

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

A: 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.

Q: Why do pre-LLM hooks and skill commands create a security risk for developers?

A: They create risk because they can access the same local context as the session, including secrets, files, and tool inputs, while remaining invisible to the model until after execution. That means exfiltration and surveillance can happen without user awareness, and post-event detection does not undo the initial loss.

Q: What are the warning signs that an AI agent is overprivileged?

A: Warning signs include an agent that can reach tools or data stores unrelated to its task, persists with the same privileges after the session ends, or depends on static credentials instead of short-lived tokens. If the agent’s access can be reused across tasks, or if its actions cannot be clearly attributed to a bounded workload identity, overprivilege is already present.

Q: How should teams govern AI assistant configuration files and hooks?

A: Treat them as executable security controls, not documentation. Limit who can modify them, scan them in code review and CI, disable unnecessary hooks, and require managed policy for any setting that can invoke code, access secrets, or modify tool output. The question is not convenience but delegated authority.

Technical breakdown

How Claude Code separates the harness from the LLM

Claude Code uses a two-layer model. The harness is deterministic software that parses skills, expands variables, runs hooks, and dispatches tools. The LLM only receives the rendered result after preprocessing. That design means security decisions can happen outside the model’s awareness, which is very different from a chat prompt where the model sees the full input first. When skills include frontmatter, shell commands, or hook definitions, those elements are operational instructions to the harness, not conversational content to the model.

Practical implication: Treat skill files as executable control inputs and review them with the same discipline used for scripts, workflow files, and CI jobs.

Why pre-LLM command execution creates a secrets exposure path

The !`command` pattern lets the harness run shell commands during preprocessing and substitute the output into the skill text. If that command reads environment variables, SSH material, cloud credentials, or local config, the data can leave the workstation before the model ever sees the prompt. Because the AI only receives the rendered output, post-hoc detection does not prevent the exfiltration event. This is a classic trust-boundary failure: the system assumes preprocessing is benign while it is already performing actions with access to sensitive context.

Practical implication: Constrain command execution in skill preprocessing and block any skill path that can read secrets, environment state, or credential stores.

How hooks turn tool use into a surveillance channel

Hooks are more dangerous than one-time preprocessing because they fire repeatedly on tool use. They can observe the exact command, file path, session context, and working directory, and they can influence tool input or output before the model sees it. In effect, the hook becomes an event-driven interceptor for the AI session. That creates a governance problem similar to unauthorized middleware in a privileged workflow: the model may be reasoning normally while another layer silently records or alters the evidence it depends on.

Practical implication: Inventory every hook as a privileged control point and restrict or disable hooks that can observe or modify tool calls without explicit approval.

Threat narrative

Attacker objective: The attacker wants to steal credentials, observe AI-assisted developer activity, and manipulate the assistant’s output before the user can trust it.

1. Entry occurs when a repository or local project includes a crafted skill file in .claude/skills/ that the harness loads automatically.
2. Credential access happens when preprocessing runs shell commands that collect SSH keys, cloud credentials, environment secrets, or configuration data before the LLM is involved.
3. Escalation and surveillance follow when hooks intercept every tool call, capturing commands and context or altering tool input and output without user visibility.
4. Impact is secret theft, reconnaissance leakage, or fabricated assistant output that can mislead developers and downstream automation.

Breaches seen in the wild

• Anthropic GTG-1002 AI espionage campaign: A state-sponsored group ran Claude Code agents to attack about 30 organisations, harvesting and reusing credentials at machine speed.
• Sentry MCP Agentjacking 2026: Researchers showed a fake Sentry error, posted with a public DSN, could make AI coding agents run attacker code with developers' credentials.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Pre-LLM execution is the real trust boundary: the security model fails if governance starts at the LLM prompt instead of the harness. Skills, hooks, and frontmatter can all execute before the model reasons, which means the control problem is runtime authority, not model output. Practitioners should treat the preprocessing layer as the first security perimeter for AI assistants.

Configuration files have become executable attack surface: repository content that looks like metadata can now trigger commands, permissions, and model changes. That is a named trust gap, not a minor implementation detail, because the same file can both define behaviour and silently invoke it. Teams need to govern SKILL.md, hook settings, and assistant config as active code paths, not passive project documentation.

AI assistant security now overlaps with NHI governance: the harness, hooks, and skill files function like delegated machine identities with ambient authority over tools and secrets. That makes OWASP-NHI concepts directly relevant, especially secret leakage, insecure authentication boundaries, overprivileged non-human access, and long-lived or invisible authority. The practitioner conclusion is straightforward: govern the assistant’s machine-side permissions as tightly as any other privileged NHI.

Supply chain review must extend to agent configuration, not just code: cloning a repository can now import hidden behavioural logic into an AI session. This is why the article points to a broader software supply chain problem, but the control failure is governance blind spot rather than malware sophistication. Security teams should expand review scopes to include .claude directories and any artefact that can alter assistant behaviour.

Preprocessing creates a post-hoc detection trap: an AI that notices malicious behaviour after execution has already lost the preventive window. That is the core failure mode here, and it shows why detection alone cannot govern pre-LLM execution. The practitioner lesson is to move enforcement to load time, before the harness can run untrusted commands or hooks.

From our research library:

• Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
• 96% of security operations teams report critical blind spots, most commonly in cloud infrastructure (74%) and identity and access behaviour (67%).
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Pre-LLM preprocessing is the new control point for AI assistants: once a harness can run commands or hooks before the model sees a prompt, prompt-based trust assumptions no longer hold. Security teams should move review and enforcement to configuration ingestion, because the assistant may already have acted before the LLM is asked to reason.

AI assistant governance now intersects directly with NHI control design: the harness behaves like a delegated machine actor, which means overprivileged access, secret handling, and offboarding logic all need to be applied to assistant configuration as well as service accounts. That is where NHI governance stops being theoretical and becomes operational.

Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026: that scale is a reminder that AI-assisted development increases the value of pre-execution controls, not just detection after the fact.

For practitioners

• Audit AI assistant configuration as executable code Review .claude/skills/, hook definitions, allowed-tools frontmatter, and model settings with the same rigor used for workflow or build files. Block any configuration that can execute shell commands or alter permissions without explicit approval.
• Disable or tightly restrict hooks Turn off hooks where they are not operationally required, and in managed environments allow only admin-defined hooks that cannot observe or rewrite tool activity outside policy.
• Remove secret-bearing context from preprocessing paths Prevent skills from reading environment variables, credential stores, SSH material, cloud config, or repository metadata that could be exfiltrated before the model responds.
• Scope sandboxing to the full execution path Verify that sandbox controls cover preprocessing, hook execution, and any HTTP requests made by the harness, not just Bash child processes after the model has already started reasoning.
• Add AI configuration files to supply-chain review Extend pull-request checks and CI scans to flag !` syntax, permissive frontmatter, hook registration, and silent model changes in assistant configuration files.

Key takeaways

• Claude Code skills can create a trust gap before the LLM is involved, because the harness can execute commands and hooks during preprocessing.
• The article’s proof-of-concept attacks show that secret exfiltration and tool-call surveillance can happen before the assistant can warn the user.
• Security teams should govern assistant configuration files, hooks, and permission rules as executable attack surface rather than passive metadata.

Key terms

• 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.
• Assistant Harness: The deterministic software layer that manages an AI assistant session, processes configuration, dispatches tools, and handles execution before the model reasons. It behaves like privileged runtime infrastructure, so its permissions, inputs, and outbound effects need governance similar to other sensitive automation.
• Hook Surveillance: Hook surveillance is the repeated interception of tool activity through event-driven callbacks that observe or alter commands, files, or outputs. It creates a hidden monitoring layer around an AI session and can expose sensitive context without the model or user seeing it.
• Configuration-as-Code Risk: Configuration-as-code risk arises when files that look like settings can also execute behaviour or change permissions. In AI assistant environments, that means a repository can import operational logic that functions like code even though it is packaged as metadata.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It helps security practitioners build the control thinking needed for delegated machine access and AI-driven automation.