Claude Code skills expose hidden attack paths in agentic AI workflows

At a glance

What this is: HiddenLayer shows that Claude Code skills can conceal tool permissions, background triggers, and memory-poisoning instructions inside frontmatter, turning a workflow helper into a hidden attack surface.

Why it matters: This matters because agentic coding environments can inherit malicious instructions from skills, so IAM, PAM, and security teams need to govern agent behaviour, not just visible prompts and code.

Context

Claude Code skills are small instruction bundles that can extend agentic coding workflows, but their frontmatter can also carry control fields that change how the agent behaves. In this case, the security gap is not the code body alone. It is the combination of hidden metadata, pre-authorised tool access, and triggers that can execute outside normal user review.

That creates an agentic identity problem as much as an application security problem. If a skill can bypass a permission prompt, hide consequential instructions, or write persistent memory into a project, then the trust boundary has moved from the visible prompt to the skill file itself. For teams governing AI coding agents, the issue is how much runtime authority metadata can confer before a human notices.

The article frames this as a supply-chain risk for agentic workflows. That is the right lens: once skills can arrive through repositories, hubs, or shared projects, the governance challenge becomes one of provenance, visibility, and least-privilege control over what an agent is allowed to do.

Key questions

Q: What breaks when skill frontmatter can pre-authorise tools in agentic coding workflows?

A: Permission prompts stop being a reliable control because the effective authority moves into metadata that the user may never see. That creates delegated execution without fresh intent, which is dangerous when the skill can reach shell commands, file writes, or network fetches. Teams should treat tool grants in skills as privileged scope, not harmless convenience.

Q: Why do hidden skill fields create more risk than visible prompt injection?

A: Hidden fields bypass the review path that developers naturally use for names, descriptions, and visible instructions. If consequential commands sit in frontmatter such as when_to_use or user_invocable, the user may approve a skill without seeing the real behaviour. The risk is not only injection, but incomplete inspection of the execution surface.

Q: How should teams govern persistent memory writes from AI coding agents?

A: They should treat project memory as lifecycle state, not scratch space. If a skill can write persistent instructions without the same controls applied to ordinary files, it can outlive the session and influence later work after the original trigger is gone. Governance needs ownership, review, and reset processes for that stored context.

Q: When do skills become a software supply chain risk rather than a local workflow helper?

A: They become a supply chain risk as soon as they can be imported, reused, or chained across projects without full inspection of their metadata and allowed capabilities. At that point, the threat is not just the current repository. It is the reuse of an artefact that can carry hidden authority into every downstream workflow.

Technical breakdown

How skill frontmatter becomes an execution boundary

Claude Code skills are Markdown files with frontmatter that can define context, tool access, and invocation behaviour. In the article’s examples, fields such as allowed-tools, when_to_use, and user_invocable change what the agent can do and when it can do it. That means the security boundary is not just the skill body or the prompt text. It is the metadata that silently shapes agent runtime authority. In agentic coding, the frontmatter can function like a policy layer, except it may be inherited from a repository or shared skill without the user seeing the effective control state.

Practical implication: security review must inspect skill metadata, not just visible instructions or code bodies.

Why permission prompts fail in agentic coding workflows

The article shows that pre-authorised tool lists can bypass runtime permission prompts for actions such as Bash, Read, Write, WebFetch, and WebSearch. When a skill declares allowed-tools, the agent may execute those actions without asking again, even when the instruction came from an untrusted file. That is a material shift from interactive approval to inherited authority. In practical terms, the model assumes the tool grant is safe because it was declared earlier, but the effective source of trust may now be a skill file rather than the end user’s intent. This is a runtime authorisation problem, not just a prompt-injection problem.

Practical implication: treat tool pre-authorisation in skills as a privileged control and restrict it to reviewed, trusted sources.

How hidden triggers create persistence and visibility gaps

The article describes two related patterns: instructions moved into fields the user does not normally see, and skills set to run only in the background. Combined with project memory writes, this creates persistence that can survive session closure and even skill removal. The deeper problem is observability. If frontmatter is not rendered in the UI and memory files can be written without the same friction as ordinary files, the user loses the ability to review the true execution surface. In agentic systems, that makes hidden metadata a durable control channel rather than a convenience field.

Practical implication: add inspection and monitoring controls for hidden skill fields, background invocation, and project memory writes.

Threat narrative

Attacker objective: The attacker aims to convert a benign-looking skill into a persistent control channel that manipulates agent actions, costs, and project state without user awareness.

1. Entry occurs when a developer imports or invokes a skill from a repository, hub, or shared project that contains malicious frontmatter.
2. Credential or capability abuse follows when the skill pre-authorises tools such as Bash, Read, Write, WebFetch, or WebSearch without a fresh permission prompt.
3. Escalation happens when hidden instructions trigger background execution, invoke other skills, or write attacker-controlled project memory that persists beyond the original skill.
4. Impact is persistent malicious behaviour in the coding workflow, including covert command execution, cost amplification, and poisoned project state that can affect later sessions.

