Claude Code skills expose hidden attack paths in agentic AI workflows

At a glance

What this is: This research shows that Claude Code skills can be abused through frontmatter fields to bypass permissions, hide malicious instructions, trigger background execution, and persist poisoned memory.

Why it matters: It matters because agentic coding tools introduce non-human identity risk into developer workflows, and security teams need controls that inspect more than visible prompt text or repository body content.

By the numbers:

• In one test, the same task configured to use Opus with high effort cost $0.1451, more than five times the $0.0274 cost of the low-effort Haiku version.

👉 Read HiddenLayer’s research on Claude Code skill frontmatter abuse

Context

Claude Code skills are reusable task modules that can extend an agent’s behavior inside a project repository. The security problem is that the control surface is not limited to the visible skill body. Frontmatter fields can change what the agent is allowed to do, when it runs, and whether the user sees it at all.

For identity security teams, this is a non-human identity governance problem inside the software development lifecycle. Skills, tool permissions, and project memory together define a runtime privilege model for the agent, and the article shows that model can be manipulated through fields many users never inspect.

That makes skills files closer to executable policy than documentation. The starting position here is unfortunately typical for fast-moving agentic AI adoption, where usability arrives before governance maturity.

Key questions

Q: How should security teams validate AI agent skills before installation?

A: They should execute each skill in a controlled sandbox with real agent context and inspect actual behaviour, not just source code. The review should cover tool calls, file access, DNS resolution, outbound traffic, and credential access attempts before the skill is allowed to inherit production permissions. Behavioral evidence is the only reliable trust signal for downloaded skills.

Q: Why do hidden skill fields create governance risk for agentic coding tools?

A: Hidden fields break the assumption that what the user can see is all the agent can do. When metadata controls permission, timing, or invocability, a benign-looking skill can execute actions that were never obvious in the UI. That turns agent governance into a visibility problem as much as a permissions problem.

Q: What breaks when project memory can be modified by a skill?

A: Persistent agent memory can preserve malicious instructions after the originating skill is removed, which defeats ordinary cleanup and review routines. Once memory is written, later sessions can inherit the attacker’s intent without another visible trigger. That is why memory writes need the same governance attention as configuration or code changes.

Q: Who is accountable when an imported skill triggers unauthorized actions?

A: Accountability sits with the organisation that allowed the skill into a shared workflow and with the team that failed to review the privilege fields inside it. In practice, this needs ownership across IAM, platform engineering, and application security because the problem spans identity, execution, and software supply chain governance.

Technical breakdown

How skill frontmatter changes agent permissions

Frontmatter is the metadata layer that tells the agent how a skill should behave. In this case, fields such as allowed-tools can pre-authorize tools like Bash, Read, Write, WebFetch, or WebSearch, which changes the normal approval boundary for a session. If the agent accepts those instructions, a skill can run actions that would otherwise require user confirmation. That is an identity problem, not just a prompt-injection problem, because the skill is effectively carrying delegated runtime authority inside the project. The risk grows when the permission boundary is defined in files that users rarely audit deeply.

Practical implication: treat skill metadata as privileged policy and inspect it with the same rigour you apply to secrets and access grants.

Why hidden invocation and skill chaining matter

The article shows two visibility failures. First, when_to_use can move consequential instructions out of the user-visible summary while still influencing agent behaviour. Second, user-invocable=false removes a skill from the slash menu, yet the skill can still be triggered by background conditions. Skill chaining adds another layer because one skill can invoke another, which turns a local helper into a supply chain path. In agentic environments, that means a benign-looking skill can serve as the launch point for a second hidden action, expanding the attack surface without changing the user’s workflow.

Practical implication: assume that any hidden trigger or chained invocation expands the trusted execution surface and requires explicit review.

How project memory creates persistence

Project memory changes the threat from a one-time action to a durable state change. The article shows that a skill can write to memory without the same permission prompts that protect other files, and the malicious instruction then survives beyond the original skill or session. That is a classic persistence mechanism adapted to agentic systems: the payload moves from the skill into a shared memory artifact the agent will consult later. Once memory is poisoned, future sessions can inherit the attacker’s intent even after the original file is removed.

Practical implication: separate transient agent context from persistent project memory and monitor memory writes as governance events.

Threat narrative

Attacker objective: The attacker wants durable control over agent behaviour inside developer workflows so malicious actions can recur without visible user approval.

1. Entry occurs when a developer imports a skill from a repository or hub and the frontmatter carries hidden tool permissions or trigger logic.
2. Escalation occurs when the agent executes pre-authorized tools, chains into another skill, or writes attacker-controlled instructions into project memory without visible approval.
3. Impact is persistent malicious behaviour inside the codebase, including hidden command execution, token waste, and recurring sabotage across later sessions.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

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

NHI Mgmt Group analysis

Skill frontmatter is now a privilege boundary, not just metadata: The article shows that allowed-tools, when_to_use, and user-invocable can materially change what an agent is permitted to do and whether the user can see it. That means the review model for agentic coding tools has to treat frontmatter as part of the control plane, not as descriptive packaging. For practitioners, the governance question is whether metadata can alter runtime authority without a separate approval path.

