AI Agents

Agent Skills Moves to AAIF: What Operators Should Change

Agent Skills now has a vendor-neutral home, but portability is not a security boundary. Use this adoption and review checklist before running a skill.

WealthLab

— 5 min read
Share
Diagram of portable agent skills moving through governance, review, isolation, and controlled deployment

Quick answer: Anthropic donated the Agent Skills standard to the Agentic AI Foundation (AAIF) under the Linux Foundation on October 22, 2026. The transfer gives the format a vendor-neutral governance home and includes the Agent Skills name, logo, GitHub organization, and domain. It does not make downloaded skills safe by default, guarantee identical behavior across agents, or replace review, sandboxing, least privilege, and version pinning.

This is source-based operator analysis, not a hands-on security test. WealthLab reviewed the Anthropic and Linux Foundation announcements, the current Agent Skills specification and repository, and independent commentary from Simon Willison. No third-party skill was installed or executed for this article.

What changed on October 22

Agent Skills is a lightweight directory format centered on a required SKILL.md file. A package can also contain executable scripts, references, assets, and other files. The standard began at Anthropic and is now an AAIF project under Linux Foundation governance.

Anthropic says the donation covers the project identity and public infrastructure, while engineers from Anthropic, Google, OpenAI, and other companies will maintain it as individuals. The Linux Foundation separately confirmed Agent Skills as one of four newly contributed AAIF projects. Anthropic proposed versioned releases, a formal proposal process, and security guidance as next steps. “Proposed” matters: operators should not describe those future controls as already delivered.

Anthropic also reports more than 70 platform integrations, one million published skills, and nearly 280 million installations. Those are vendor-reported adoption figures; WealthLab found no independent audit of the counts and does not use them as proof of safety or interoperability.

What did not change

  • A format is not a permission system. The specification defines packaging and metadata. It does not itself isolate a process, restrict filesystem or network access, or approve a command.
  • Portability is not behavioral equivalence. Clients decide how they discover, load, interpret, and execute skills. The specification labels allowed-tools experimental and says support may vary.
  • Neutral governance is not package vetting. A standards body can improve stewardship and change control without reviewing every repository that claims compatibility.
  • Markdown can carry operational risk. A skill body contains instructions, while optional directories may contain executable code and supporting data. Review both prose and files.
  • Popularity is not provenance. Install counts, stars, familiar naming, or compatibility badges do not establish who produced the package or what changed since review.

Operator impact: treat skills as a supply chain

The practical gain is a more stable shared format that can reduce duplicated workflow packaging across compatible agents. The practical risk is that portability can also make an unsafe instruction or script easier to distribute. Organizations should apply software-supply-chain controls to the whole skill directory, then apply agent-specific controls at runtime.

The smallest useful trust record links a skill to its source repository, immutable commit or release, license, reviewer, approved agent/runtime, required tools, network destinations, sensitive paths, last review date, and rollback procedure. Keep that record outside the skill package so a package update cannot rewrite its own approval history.

Adoption and security checklist

  1. Pin the source. Fetch from the project or publisher you intended, record the repository and immutable commit or signed release, and archive the reviewed package hash. Do not execute a mutable branch blindly.
  2. Inventory the complete directory. Review SKILL.md, scripts, binaries, symlinks, references, templates, and hidden files. A harmless-looking frontmatter block does not summarize every behavior.
  3. Map requested capability to real runtime access. List shell commands, interpreters, package managers, filesystem paths, credentials, APIs, network hosts, browser sessions, and write operations the agent can actually reach.
  4. Start with deny-by-default tools and credentials. Expose only the tools and narrowly scoped credentials needed for the task. Treat the experimental allowed-tools field as metadata interpreted by a client, not as a universal security boundary.
  5. Separate instructions from untrusted data. Web pages, documents, issue text, and retrieved files can contain hostile instructions. The runtime should not let source content redefine the skill, elevate permissions, or authorize side effects.
  6. Validate in an isolated environment. Use synthetic data, disposable storage, constrained network access, and no production secrets. Same-user directories or a different working folder are not a security sandbox.
  7. Test negative cases. Confirm the workflow refuses out-of-scope writes, unexpected destinations, missing approvals, malformed inputs, and attempts by retrieved content to alter instructions.
  8. Promote by exact version. Record what passed review, deploy that artifact, monitor tool calls and network access, and require a fresh review when executable files, instructions, dependencies, or permissions change.
  9. Keep a kill switch and rollback. Operators need a fast way to disable the skill, revoke its credentials, remove cached copies, and restore the prior known-good version.

Fit and non-fit cases

Good fit: repeatable internal workflows where the organization owns or reviews the skill, can constrain the runtime, and benefits from sharing procedures across compatible agent clients.

Use extra controls: workflows that access production infrastructure, source-control write tokens, customer data, payment systems, browser sessions, or administrative APIs. These need explicit approvals, short-lived credentials, audit logs, and environment isolation beyond the file format.

Non-fit without redesign: downloading arbitrary community skills directly into a privileged agent; allowing a skill to install unpinned dependencies at runtime; or assuming a declared tool list prevents access that the host agent already exposes.

Migration guidance for existing skill collections

  1. Do not mass-convert or republish packages just because governance changed. Inventory first.
  2. Validate current frontmatter and directory naming with the reference validator, but treat a passing format check as syntax evidence only.
  3. Pin each production skill to a reviewed revision and identify any loader that tracks a mutable branch.
  4. Compare actual runtime tools with each skill's documented requirements; remove ambient access that has no task-level justification.
  5. Stage updates with synthetic inputs, inspect diffs, test rollback, and promote one revision at a time.
  6. Track the AAIF roadmap for versioned releases, proposals, and security guidance. Reassess controls when published artifacts—not announcements—change.

Evidence boundary and sources

Sources checked October 27, 2026. Anthropic is authoritative for what it donated and for its own adoption figures. The Linux Foundation independently confirms project acceptance and AAIF governance. The specification is authoritative for the current package format and its experimental tool metadata. Simon Willison's commentary corroborates the timing and places the move in the earlier open-standard discussion; it is not evidence for the vendor's adoption counts.

No hands-on skill installation, cross-client compatibility test, or sandbox escape test was performed. Runtime behavior depends on the agent, its tool implementation, host permissions, credentials, and the exact skill revision. This article contains no affiliate links.

Read more