Towards Secure Agent Skills: Architecture, Threat Taxonomy, and Security Analysis

arXiv:2604.02837 · cs.CR, cs.AI · Submitted 2026-04-03 · Read on arXiv

Listen

Transcript

Introduction to the show: ident: Security Radio. Generated commentary on the latest security and cryptography papers.

Nadia: Today's paper: "Towards Secure Agent Skills".

Elias: The gist The first comprehensive security analysis of the Agent Skills framework reveals that most severe threats arise from structural properties of the framework itself,

Nadia: First, who's behind it and why it matters.

Title and authors: Nadia: So we're looking at this paper today titled "Towards Secure Agent Skills: Architecture, Threat Taxonomy, and Security Analysis." It’s basically the first time someone has done a deep dive into the security of this Agent Skills framework.

Elias: Right. It looks like they've mapped out the whole lifecycle of an Agent Skill—Creation, Distribution, Deployment, and Execution—and pointed out exactly where each phase opens up different kinds of threats across three attack layers.

Priya: I’m curious about what that means for us on the ground. Are we talking about vulnerabilities that are really exploitable cheaply, or is this more theoretical stuff?

Nadia: It’s grounded in real-world evidence, which is important because it shows these aren't just abstract risks; they're happening. The paper says they constructed a threat taxonomy with seven categories and seventeen distinct scenarios spread across those three layers.

Elias: That structure helps organize the mess because it breaks down the attack surface into delivery, runtime, and persistence. The authors identified things like supply chain compromise in the first layer, prompt injection in the second layer, and memory file poisoning in the third layer of impact.

Priya: So when you say "supply chain compromise" or "consent abuse," what does that look like practically for a developer or a user?

Nadia: Well, they link this directly to how open marketplaces operate without any mandatory vetting for Skills. It points to the risk of malicious Skills getting into circulation before anyone actually checks them.

Elias: And then there’s the single-approval persistent trust model they mentioned, which leads to consent abuse. It means once a Skill gets that initial green light, it keeps that trust forever, which is a structural weakness.

Priya: I worry about the runtime attacks—prompt injection and code execution. If an Agent Skill can run arbitrary scripts or inject instructions directly into the agent's workflow, how do we even begin to stop that?

Nadia: The paper highlights the absence of a structural data-to-instruction boundary as a key reason for prompt injection vulnerabilities. It means malicious instructions can easily get mixed with the actual data being processed.

Elias: They also found that code execution is possible by exploiting bundled scripts and the runtime dependency mechanisms, which is another direct attack vector in that second layer of threats.

Priya: And then there’s persistence—layer three—where a compromised Skill might stay embedded through configuration poisoning or memory file manipulation. That sounds really insidious because it affects what happens across multiple sessions.

Nadia: Exactly. They validated this whole taxonomy by analyzing five confirmed security incidents in the Agent Skills ecosystem, which shows that these scenarios aren't just hypothetical; they’ve actually happened with things like a MedusaLocker Ransomware Skill mapping to certain threat categories.

Elias: And the ClawHavoc Campaign is another example they used to show how supply chain techniques like typosquatting and ranking manipulation actually work in practice, which ties right into that first layer we talked about.

Title and authors: Priya: So what are the suggested improvements they propose for fixing these issues? What's the actual defense direction they recommend?

Nadia: They suggest defense directions need to be layered, addressing the content layer, distribution layer, runtime layer, and trust model all at once. For instance, tackling consent abuse requires architectural reform of that trust model.

Elias: That includes things like fine-grained permission grants per capability or version-bound trust—meaning you cryptographically bind the relationship to a specific Skill hash at installation time. This would counter post-installation modification where old approvals persist and the scope is undifferentiated.

Priya: I see that version binding sounds like a solid step for fixing that persistence issue we discussed earlier. Does this also help with what they call T4 point 1, malicious scripts <ref:2604.02837#pg1>?

Nadia: They suggest implementing capability-tiered sandboxing where isolation levels are determined by the Skill’s declared scope. This would confine the blast radius of any malicious script based on what it’s supposed to do, rather than just having a blanket restriction.

Elias: That ties back into their open research challenges, like designing a consent model that is both security-effective and usable for non-expert users, which they call C2. And they also suggest extending the specification with mandatory capability declarations and dependency pinning to establish baseline security properties across all compliant agent runtimes.