Hidden invocation creates an identity blind spot inside the development lifecycle: A skill that is removed from the menu but still triggerable in the background breaks the assumption that user visibility equals user consent. This is a non-human identity issue because the actor is not a person but the tool-mediated execution chain behind the person. The implication is that audit and approval models built for visible user actions do not cover background agent triggers.

Persistent memory poisoning is the clearest sign that agentic workflows need lifecycle governance: Once malicious instructions are written into project memory, the payload outlives the original skill and session. That is not a simple prompt-injection issue, it is lifecycle persistence for a non-human identity artefact. Practitioners should read this as a signal that offboarding, retention, and revocation logic must extend to agent memory as well as repository content.

The software supply chain now includes agent behaviour, not just code: A compromised package or imported skill can change downstream project behaviour through delegated agent actions. That broadens the supply chain model from dependency integrity to identity and action integrity. Security teams need to treat agent skills as supply chain objects with privileges, triggers, and persistence, not as passive configuration files.

HiddenLayer’s findings sharpen the agent metadata trust gap: The problem is not that a skill exists, but that the fields governing invocation, visibility, and tool access are easy to overlook. The result is a trust gap between what developers think the skill does and what the agent can actually do. Practitioners should assume that any uninspected field can become a governance failure.

From our research:

• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
• Another finding from the same research shows that 80% of organisations report AI agents have already performed actions beyond their intended scope.
• That visibility gap is why practitioners should also review OWASP NHI Top 10 for agentic application risk patterns that intersect with hidden tool use and privileged context.

What this signals

Agentic coding tools are turning repository content into runtime authority, which means programme owners need controls that understand both execution and persistence. Hidden frontmatter, background triggers, and memory writes create a governance boundary that is closer to NHI lifecycle management than to ordinary source-code review. Teams that already track agent visibility should pair that work with the NIST AI Risk Management Framework because the risk is about delegated behaviour, not just model output.

Agent metadata trust gap: the field is moving toward a simple test. If a review process only inspects the visible body of a skill, it is not reviewing the real privilege model. That means security teams need to align code review, repository controls, and memory governance into one workflow before agent adoption spreads further.

For practitioners, the immediate signal is that agentic controls have to sit closer to the development pipeline. The same project that accepts a skill from an internal repo may also need allowlisting, metadata linting, and auditable memory changes, because hidden runtime authority can persist longer than the session that created it.

For practitioners

• Scan skill files beyond the body text Inspect frontmatter fields such as allowed-tools, when_to_use, model, effort level, and user-invocable during code review and repository intake. Treat the raw SKILL.md file as the authoritative object, not the rendered summary, and flag any field that changes execution authority or visibility.
• Block hidden execution paths from imported skills Require explicit approval for background triggers, skill chaining, and any skill that can invoke tools without a visible user prompt. If a skill can run in the background or call another skill, it should be reviewed as a privileged workflow component, not a convenience feature.
• Separate agent memory from transient task context Monitor writes to project memory as persistence events and restrict which workflows can create or modify memory files. Preserve an audit trail for memory changes so that poisoned instructions can be identified, removed, and tied back to the originating skill or session.
• Apply supply chain controls to skills repositories Validate skills pulled from internal repos, external hubs, and third-party packages with the same scrutiny used for dependency trust. Where possible, pair code review with static checks for disallowed frontmatter patterns and risky tool permissions before the skill enters a shared project.

Key takeaways

• Claude Code skills can alter agent behaviour through hidden metadata, which makes frontmatter part of the privilege model.
• The most serious risk is persistence, because poisoned project memory can survive session boundaries and even skill removal.
• Teams need review, approval, and audit controls that inspect the full SKILL.md file and not just the visible skill description.

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.
• Project Memory Poisoning: Project memory poisoning happens when an attacker writes malicious instructions into persistent memory used by an AI agent. The payload survives session boundaries and can influence later actions even after the original malicious skill or prompt is removed.
• Background Skill Invocation: Background skill invocation is execution triggered without an explicit user-facing run command. It matters because the agent can act on hidden conditions or delegated rules, making visibility and approval weaker than developers often assume.
• Activation Trust Gap: The activation trust gap is the difference between trusting data because it is protected and governing it because it is being reused. It appears when organisations move data from backup or archival systems into AI pipelines without reapplying access, sensitivity, and consumer controls.

What's in the full report

HiddenLayer's full research covers the operational detail this post intentionally leaves for the source:

• Exact frontmatter fields that enabled permission bypasses and hidden execution in Claude Code
• Step-by-step examples of how memory poisoning persisted after the original skill was removed
• Testing notes on downgrade attacks, cost-amplification, and background task invocation
• Behavioural observations showing how the same skill could be hidden from the slash menu while still executing

👉 HiddenLayer’s full post covers the attack chain, hidden fields, and persistence mechanism in detail

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.