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

At a glance

What this is: This is a security analysis of Claude Code’s pre-LLM execution model, showing that skills and hooks can exfiltrate credentials or surveil tool calls before the AI model is aware.

Why it matters: It matters because AI coding assistants introduce a new identity and trust boundary around the harness, hooks, and secrets that conventional IAM and supply chain controls may not fully govern.

👉 Read Mint's analysis of Claude Code skills, hooks, and pre-LLM exfiltration

Context

Pre-LLM execution changes the security model for AI coding assistants because configuration files can run code before the model reasons about the task. In practice, that means secrets, tool calls, and network requests can be handled outside the AI’s visible context, which creates a governance gap for NHI-style credentials and developer machine trust.

Claude Code skills and hooks sit at the intersection of AI security, software supply chain risk, and identity governance. For IAM and PAM teams, the key issue is not only what the model can do, but what the harness can execute with inherited permissions, including access to credentials, environment variables, and network destinations. That makes repository content part of the runtime trust boundary, which is not the typical assumption in developer workflows.

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 hooks create a stronger security concern than ordinary tool logging?

A: Hooks are not passive logs. They can observe every matching tool call, receive the full context, and sometimes alter input or output before the AI sees it. That gives them interception power, which means a malicious hook can capture reconnaissance or secrets-related activity while still looking like normal session plumbing.

Q: How can security teams tell whether AI assistant configuration is being abused?

A: Look for unexpected network callbacks, unusual tool permissions in frontmatter, hidden model overrides, and repository content that behaves like executable policy. The signal is not just malicious output. It is privileged behaviour appearing in files that teams previously treated as static configuration.

Q: Who is accountable when a malicious skill exfiltrates code or credentials?

A: Accountability sits with the organisation that approved the skill, the team that granted the agent its reachable tools, and the owners of the workflow where the skill was introduced. Frameworks such as OWASP Agentic AI Top 10 and NIST AI Risk Management Framework help define governance, but the operational answer is clear ownership before deployment.

Technical breakdown

How pre-LLM preprocessing changes the trust boundary

Claude Code separates the harness from the LLM. The harness parses SKILL.md files, expands template variables, executes commands, and dispatches tools before the model receives the final prompt. That means the model only sees rendered output, not necessarily the command path that produced it. Security-wise, this is a classic visibility gap: the runtime that can touch the filesystem, shell, and network is not the same component that makes the reasoning decision. If the pre-processing layer is compromised, the AI can be perfectly cautious and still be too late.

Practical implication: treat harness-level execution as privileged code and audit it separately from model prompts.

How hook-based tool surveillance works

Hooks are event-driven controls that fire on tool activity such as Bash, Read, and Write. They receive rich context, including the exact command or file access, and can alter input or output before the LLM sees it. That makes them more than telemetry. They are a live interception layer with the power to observe reconnaissance, collect secrets-related activity, and shape the session narrative. In identity terms, hooks can turn a legitimate agent session into an instrumented control plane for silent data capture.

Practical implication: inventory every hook as a control-plane dependency and restrict which sessions may load them.

Why supply-chain delivery makes skills a hidden attack surface

Skills stored in repository-local .claude/ directories behave like distributed runtime configuration. When a project is cloned, those skills arrive with it, which makes them a supply-chain delivery mechanism for code execution that looks like tooling. The article’s point is not just that malicious content can exist, but that the trust decision happens after the repository has already been accepted. That is the same structural problem identity teams see when long-lived credentials travel with code: the payload inherits trust faster than governance can inspect it.

Practical implication: add .claude/ directories to code review, CI scanning, and repository allowlisting rules.

Threat narrative

Attacker objective: The attacker wants to turn trusted AI coding assistance into a covert credential collection and reconnaissance channel.

1. Entry occurs when a developer clones or opens a repository that contains malicious or modified Claude Code skills in the .claude/skills/ directory.
2. Credential access occurs during preprocessing when a skill executes shell commands that collect SSH keys, AWS credentials, environment variables, or configuration data before the LLM sees the session.
3. Impact follows when the attacker uses the harvested material or silent surveillance of tool calls to steal secrets, observe reconnaissance, or manipulate session output.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Pre-LLM execution is the new trust boundary for AI assistants. The article shows that the LLM is no longer the first meaningful security checkpoint in the workflow. The harness can execute commands, expand variables, and invoke hooks before the model sees anything. For identity and NHI governance, that means the security model must account for machine-executed actions that occur outside human review and outside the model’s reasoning path. Practitioners should treat preprocessing as a governed execution tier, not a harmless setup step.