Priya: If we look at how this changes things for someone who just uses these agents every day, what's the real-world implication of all this analysis?

Nadia: For users, it means treating Skill installation like managing software dependencies, with constant monitoring for content changes. It’s a shift in how you view installing an Agent Skill.

Elias: It’s about moving away from trusting things by default and instead requiring verifiable proof of what a Skill is capable of and where it came from. The whole idea behind the paper is that we need to move toward that kind of rigor for this new framework.

Priya: So, to wrap up, what's the big picture here? What does understanding this Agent Skills attack surface really tell us about deploying these LLM agents widely?

Nadia: It tells us that the structural design itself introduces severe risks if we don't enforce strict controls at every stage of the lifecycle. The paper lays out actionable recommendations for authors, marketplace operators, and platform developers to build something safer.

Elias: They suggest authors document the full set of filesystem and network operations a Skill performs, and marketplace operators need mandatory security review pipelines combining static analysis of scripts with semantic analysis of instructions.

Priya: I think the key thing is that this research provides the foundation for actually building those defenses you need to make broad deployment safe. It sets a standard for what secure Agent Skills should look like before we let them spread everywhere.

Nadia: Exactly. We’ve heard from Nadia, Elias, and Priya on the "Towards Secure Agent Skills: Architecture, Threat Taxonomy, and Security Analysis." That’s all for this discussion on the paper.

The paper's summary: Nadia: So, this paper basically lays out the first deep security look at how Agent Skills work, showing that most of the bad stuff comes from how they are built structurally, not just what's inside them.

Elias: Right. It points out three main structural flaws: no clear boundary between data and instructions, a single trust model that never changes once set, and no required security review before a Skill gets shared in a marketplace.

Nadia: That lack of boundaries is huge because it opens the door for things like prompt injection attacks to happen directly. We’re not even looking at the system as a whole, just one piece of instruction getting mixed up with the data it's supposed to be handling.

Elias: And that single trust model means once a Skill gets approved, that approval sticks forever, which creates this consent gap where you can't easily revoke permissions later. It’s not version-bound or anything like that yet.

Nadia: The results show they mapped out seven different threat types across three stages—delivery, runtime, and persistence—which helps us see the whole danger chain from the marketplace right to long-term system compromise.

Elias: They validated this by looking at real incidents in the Agent Skills world, like a ransomware skill or a campaign that used typosquatting to get access to things. It proves these theoretical categories are actually happening out there.

Nadia: So, what does this mean for us as people who just use these agents every day? It means that installing an Agent Skill isn't just about downloading an instruction file anymore; it’s a security risk depending on where you install it and how you trust the source.

Elias: Exactly. It suggests that for deployment to be safe, we have to move past the current simple trust model and start thinking about mandatory capability declarations and version-bound trust grants.

Nadia: That takes us right into what they propose as defense directions—we need to fix things at every layer, from how the Skill is written down to how the marketplace vets it.

Elias: They also highlight some open challenges for future work, like figuring out a consent model that actually works well for non-expert users and creating better ways to check for malicious intent in natural language instructions.

Nadia: It’s a lot of work, but it gives us a concrete blueprint to start building the necessary controls.

Elias: And if we get those controls right, it could make this whole Agent Skills ecosystem much more reliable.

The paper's improvements: Tom: So, we’re looking at how they suggest fixing these structural problems in Agent Skills to make them safer overall.

Nadia: The authors say you gotta fix it at every layer—the content layer, the distribution layer, the runtime layer, and that trust model itself. It’s not a single patch.

Elias: They propose making the specification more rigid by mandating typed capability declarations so you can enforce baseline security properties across all agent runtimes automatically.

Nadia: That addresses that initial issue where instructions can easily be interpreted with too much authority because there isn't a clean data-to-instruction boundary to separate them.

Elias: Then they push for version-bound trust grants, which means cryptographically binding the trust relationship to a specific content hash at installation time. That should stop post-installation modification from inheriting old approvals.

Nadia: That tackles that persistence issue we talked about, where a malicious Skill can keep modifying configuration files across different sessions without anyone noticing.

Elias: They also suggest capability-tiered sandboxing, where the isolation level depends on what the Skill explicitly declares it can do. This should confine any malicious scripts based on their declared function instead of having an all-or-nothing restriction.