Breaches seen in the wild

• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
• Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.

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

Skill frontmatter is now part of the agent’s trust boundary: HiddenLayer’s findings show that the real control plane in agentic coding is not just the prompt or the code body. Frontmatter can alter permissions, visibility, and execution timing before the user sees the effective behaviour. That shifts skills from convenience artefacts to governance objects, which means review discipline has to extend into metadata.

Pre-authorised tool use creates a delegated privilege problem, not a UI problem: When a skill can grant Bash or Write access through declared fields, the agent is no longer operating under simple user prompting. It is executing with inherited authority from a file. That is exactly the kind of delegation chain that identity teams recognise in service accounts, and the same control expectation applies here: capability must be bounded at issuance, not discovered after execution.

Hidden instructions create an observability gap that conventional review misses: If the user interface only shows name and description, then the most sensitive fields are effectively outside the normal approval loop. That means review processes built around visible prompts, code diffs, or body text will miss the actual attack surface. The practitioner conclusion is straightforward: visible review is not sufficient when the control lives in non-visible metadata.

Persistent memory poisoning turns a transient abuse into a lifecycle issue: The article demonstrates that attacker-defined behaviour can survive session boundaries and remain after the originating skill is removed. That is not just a one-time compromise. It is a lifecycle failure in the management of agent context. Once memory becomes writable through a skill path, the governance question becomes who owns and resets that state over time.

Claude Code skills now sit inside the software supply chain for agentic workflows: A skill can arrive from a repository, a hub, or an internal project, and any of those paths can carry hidden authority. That broadens the governance surface from software artefacts to operational intent. Teams should treat skill intake, inspection, and allowance as part of supply-chain security, because the agent executes what the metadata permits, not just what the user can see.

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.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

Hidden skill metadata is a governance blind spot: Teams evaluating agentic coding should assume the visible interface is only a partial control plane. The more authority that sits in non-rendered fields, the less effective conventional code review becomes, and the more important pre-ingestion inspection and runtime observability become.

Agentic workflow trust now extends beyond code into behaviour-shaping metadata: A skill that can alter tool scope, execution timing, or persistence is no longer just an enhancement file. It is an identity-bearing artefact that should be tracked with the same seriousness as any delegated service account or privileged automation.

Runtime observability has to replace user vigilance as the primary safeguard: Relying on a developer to notice malicious agent behaviour in real time does not scale. Security teams need hooks, logs, and policy checks that expose background invocation, unexpected tool use, and context persistence before those actions become normalised.

For practitioners

• Inspect skill frontmatter as a governed artefact Review allowed-tools, when_to_use, user_invocable, model, and effort fields before a skill is accepted into a project or shared team workflow.
• Restrict pre-authorised tool scopes Limit tool permissions in skills to the smallest practical set and treat any skill that can invoke shell, file write, or network fetch as privileged.
• Block hidden background execution paths Disallow skills that can run invisibly in the background or that trigger on ordinary developer actions without a clear approval step.
• Monitor project memory writes Track when skills can create or modify project memory files, because persistence there can outlast the originating skill and alter later sessions.
• Review skills from every intake path Apply the same validation standard to skills from internal repositories, public hubs, and developer-imported packages before they are used in production work.

Key takeaways

• Claude Code skills can embed authority in frontmatter, which means the hidden control surface matters as much as the visible prompt or code body.
• The article’s proof-of-concept shows that tool pre-authorisation, background triggers, and memory writes can create persistence and visibility gaps in agentic workflows.
• Teams need to inspect metadata, constrain delegated tool access, and monitor persistent context because agent behaviour can be shaped long before a user notices the skill’s true effect.

Key terms

• Skill Frontmatter: Skill frontmatter is the metadata block that shapes how an agentic skill behaves before its body runs. In practice it can define permissions, triggers, visibility, and execution context, which makes it a governance surface, not just a description field.
• Background Invocation: A mode where an agent runs a skill or task without the user explicitly selecting it at the moment of execution. In agentic coding, background invocation is risky when the trigger is hidden or when the task can execute with inherited authority and limited human awareness.
• Memory Poisoning (ASI06): An attack where malicious content is injected into an AI agent's memory or context, causing it to alter its behaviour in subsequent tasks, potentially exfiltrating secrets, escalating privileges, or acting against its intended purpose.
• Tool Pre-Authorisation: A control pattern where a skill or policy grants an agent permission to use specific tools in advance. For autonomous or semi-autonomous workflows, pre-authorisation must be tightly governed because it can bypass fresh user intent and expand the agent’s effective operating scope.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.