AI agent skills turn the extensibility layer into an identity risk

At a glance

What this is: This is an independent analysis of AI agent skills as an attack surface, showing that skills can act as prompt injection by design and turn the extensibility layer into a governance problem.

Why it matters: It matters because IAM, NHI, and agentic AI programmes now have to govern instruction sets, package trust, and runtime privilege together instead of treating them as separate controls.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes , and as quickly as 9 minutes in some cases.

👉 Read Backslash Security's analysis of AI agent skill governance and attack paths

Context

AI agent skills are modular instruction bundles that extend agent behaviour, often inside development environments and agentic workflows. In practice, they sit close to the control plane for what the agent sees, does, and can reach, which makes them materially different from ordinary plugins or documentation.

The security problem is that skills can carry filesystem, network, and credential access inside the same instruction path that shapes agent behaviour. For IAM and NHI teams, that means instruction trust, dependency trust, and privilege scope now intersect in one place, and the weakest of the three can become the breach path.

Key questions

Q: How should security teams govern AI agent skills in production environments?

A: Security teams should treat agent skills as governed instructions with privileged influence over runtime behaviour. That means requiring provenance checks, review, allowlisting, and tool-scoping before deployment. Skills should not inherit filesystem, network, or secret access by default. Governance must cover the skill itself, the agent that consumes it, and the execution environment.

Q: Why do AI agent skills create more risk than ordinary plugins?

A: They create more risk because they live inside the agent’s instruction path and can alter decisions, not just add features. When a skill can rewrite behaviour and reach tools or credentials, the issue becomes identity and privilege governance. The control question is who can author the instruction set and what it can cause the agent to do.

Q: What do security teams get wrong about skill marketplaces?

A: They often treat marketplaces as convenience layers rather than supply chain entry points. If there are no signatures, lockfiles, or mandatory review, a marketplace becomes a trust gap, not a distribution channel. Security teams should assume that popularity, downloads, or helpful naming do not prove safety.

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

Why AI agent skills behave like prompt injection by design

Skills are injected into an agent’s system prompt, which gives them a privileged place in the decision process. That means a malicious or poorly written skill can change how the agent interprets goals, chooses actions, and sequences work. In agentic environments, the prompt is not just conversational input. It can function as executable policy when the agent treats the skill as authoritative guidance. This creates a higher-risk path than ordinary user prompts because the instruction is meant to persist and shape future behaviour. Practical implication: treat skills as governed code and governed instructions, not as content files.

Practical implication: classify skills as governed instructions with approval, review, and provenance controls before deployment.

How unsigned skills expand the supply chain risk for agentic AI

The article points to a marketplace with no package signatures, lockfiles, or mandatory review. That combination removes the usual trust anchors practitioners rely on for software supply chain control. Without provenance, a skill can look helpful while actually carrying malicious logic, hidden dependencies, or external script execution. This is especially dangerous in vibe coding and agentic development, where the user assumes the skill is an efficiency layer rather than a runtime authority. Practical implication: apply software supply chain controls to skills with the same seriousness as code dependencies and internal packages.

Practical implication: require provenance, review, and dependency control for every skill source, internal or external.

Why skill abuse becomes an identity and privilege problem, not just a content problem

The article shows that a skill can request filesystem, network, and shell access beyond the original intent, and can even drive silent exfiltration. That moves the issue from content moderation into identity governance, because the real question is what the agent is allowed to do once the instruction is trusted. If the skill can widen effective privilege without a human review step, then the control failure is not just detection. It is an over-trusted delegation boundary. Practical implication: constrain the agent’s reachable tools and privileges before allowing new skills into production.

Practical implication: limit reachable tools and privilege scope before allowing new skills into production environments.

Threat narrative

Attacker objective: The attacker aims to convert trusted agent instructions into silent repository or credential exfiltration without triggering the user’s normal review path.

1. Entry occurs when a malicious AI agent skill is installed from a public marketplace or copied into a local workflow with no meaningful provenance checks.
2. Credential access and data theft occur when the injected instructions convince the agent to access filesystem contents, shell access, SSH keys, or cloud credentials as part of its task.
3. Impact occurs when the agent silently exfiltrates repository contents or credentials, leaving little or no audit trace because the exfiltration was framed as normal task completion.

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

AI agent skills are becoming an identity trust boundary, not just a developer convenience. The article shows that a skill can sit inside the agent’s decision path and shape what the agent is allowed to do, not merely what it reads. That collapses the old separation between instructions and execution, which is why IAM and NHI teams have to treat skills as governed runtime authority. The practitioner conclusion is simple: the trust model for extensibility now belongs in identity governance.

Prompt injection by design is the right framing for skill abuse. The problem is not only that a skill may contain malicious content, but that the architecture gives the skill privileged influence over agent behaviour from the start. That means the security issue is structural, not accidental. Once an organisation lets unreviewed skills rewrite agent behaviour, it has already accepted a control plane that can be turned against it. The practitioner conclusion is that skills need pre-execution trust decisions, not after-the-fact review.