Nadia: That sounds like a way to preserve utility for legitimate Skills while still restricting any undeclared access, which is a big win for usability and security balance.

Elias: And for the runtime side, they suggest purpose-built behavioral monitoring that watches network activity and flags anything inconsistent with what the Skill actually claimed its purpose was. That should help track data exfiltration better.

Nadia: So it’s about adding mandatory checks to the process, not just hoping authors write good instructions. It shifts the responsibility onto the platform developers to enforce these new rules.

Elias: It’s a step toward making security properties inherent in the architecture instead of something you have to bolt on later as an afterthought.

Nadia: This whole thing sets up some real challenges for future research, like designing consent models that actually work well for non-expert users while still being security-effective.

Elias: And they also flag that ensuring supply chain integrity through just syntactic artifact signing isn't enough to guarantee safety in distribution.

Conclusion: Tom: So we’re wrapping up this look at "Towards Secure Agent Skills: Architecture, Threat Taxonomy, and Security Analysis." It boils down to seeing how structural flaws in the framework create a whole set of predictable attack paths across delivery, runtime, and persistence stages.

Nadia: Exactly. The main point is that you can't just focus on securing the Skill content itself; you have to secure the whole Agent Skills ecosystem because the framework itself has these inherent weaknesses.

Elias: It’s about moving away from a system where trust is persistent and undifferentiated, which is what they identified as a core problem leading to consent abuse.

Priya: From my side, I’m interested in how much of this actually changes for the end user when they are just trying to get their work done with an AI agent.

Nadia: It means users need to start viewing Skill installation like managing a software dependency because you need ongoing monitoring for content changes.

Elias: And for developers, it suggests that building typed capability declarations into the specification is necessary to enforce those baseline security properties across all compliant runtimes.

Priya: It sounds like a lot of extra work to implement before you even get to the actual application layer where things break.

Nadia: It is work, but they show us how this research provides a foundation for actually building those defenses that make broad deployment safe.

Elias: They also flag that while they mapped out these scenarios well, ensuring supply chain integrity through just artifact signing doesn't guarantee safety in the distribution phase.

Priya: I think the future work on usable consent models is where things get interesting for real-world privacy concerns.

Nadia: So, to sum up, "Towards Secure Agent Skills: Architecture, Threat Taxonomy, and Security Analysis" gives us a clear map of structural risks in this framework.

Elias: It shows that the biggest threats aren't just clever prompt injections but the underlying assumptions about trust and boundary definitions.

Priya: And it really highlights that for any new standard in this area, you can’t ignore the measurement part of security—you have to know what the data actually reveals.

Nadia: That’s right. It gives us actionable steps for authors, marketplace operators, and platform developers on how to build something safer from the ground up.

Elias: We’ve seen some interesting work on watermarking and signature schemes before, but this paper provides a specific taxonomy tailored to the unique structure of Agent Skills.

Priya: I think we need more papers that actually test these proposed fixes against real-world attack simulations rather than just looking at the theory.

Nadia: True. It’s interesting how they connected those theoretical categories to concrete incidents like ransomware, which makes it feel much less abstract for us in the field.

Elias: And if we want to get into how this relates to other agent security papers, we could look at SecureClaw or EthCluster next, since that work deals with different parts of the vulnerability spectrum.

Zhiyuan Li, Jingzheng Wu, Xiang Ling, Xing Cui, Tianyue Luo

Institute of Software, Chinese Academy of Sciences · University of Chinese Academy of Sciences

cs.CR, cs.AI

Submitted: 2026-04-03

Updated: 2026-10-14

Code: https://github.com/cisco-ai-defense/skill-scanner

License: http://arxiv.org/licenses/nonexclusive-distrib/1.0/

Importance score: 92/100

The gist: The gist The first comprehensive security analysis of the Agent Skills framework reveals that most severe threats arise from structural properties of the framework itself, including the absence of a

Key concepts

