Agent Skills Join the Linux Foundation: How to Vet and Pin Them
Anthropic donated the Agent Skills standard to the Agentic AI Foundation on October 22. With a million skills published, here is how to treat them like any other dependency.
On this page 8 sections
Agent Skills are folders with a SKILL.md file that teach an AI agent a task, and they are now governed by the Linux Foundation. Treat every third-party skill like a dependency. Read its files, pin it to a specific version, keep it in your repository, and limit what the agent running it can reach.
On October 22, 2026, Anthropic announced it is donating the Agent Skills standard to the Agentic AI Foundation, a Linux Foundation project. According to Anthropic's announcement, more than 70 agent platforms have integrated the standard, about 1 million skills have been published, and nearly 280 million have been installed.
This guide is for engineers and security leads whose teams now install skills the way they once installed packages. It covers what changed, why it matters for supply chain risk, and a short routine for vetting and pinning skills. Backtrace covers the habits that keep delivery pipelines safe, and skills are now part of that pipeline.
What changed on October 22
Anthropic donated the Agent Skills name, logo, GitHub organization and the agentskills.io domain to the foundation. The foundation operates under the Linux Foundation. Anthropic co-founded it with Block and OpenAI, and the Model Context Protocol (MCP), another agent standard, already lives there.
Engineers from Anthropic, Google, OpenAI and other companies will maintain the standard as individuals. David Soria Parra and Mahesh Murag are the lead maintainers. Anyone can use or contribute without joining the foundation.
Anthropic says it will keep the standard open, community-driven and vendor-neutral. The proposed roadmap includes versioned releases, a formal proposal process and security guidance for people who write and install skills. Developer Simon Willison noted on his blog that he had predicted such a move when skills were first called an open standard, in a link post on the donation.
Neutral governance is good for compatibility. It does not review the contents of any individual skill.
Why skills belong in your dependency policy
A skill is instructions plus, sometimes, code. An agent reads the instructions and may run the scripts with whatever access you gave it. That puts a skill in the same risk class as a package, a GitHub Action or a shell script you download.
The scale matters here. With about a million published skills, most teams will never read more than a few. The mix will include careful work, abandoned work and a few bad ideas. That is true of every package registry we have ever used.
We have a good playbook for this problem already. Our explainer on how software supply chain attacks work shows the common pattern: trust gets extended to a name, then abused when the content behind the name changes. A skill pulled from a remote source can change in the same way.
There is also a human angle. Skills are plain text, so they feel harmless. A reviewer who would scrutinize a build script may skim a markdown file. That habit needs to change.
How do you vet an agent skill before installing it?
To vet a skill, read every file in the folder, check who maintains it, and note what it asks the agent to do. Look for scripts, network calls, file writes outside the project and instructions that tell the agent to ignore your own rules. If you cannot explain a line, do not install it.
Use this checklist on each new skill:
- Read SKILL.md from top to bottom, including any instructions about tools or permissions.
- Open every script and reference file in the folder, not only the main one.
- Check the maintainer's history, other projects and how they respond to issues.
- Search the files for network calls, shell commands that download and run code, and references to credentials.
- Try the skill in a throwaway project with no secrets before using it on real code.
Step five is the one teams skip. A sandbox costs ten minutes and shows you what the agent actually does when it follows the skill.
Backtrace's editors suggest keeping a short note beside each approved skill. Record who reviewed it, on what date, and what it is allowed to do. That record is useful when something goes wrong.
A worked example of a skill review
Imagine a skill that promises to generate release notes. The folder holds a SKILL.md file, a template and one script. Start with the markdown. It should describe the task in plain terms and name the tools the agent may use.
Then open the script. A release-notes helper should read commit messages and write a text file. If the script also reaches out to a remote server, sends repository contents somewhere, or runs a downloaded file, stop and ask why. The answer may be innocent, but you should know it before an agent runs it.
Finally, run it in a scratch repository with a few fake commits. Check the output, and check what else changed on disk. If the skill behaves the way its description says, record the review and move it into your approved folder. If it does anything surprising, the review has already paid for itself.
How to pin and store skills
Pinning means locking a skill to a specific version so it cannot change under you. If the skill lives in a Git repository, pin to a commit hash and not a branch name. A branch moves. A hash does not.
For skills that matter, copy them into your own repository. Then they get the same treatment as the rest of your code: pull requests, review, history and an owner. A change to a skill shows up as a diff that a person has to approve.
A simple layout works well:
- A single folder in the repository for approved skills, one subfolder per skill.
- A code owners file that assigns review of that folder to a named team.
- A short README listing each skill's source, pinned version and review date.
- A scheduled reminder to review updates, quarterly or sooner for high-use skills.
This also helps with consistency. When every engineer's agent loads the same reviewed skills, results are easier to compare and failures are easier to trace.
If you already guard your pipeline against unreviewed workflow changes, apply the same ideas here. Our guide to checking repositories for the GhostAction workflow shows how to audit automation files that can reach your secrets.
Limit what the agent can do
Even a reviewed skill should run with the least access that gets the job done. Give agents read-only access by default, scope tokens to one repository, and keep production credentials out of reach entirely.
Here is a short permission baseline:
- Run agents in a container or a disposable environment for any untrusted skill.
- Do not expose long-lived secrets to the agent's environment.
- Require human approval for commands that delete data, push code or call external services.
- Log the commands an agent runs, so you can review them later.
Secrets deserve special care. If an agent can read an environment file, a skill can ask it to print the contents. Scanning for exposed credentials is cheap insurance, and our comparison of secrets scanning tools can help you pick one.
Pair this with careful code review. Agents sometimes write code that looks right and is not. Our checklist on what to check in AI code review covers the common failures.
Teams with several repositories should centralize this work. One shared, reviewed skills repository, consumed by the others at a pinned commit, avoids ten slightly different copies and ten separate review habits.
What to watch as the standard matures
The roadmap mentions versioned releases and security guidance. Both are worth tracking. Versioned releases make pinning easier, and official guidance gives you a baseline to audit against.
Until then, rely on your own process. Standards bodies set formats. They do not promise that every file written to the format is safe, and the foundation has not said otherwise.
One counterpoint is fair. Skills are easier to read than compiled packages, so a careful review is often quick. A short SKILL.md with no scripts carries much less risk than a large dependency tree. Match the effort to the content, and spend your time on skills that include code or broad permissions.
Conclusion
The donation gives Agent Skills a neutral home, and it will probably speed up adoption. It does not change the basic rule for anything an agent installs. Read it, pin it, store it in your repository and limit what it can touch.
Start this week with an inventory. List every skill your team uses today, find where each one came from, and bring the important ones under review. That single list will tell you how big the job really is.
