AI Agent Skills Are Becoming a Software Supply Chain
AI agents become more useful when they can load reusable instructions, tools, connectors, workflows, and domain knowledge. These packages are often described as skills.
A skill can teach an agent how to complete a repeated task, define which tools to use, specify an output format, or provide scripts and supporting files. This makes skills valuable for turning a general model into a specialized working system.
It also introduces a new security problem.
Quick Answer: Agent skills are becoming installable capability packages that can influence tools, files, credentials, and system behavior. This creates a software-supply-chain problem: users must know who published a skill, what it instructs the agent to do, which permissions it requires, and whether it contains malicious or unsafe behavior before installation.
Why should an AI skill be treated like software?
A skill may look like a Markdown file or a collection of prompts, but its effect can extend far beyond text generation.
Depending on the host agent, a skill may influence:
- Which commands the agent runs.
- Which files it reads or writes.
- Which external websites it visits.
- Which credentials it requests.
- Which packages or scripts it installs.
- Which data it sends to external services.
- How it handles approvals.
- Which safety instructions it attempts to override.
A malicious instruction can be just as consequential as malicious code when the agent has access to powerful tools.
This means the security boundary is not the file extension. It is the capability the package gains after installation.
What does recent research show?
A May 2026 technical report analyzed 3,984 AI agent skills from major marketplaces. The researchers reported 76 confirmed malicious payloads and found that 13.4 percent of the analyzed skills contained at least one critical-level security issue.
The malicious patterns included credential theft, backdoor installation, and data exfiltration.
These findings should not be interpreted as proof that every skill marketplace is unsafe. They show that the ecosystem has reached a scale where open publishing without security analysis creates real risk.
The report’s central implication is important: automated and manual security review are no longer optional when skills can access credentials, local systems, or business data.
How can a skill attack an agent environment?
A harmful skill can use several techniques.
Hidden or misleading instructions
The skill may present itself as a productivity tool while instructing the agent to read sensitive files, request secrets, or send data elsewhere.
Unsafe scripts and dependencies
A package may include executable code, shell commands, installation steps, or dependencies that create persistence or expose the system.
Credential requests
A skill may tell users to paste API keys, tokens, cookies, passwords, or private certificates into a prompt or configuration file.
Excessive permissions
A harmless-looking workflow may request broad filesystem, email, browser, database, or cloud access that is not necessary for the stated task.
Prompt injection and instruction override
A skill can attempt to weaken the host system’s safety rules, conceal actions, or prioritize external content over trusted instructions.
Data exfiltration
The package may direct the agent to upload files, logs, environment variables, conversation history, or user data to an outside endpoint.
What should users check before installing a skill?
Users should apply a basic installation review.
| Question | Safer signal |
|---|---|
| Who published it? | Identifiable publisher with history and contact information |
| What files are included? | Small, understandable package with documented purpose |
| Does it include executable code? | Code is visible, justified, and independently reviewed |
| What permissions are requested? | Least privilege tied directly to the task |
| Does it ask for secrets? | Uses placeholders and secure credential mechanisms |
| Does it contact external services? | Endpoints and data flows are disclosed |
| Can actions be reviewed? | Important steps require confirmation |
| Is the version fixed? | Version history and changes are visible |
| Can it be removed safely? | No hidden persistence or undeclared changes |
| Has it been tested? | Security and behavior checks are documented |
A user should not install a skill simply because the description sounds useful or the rating is high.
What responsibilities do skill marketplaces have?
A responsible marketplace should treat curation as a security function.
Important controls include:
- Publisher verification.
- Manual review before publication.
- Static scanning of code and instructions.
- Detection of secrets and suspicious endpoints.
- Permission declarations.
- File inventories and checksums.
- Version history.
- Clear update notifications.
- User reporting and rapid removal.
- Security advisories for affected versions.
Marketplaces should also distinguish between a skill that only provides instructions and one that includes executable code, connectors, or installation scripts. These packages should not receive the same trust level.
Ratings and download counts are not substitutes for review. They can be manipulated and may encourage users to install popular but unsafe packages.
Why does trusted curation matter?
Open ecosystems create variety, but unrestricted uploads create a review burden that most users cannot handle.
A curated library can reduce risk by limiting who can publish, reviewing files manually, preserving canonical versions, and documenting compatibility and safety notes. This does not guarantee that every package is perfect, but it creates accountability and a controlled correction process.
For professional users, provenance is part of product quality.
A skill should answer:
- Who created this?
- What is the intended behavior?
- What files are included?
- Which tools does it use?
- Which data does it access?
- What is explicitly prohibited?
- How was it reviewed?
- What changed in this version?
This information makes trust inspectable rather than purely reputational.
How should organizations govern internal skills?
Internal skill creation can spread rapidly because employees can produce useful workflows without waiting for a central engineering team.
That speed is valuable, but organizations need an internal registry.
Each skill should have:
- A named owner.
- A business purpose.
- A version.
- Approved tools and data.
- Required permissions.
- An evaluation set.
- Review and expiration dates.
- Incident and removal procedures.
- Logs of consequential actions.
High-risk skills should be separated from low-risk instruction templates. A writing-format skill should not go through the same approval as a skill that can execute code, send email, or access customer records.
What is the future of skill security?
Skill ecosystems are likely to evolve toward signed packages, permission manifests, automated scanning, sandboxed execution, reputation based on verified behavior, and organization-level policy controls.
Security will also become more continuous. A skill that was safe at publication may become risky after a dependency, endpoint, model, or host tool changes.
The important trend is that AI customization is becoming operational infrastructure. Skills are no longer only clever prompts. They are part of the software supply chain around agents.
Related PiSkill Resources
Explore the Application Security Threat Modeler, Secrets Management and Key Rotation Designer, Data Access and Least Privilege Reviewer, Human in the Loop Agent Control Architect, and AI Visual Rights and Brand Safety Reviewer skills.
Sources
- Technical Report: Exploring the Emerging Threats of the Agent Skill Ecosystem
- The 2025 AI Agent Index: Technical and Safety Features of Deployed Agentic Systems
- Stanford Artificial Intelligence Index Report 2026