Agent Skills Framework: An open standard defining a modular, filesystem-based way to package domain expertise for LLM agents. It organizes capabilities into separate 'Skills' which bundle instructions (SKILL.md) and optional scripts, allowing agents to acquire specific knowledge on demand without needing deep programming skills.
Threat Taxonomy: A structured classification system used to categorize security risks within the Agent Skills framework. It divides threats into three attack layers—Delivery/Trust Establishment, Runtime Attack, and Persistent/Lateral Impact—and seven main categories, helping researchers understand where vulnerabilities occur.
Data-Instruction Boundary: The lack of a clear separation between the data (the skill content) and the instructions (how the LLM should use that data). This structural flaw allows malicious instructions to potentially manipulate how a Skill processes information, leading to direct runtime attacks like prompt injection.
Single-Approval Persistent Trust Model: A security weakness where trust is granted once for a Skill, persisting indefinitely. The framework lacks mechanisms for continuous verification or granular permission grants. This model makes it difficult to revoke trust or limit the damage if a single skill is compromised.

Terminology

Agent Skills — 126× in this paper
Progressive Disclosure — 10× in this paper · explained in 2 episodes
Verification — 10× in this paper · explained in 2 episodes
Core — 6× in this paper · explained in 2 episodes
Provenance — 6× in this paper · explained in 5 episodes
Model Context Protocol — 5× in this paper
Multi-Agent System — 4× in this paper · explained in 7 episodes
Prompt Injection Attacks — 4× in this paper · explained in 2 episodes
Action Space — 3× in this paper · explained in 1 episode
Actor — 3× in this paper · explained in 3 episodes
Agentic AI — 3× in this paper · explained in 2 episodes
Indirect Prompt Injection — 3× in this paper · explained in 2 episodes
AI Agents — 2× in this paper · explained in 2 episodes
Benchmarking — 2× in this paper · explained in 4 episodes
Model Context Protocol (MCP) — 2× in this paper · explained in 8 episodes
RAG — 2× in this paper · explained in 3 episodes
Robustness — 2× in this paper · explained in 5 episodes
Adversarial Attacks — 1× in this paper · explained in 1 episode
Adversarial Robustness — 1× in this paper · explained in 3 episodes
Agent Memory — 1× in this paper
Benchmark — 1× in this paper · explained in 2 episodes
Fingerprinting — 1× in this paper · explained in 2 episodes
Large Language Models (LLMs) — 1× in this paper · explained in 8 episodes
Transferability — 1× in this paper · explained in 5 episodes

Summary

The gist The first comprehensive security analysis of the Agent Skills framework reveals that most severe threats arise from structural properties of the framework itself, including the absence of a data-instruction boundary, a single-approval persistent trust model, and the lack of mandatory marketplace security review.

Agent Skills Framework Overview

Agent Skills is an emerging open standard that defines a modular, filesystem-based packaging format enabling LLM-based agents to acquire domain-specific expertise on demand<ref:2604.02837#pg2> This framework organizes capabilities as modular, filesystem-based directories, where each Skill bundles a SKILL.md instruction file written in natural language and optional executable scripts<ref:2604.02837#pg6> It achieves remarkable flexibility and composability, allowing Skills to encode arbitrary workflows, domain knowledge, and organizational procedures without requiring programming expertise<ref:2604.02837#pg7>

Structural Security Properties

The analysis reveals that the Agent Skills attack surface spans seven threat categories organized across three attack layers<ref:2604.02837#pg8> The first layer covers how malicious Skills reach users and acquire trusted authority, encompassing supply chain compromise, facilitated by open marketplaces with no mandatory vetting<ref:2604.02837#pg9> The second layer covers direct attacks that an activated Skill can mount, including prompt injection, enabled by the absence of a structural data-to-instruction boundary<ref:2604.02837#pg10> and code execution, exploiting bundled scripts and runtime dependency mechanisms<ref:2604.02837#pg10> The third layer covers how compromise effects extend beyond the current session or agent boundary, through persistence via memory file and configuration poisoning<ref:2604.02837#pg10>

Threat Taxonomy

The threat taxonomy identifies seven categories and seventeen distinct threat scenarios across three attack layers<ref:2604.02837#pg2> Layer 1, Delivery and Trust Establishment, covers supply chain compromise and consent abuse<ref:2604.02837#pg10> Layer 2, Runtime Attack, covers prompt injection, code execution, and data exfiltration<ref:2604.02837#pg10> Layer 3, Persistent and Lateral Impact, covers persistence and multi-agent propagation<ref:2604.02837#pg10> Key scenarios include T1.1 Typosquatting in the Distribution phase<ref:2604.02837#pg10>, T5.1 Credential Harvesting in the Execution phase<ref:2604.02837#pg10>, and T6.1 Memory File Poisoning in the Execution phase<ref:2604.02837#pg10>

