Anthropic gave Agent Skills a neutral home. Openness now needs a security ledger

THE SIGNAL IN ONE SENTENCE

Anthropic is giving Agent Skills a neutral home. That is good news for an idea that should not belong to one model company forever. It is also the moment to stop treating a skill like a clever prompt in a folder. On October 22, Anthropic said it would donate the Agent Skills standard to the Agentic AI Foundation, a Linux Foundation project. The donation includes the Agent Skills name and logo, its GitHub organization and the agentskills.io domain. Anthropic says people will be able to use and contribute to the standard without joining the foundation. Engineers from Anthropic, Google, OpenAI and other companies are expected to maintain the project as individuals. The proposed first roadmap includes versioned releases, a formal proposal process and security guidance for people who write and install skills. That is the governance announcement. The technical object is wonderfully plain. A skill is a folder with a required SKILL.md file. The file contains metadata and instructions telling an agent how to perform a task. The folder can also include reference material, templates, data and executable scripts. In other words, a skill can be documentation, software or both. The current specification requires only a name and description. License, compatibility notes and metadata are optional. An experimental allowed-tools field can list tools that are pre-approved, but the specification warns that support may vary by agent implementation. A scripts directory may hold Python, Bash, JavaScript or whatever the client supports. This simplicity helps the format travel. It also creates a security problem that can travel with it. The plain signal is that every installed skill needs a security ledger. The ledger should answer a short list of questions before an agent reads the instructions or runs a file: who made this, which exact version is here, what changed, what can it access, what can it alter, where can it connect, how was it tested and how can it be revoked? Without that record, openness can become a faster route for ambiguity. Anthropic says more than 70 agent platforms have integrated the format since it was published as an open standard in December 2025. The company also reports one million skills published and nearly 280 million installations. Those are Anthropic's figures, not an independently audited ecosystem census, but even a fraction of that scale makes package hygiene urgent. A neutral home matters because a standard is more useful when rivals can implement it without asking one vendor for permission. Public proposals and versioned releases can reduce surprise. Maintainers from several organizations can surface assumptions that a single product team might miss. A foundation can preserve the format even if one company changes priorities. Neutral stewardship, though, is not the same thing as safe execution. The foundation can define how a folder is shaped. Each agent still decides when to activate the skill, which files to read, whether to run scripts, which tools exist, what permissions those tools carry and how results reach the outside world. The same folder can therefore be harmless in one client and dangerously capable in another. Compatibility needs to include behavior, not merely syntax. Imagine a calendar skill that works in three agents. One asks before creating an event. One creates the event and then announces it. One has access to a company calendar, contact directory and email account at the same time. The folder is portable. The consequence is not. The security ledger should begin with identity and provenance. Record the publisher, maintainer, source repository, license and release date. Pin the installed folder to a cryptographic hash so a reviewer can tell whether the bytes changed. Sign releases when possible. Preserve the original package and the verification result. A familiar name is not proof that the folder came from the familiar maintainer. Then record the contents. List the main instructions, scripts, binaries, reference files, templates and dependencies. Mark files that arrived after installation. If a script downloads another script, the downloaded code belongs in the security review too. The important program is the complete chain that executes, not the tidy folder that passed the first inspection. Now declare permissions as data. Can the skill read local files? Which directories? Can it write or delete? Can it run shell commands? Can it reach the network? Which destinations? Can it use credentials, connectors, a browser, email, messaging, source control, payments or production infrastructure? Can it send user data outside the current system? An optional prose note saying internet access is required is not enough for a capable agent. Clients need machine-readable scopes they can enforce. A PDF formatting skill may need to read one document, write one output file and call no network service. A deployment skill may need source control and hosting access but should not automatically gain email or payroll permissions just because those tools happen to be available in the same workspace. Least privilege sounds boring until the agent meets an instruction it should not obey. Run unfamiliar skills in a sandbox by default. Block network access unless destinations are declared and approved. Mount only the files needed for the task. Keep secrets out of the process unless the job cannot proceed without them. Require a person before irreversible deletion, external publication, money movement or a message sent in the user's name. The ledger should show every exception. Next comes activation. Agent Skills uses progressive disclosure. Clients load names and descriptions for discovery, read the full SKILL.md when a task matches and then access resources or execute code as needed. That saves context, but it also means activation is a trust boundary. A malicious or simply overbroad description can try to become relevant to tasks it should not touch. A skill body can contain instructions that conflict with the user or the agent's governing rules. Reference files can hide additional instructions. An asset can be treated as data by one client and executable content by another. So the ledger needs an activation record: which task caused the match, which version was loaded, what resources were opened, what code ran, what tools were requested, what permissions were granted and what result reached the user or an outside system. That is not surveillance for its own sake. It is how an operator reconstructs an incident. Versioning is the next trap. A package can be safe on Tuesday and compromised on Friday. Automatic updates improve maintenance but expand the blast radius of a bad release. Frozen versions improve reproducibility but leave known vulnerabilities in place. Use an update policy that can explain itself. Pin production workflows to reviewed versions. Show the diff before installing an update. Re-run tests when instructions, scripts, dependencies or permission requests change. Separate a format version from a package version. Keep a path to roll back. If a maintainer account or repository is compromised, clients need a way to stop a release even when its version number looks newer and shinier. That means revocation cannot be a footnote. The ecosystem needs a public process for reporting a dangerous skill or release, attaching evidence, alerting clients and marking the affected version as revoked. Clients should be able to quarantine it, identify where it was installed and show which tasks ran before the alert. A replacement release does not erase the need to understand what the old one did. Registries deserve separate scrutiny from the specification. An open folder format does not automatically provide a trustworthy marketplace. A registry operator decides how publishers are verified, whether names can be confused, how rankings work, what malware scanning occurs, how complaints are handled and whether paid placement affects discovery. The standard should make security metadata portable so users do not lose the ledger when they switch registries or clients. Cross-platform testing should focus on consequences. Take one skill, one task and one controlled fixture. Run it in each supported client. Compare activation, tool requests, file access, network calls, prompts for approval, output and cleanup. A green check for valid YAML only proves that the folder is shaped correctly. It says nothing about whether three agents interpret the instructions safely or consistently. Publish those compatibility results by client version. Organizations installing internal skills need the same discipline. A folder written by a colleague can still contain stale instructions, excessive permissions or a script copied from somewhere else. Internal does not mean reviewed. Trusted does not mean permanent. Give each skill an owner, an expiry date and a test suite. Remove the skill when nobody owns it anymore. Skill authors can help by keeping code small, dependencies pinned and side effects explicit. Put permission needs in a machine-readable manifest. Provide a dry-run mode. Include test fixtures. Explain failure states. Never hide a network call inside a helper script because it seemed convenient at the time. Client developers have the harder job. They must enforce scopes even when the skill asks nicely, preserve the user's higher-priority instructions, isolate code, display consequential actions and produce logs ordinary operators can understand. Foundation maintainers can make those expectations portable. Define a security manifest, signed release metadata, a compatibility test suite, an incident vocabulary and a revocation feed. Keep the process public. Invite implementers, skill authors, security researchers and users who have to clean up the mess when theory meets production. Anthropic's donation is a useful move because agent capability should be portable and inspectable. The format's simplicity lowers the cost of sharing real procedural knowledge instead of stuffing every workflow into one giant system prompt. The next phase should preserve that simplicity without pretending a folder is inert. Open standards create shared roads. The security ledger supplies the vehicle inspection, cargo manifest and recall notice. Agents will need all four before portable skills can become dependable infrastructure rather than the software supply chain wearing a friendlier jacket.