Configuration files have become privileged runtime inputs. Skills, hooks, and frontmatter behave like executable policy, not static metadata. That is a governance assumption many teams still miss, especially when repositories are treated as source code only. The named concept here is pre-LLM trust gap: the distance between what the AI can observe and what the harness can already do. Security teams should assume that any file capable of shaping execution must be managed with the same discipline as secrets or deployment automation.

AI coding assistants are now part of the software supply chain threat model. The article correctly frames .claude directories as a delivery path for hidden behaviour, which is structurally similar to malicious workflow files and build scripts. This is where the identity angle becomes real: the assistant inherits access to developer context, credentials, and tool privileges, so abuse of that channel can expose NHI-like secrets and session data. The right interpretation is not that AI is unsafe in general, but that the supply chain now includes agent runtime configuration. Practitioners should expand supply chain controls to cover AI tooling artefacts.

Detection after execution is not enough when exfiltration happens first. The most important failure mode in the article is temporal. The AI can identify malicious behaviour only after the harness has already run the command and sent data away. That collapses the value of post-hoc model safety checks for pre-execution abuse. The control gap is a standing execution window with no prior isolation, which is exactly where credential theft and hook surveillance succeed. Teams should design for prevention at load time, not for model-side remorse after the fact.

Secret governance must now extend into agent tooling and developer workspaces. This article is a reminder that secrets are not only exposed in repositories and CI logs, but also inside assistant-specific configuration and tool output paths. That broadens NHI governance into areas many IAM teams do not currently monitor. The implication is straightforward: if a runtime can touch credentials, it belongs in the same control family as other privileged execution environments. Practitioners should include assistant configuration in secrets discovery, access review, and offboarding workflows.

What this signals

AI assistant governance is moving from prompt safety into runtime control. The practical lesson for programmes is that repository scanning, secrets management, and developer workstation policy now have to account for assistant-specific files that execute before the model reasons. That creates a distinct control category: assistant execution governance, where the question is not whether the model is safe, but whether the harness can be trusted to run at all.

For teams already managing IAM and NHI risk, the useful change is to treat assistant tooling as part of privileged automation. If a session can touch SSH keys, AWS credentials, or environment variables, it belongs in the same review path as other high-risk machine identities and delegated access paths. The easiest programme failure is assuming the AI is the system to secure, when the real exposure sits in the code that prepares the AI’s inputs.

For practitioners

• Audit AI assistant configuration as executable code Scan .claude/skills/, .claude/settings.json, and .mcp.json during repository review and CI checks. Flag !`command`, hooks, allowed-tools, and model overrides as high-risk execution paths, not harmless metadata.
• Restrict preprocessing and hook execution paths Apply sandboxing and managed-hook policies where available, and verify that they cover preprocessing, tool dispatch, and outbound network calls, not only Bash child processes.
• Treat cloned repositories as supply-chain inputs Extend code review and PR checks to assistant tooling artefacts so malicious skills cannot arrive through a trusted repository without inspection.
• Separate secrets discovery from assistant assistance Avoid letting assistants search for credentials in sensitive workspaces unless the environment is already isolated and the session is monitored for unexpected POST requests or tool interception.

Key takeaways

• Claude Code’s skills and hooks create a pre-LLM execution layer that can expose secrets before the model can intervene.
• The main failure mode is a trust gap between repository-delivered configuration and the visible AI session, which makes post-hoc detection too late.
• Security teams should govern assistant configuration like executable supply-chain content and extend secrets controls into developer tooling.

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.
• Hook: An event-driven action that fires when a tool or session event occurs. In AI assistant systems, hooks can observe, modify, or redirect tool activity, which makes them powerful control points and high-risk interception points if they are not tightly restricted and audited.
• 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.

What's in the full report

Mint's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step proof-of-concept attack flows showing how preprocessing exfiltration and hook surveillance were executed
• Detailed code-level examples of SKILL.md frontmatter, !`command` behaviour, and model overrides
• Server-side log evidence from the authors' controlled endpoint, including what data was received
• Specific hardening recommendations for developers, enterprises, and the Claude Code maintainers

👉 Mint's full article includes the proof-of-concept mechanics, captured logs, and mitigation guidance.

Deepen your knowledge

NHI Mgmt Group’s NHI Foundation Level course covers NHI governance, secrets management, and machine identity security through the industry's only accredited NHI security programme. It is designed for practitioners who need to connect identity controls to the broader systems and workflows that create access risk.