Real-World Incident Validation

The taxonomy was validated by analyzing five confirmed security incidents in the Agent Skills ecosystem<ref:2604.02837#pg2> These incidents map cleanly to one or more taxonomy entries, with no observed incident falling outside the taxonomy’s scope<ref:2604.02837#pg10> For example, the MedusaLocker Ransomware Skill maps to T4.1 (Malicious Script) and T2.1 (Consent Gap)<ref:2604.02837#pg10> The ClawHavoc Campaign demonstrates supply chain techniques like Typosquatting and Ranking Manipulation<ref:2604.02837#pg10>

Defense Directions and Open Challenges

Defense directions require addressing vulnerabilities at multiple layers, including the Skill content layer, distribution layer, runtime layer, and trust model layer<ref:2604.02837#pg2> For Consent Abuse (T2), architectural reform to the trust model is necessary<ref:2604.02837#pg10> This includes fine-grained, per-capability permission grants or version-bound trust, though these require changes to the Agent Skills specification<ref:2604.02837#pg10> Open research challenges include Natural Language Instruction Analysis (C1) and designing a consent model that is both security-effective and usable for non-expert users (C2)<ref:2604.02837#pg10> Furthermore, extending the specification to include mandatory capability declarations and dependency pinning would enable baseline security properties across all compliant agent runtimes (C7)<ref:2604.02837#pg10> The paper concludes that prompt injection resists detection without a formal behavioral specification that does not exist, and supply chain integrity cannot be ensured through syntactic artifact signing alone<ref:2604.02837#pg10> The findings provide actionable recommendations for skill authors, marketplace operators, platform developers, and enterprise users<ref:2604.02837#pg10>

Recommendations Summary

For Skill authors, they should treat SKILL.md files with the same security discipline applied to code and document the full set of filesystem and network operations the Skill may perform<ref:2604.02837#pg10> For marketplace operators, mandatory security review pipelines combining static analysis of bundled scripts and semantic analysis of SKILL.md instructions are necessary<ref:2604.02837#pg10> For agent platform developers, they should extend the Agent Skills specification to mandate typed capability declarations and implement version-bound trust grants<ref:2604.02837#pg10> For enterprise users, treating Skill installation as a software dependency management problem with ongoing monitoring for content changes is advised<ref:2604.02837#pg10> The paper provides a foundation for the security research and engineering effort that safe broad deployment will require."> <ref:2604.

Improvements for AI systems

textbfMandatory Capability Declarations in Specification Design: Extend Agent Skills specification to mandate typed capability declarations to enforce security properties across all compliant runtimes, which would enable the ecosystem to enforce baseline security properties across all compliant agent runtimes. This prevents the structural vulnerability where the absence of a data-to-instruction boundary allows instructions to be interpreted with operator-level authority.
textbfVersion-Bound Trust Grants: Implement version-bound trust grants that cryptographically bind the trust relationship to a specific content hash of the Skill at installation time, which would prevent post-installation modification from inheriting the original approval, directly addressing T2.2 Post-Installation Modification. This is a necessary architectural reform to counter the consent gap where the permission scope actually granted is persistent and undifferentiated.
textbfCapability-Tiered Sandboxing: Implement a capability-tiered sandboxing model where isolation levels are determined by the Skill’s declared capability scope, which would preserve utility for legitimate Skills while restricting undeclared access. This addresses T4.1 (Malicious Script) by confining the blast radius of malicious scripts based on their declared function, rather than an all-or-nothing approach.
textbfPurpose-Built Behavioral Monitoring: Deploy purpose-built behavioral monitoring that observes agent network activity and flags transfers inconsistent with the active Skill’s declared purpose, which would make detecting T5 (Data Exfiltration) more tractable by distinguishing exfiltration from legitimate data transfer based on a lack of a formal behavioral specification.
textbfExplicit User Confirmation for Persistence: Require explicit user confirmation for any modification to agent configuration files, such as settings.json, to prevent T6.2 Config Injection and establish a tamper-evident audit trail. This addresses the risk that malicious skills can establish persistent backdoors by modifying configuration files across sessions.