Unverified skill marketplaces create supply chain risk with direct privilege consequences. The article describes a world with no signatures, no lockfiles, and no mandatory review, which removes the baseline evidentiary controls used to establish provenance. In identity terms, that means the organisation cannot prove who authored the instruction set or what logic it contains before it reaches a privileged agent. The practitioner conclusion is to align skill onboarding with software supply chain governance, not informal catalog browsing.

Agent privilege now depends on instruction provenance, tool reach, and runtime constraints at the same time. A skill that can request shell, network, or filesystem access turns the agent into a higher-risk executor even when the task appears routine. This is the same governance lesson seen in NHI and workload identity programs: access scope is only useful when it matches the real execution path. The practitioner conclusion is to enforce least privilege at the skill boundary, not only at the account boundary.

Identity governance for agentic AI must recognise the modular instruction set as a control surface. The named concept here is the skill trust boundary, which is the point where a reusable instruction set becomes an enforceable authority over agent action. That boundary is where policy, provenance, and privilege meet. The practitioner conclusion is to design review, allowlisting, and revocation around the skill itself, not just around the agent that consumes it.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• That visibility gap makes agent skills a forward problem for identity programmes, especially where instruction provenance and delegated access now need the same control discipline as OAuth-connected applications.

What this signals

Skill trust boundary: agentic environments now need a control line between trusted instructions and trusted execution. If a skill can influence decisions and invoke tools, then the organisation must govern it like a privileged identity artifact, not a convenience layer. That is why supply chain controls and NHI controls are converging around the same runtime surface.

With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, the broader identity lesson is that delegated access becomes unsafe when provenance is unclear. Skill governance repeats that pattern inside the development stack, where discovery, allowlisting, and revocation need to happen before runtime trust is granted.

The practical signal for IAM and security architects is that agentic tooling is moving from experimentation into policy territory. Teams should expect skills, plugins, and MCP-connected tooling to be evaluated together as one identity and privilege plane, not as separate technology choices.

For practitioners

• Inventory every deployed skill and its source Map where skills are installed across IDEs, local workstations, and managed agent environments. Record publisher, source channel, runtime context, and which tools each skill can reach before allowing it into shared environments.
• Require provenance controls before skill onboarding Block unverified skills, unsigned packages, and any skill with hidden or remote script execution until review is complete. Treat signatures, dependency history, and ownership as mandatory acceptance criteria.
• Constrain agent tool reach at the skill boundary Separate skill approval from tool approval so a trusted instruction set cannot automatically inherit filesystem, network, or shell access. Use least privilege to narrow what the agent can invoke when a new skill is enabled.
• Detect exfiltration patterns in agent task logs Look for task completion steps that include repository pushes, external branch creation, credential reads, or unusual outbound transfers that are framed as normal workflow actions. Prioritise alerting when the behaviour occurs without a corresponding human change request.
• Align skill governance to NHI and supply chain controls Fold skills into the same control set used for NHI onboarding, software dependency review, and privileged access approvals. Where a skill can alter agent behaviour, treat revocation and version control as operational security tasks, not admin cleanup.

Key takeaways

• AI agent skills are a governance issue because they can rewrite agent behaviour and expand privilege at the same time.
• Unverified skill marketplaces create a supply chain problem that becomes a code and credential theft problem once agents trust the instructions.
• Practitioners need to govern skill provenance, tool reach, and revocation as part of the same identity control plane.

Key terms

• AI Agent Skill: A reusable instruction bundle that changes how an AI agent behaves during runtime. In practice, it can shape goals, tool use, and task execution, which makes it more like governed runtime logic than a simple plugin or note file. Because it can influence action, it needs provenance and access control.
• Skill Trust Boundary: The point at which an instruction set becomes trusted enough to influence agent behaviour and tool access. It is a governance boundary, not just a technical one. Once crossed, the organisation is no longer reviewing a suggestion, it is authorising a path that can change what the agent does next.
• Prompt Injection By Design: A condition where the architecture itself gives untrusted instructions privileged access to the agent’s decision process. The issue is not only malicious content, but the fact that the system is built to let those instructions steer execution. That creates a structural governance problem, not just a filtering problem.
• Instruction Supply Chain: The ecosystem of files, marketplaces, dependencies, and publishers that deliver agent instructions into production workflows. Like software supply chains, it can carry hidden risk through unreviewed sources, weak provenance, and altered dependencies. For agentic systems, the instruction chain can be as important as the code chain.

What's in the full article

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

• Detailed examples of malicious and manipulated AI skills, including the ClawHavoc campaign and marketplace abuse patterns.
• The article's breakdown of continuous discovery, risk assessment, and policy enforcement for Skills.md and associated scripts.
• Operational examples of blocking unverified publishers and removing unapproved skills from developer environments.
• The source's product workflow for scanning and governing skills across agentic development stacks.

👉 Backslash Security's full post covers the skill discovery workflow, policy controls, and examples of malicious skill abuse.

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.