An admission gate for third-party agent skills

Agent skills can look like documentation while behaving more like dependencies. One August study describes them as dynamically loaded instruction-and-script folders that widen an agent’s attack surface. In a controlled experiment involving 2,826 adversarial skills and 5,629 completed runs with Gemini CLI and Qwen Code, the authors reported high exploitation rates; that result describes their experimental setup, not the incidence of exploitation in production systems. Read the malicious-skill risk study.

A separate August dataset study reports collecting 3,797,117 SKILL.md files from 282,200 public GitHub repositories in July 2026. Its authors characterize skills as mostly natural-language artifacts, selected probabilistically at runtime, without compiler or type-checker verification, and commonly distributed by copying rather than through a central registry or package manager. Read the GitSkills dataset study.

Together, these studies expose an operating tension. Repository-scale distribution can put skills within easy reach, while their instructions and scripts may enter execution without the controls engineers expect around conventional packages. The studies do not establish how often public skills are malicious, nor do they demonstrate that every skill format executes scripts. They do give platform teams a concrete reason to treat skill admission as a security boundary.

Put an admission record in front of execution

Our proposed control is a signed admission record for each accepted skill version. This is an SGL operating prescription derived from the risks above, not a framework evaluated by either study.

The record can answer six questions before a skill receives tools, credentials, or workspace access:

1. Where did this version come from? Record the source repository, resolved revision, retrieval time, declared publisher, and reviewer. A repository name or author field alone is not proof of identity, so the record can distinguish a claimed publisher from a verified source.

2. What exact content was reviewed? Hash the complete skill bundle, including instructions, scripts, configuration, templates, and referenced local assets. Admission then attaches to immutable bytes rather than a branch name or mutable download URL.

3. What can the bundle execute? Inspect scripts and command-bearing configuration before activation. Flag subprocess creation, network calls, package installation, dynamic evaluation, credential access, persistence, and writes outside an assigned workspace. Natural-language instructions also belong in this review because they can influence runtime tool selection even when no script is present.

4. Which capabilities will it receive? Compare requested access with the narrow task the skill performs. Record filesystem scope, network destinations, tools, secrets, approval gates, and any ability to invoke another agent. A skill accepted for read-only repository analysis does not automatically earn shell writes or deployment credentials.

5. Where will the first execution occur? Run the admitted hash in an isolated environment with synthetic inputs and non-production credentials. Capture attempted file access, network destinations, spawned processes, tool calls, and changes to the environment. A clean test is evidence about that test configuration, not proof that every future input is safe.

6. How can the version be disabled? Assign an owner, review expiry, and revocation identifier. The runtime can deny a revoked hash even if a copied bundle remains on disk. Preserve enough execution metadata to identify which workloads used the affected version.

Make updates new admission events

Copy-based distribution creates a versioning problem: two folders with the same name may contain different bytes, while one folder may change without an obvious package release. The GitSkills authors explicitly describe distribution by copying and the absence of a central registry or package manager. Read the reported distribution characteristics.

Our judgment is that any content change should invalidate the prior admission record. The platform can calculate a new bundle hash, show the reviewer a semantic diff, repeat script and permission checks, and rerun isolation tests proportional to the change. Pinning the admitted hash at runtime prevents an approved name from silently resolving to unreviewed content.

This process also separates three decisions that are easy to collapse:

• Cataloged means the platform knows the skill exists.
• Admitted means a specific content hash passed a defined review for a defined environment.
• Enabled means a workload may invoke that admitted version with an explicit capability set.

That distinction supports gradual rollout. A version can remain cataloged while its admission is revoked, or remain admitted while disabled for sensitive workloads.

Test the boundary, not the description

A skill description states intent. Admission testing examines reachable behavior. For a practical negative-test set, present the skill with instructions or files that attempt to trigger secret reads, unapproved network access, writes outside the workspace, hidden subprocesses, or privilege expansion. Confirm that the runtime denies the action and records the denial.

The malicious-skill study evaluated adversarial skills across two coding-agent systems and reported high exploitation rates within its controlled setup. Read the experimental scope. It does not establish that the same rate transfers to another model, host, permission design, or production workload. Platform teams can therefore use the result as a reason to test their own boundary, while measuring their own configurations rather than importing the study’s outcome as a forecast.

The compact gate

Before enabling a third-party skill, the admission decision can require one review packet containing:

• verified source and resolved revision;
• hash of the complete bundle;
• instruction, script, and configuration diff;
• requested and granted capabilities;
• isolated-execution results;
• named owner and expiry;
• rollout scope and monitoring signals;
• revocation identifier and disable procedure.

The deeper shift is conceptual: reusable text becomes a software dependency when an agent can interpret it, execute accompanying code, or use it to direct privileged tools. Teams building agent platforms can place this gate alongside the other runtime boundaries in their build process, then admit exact versions instead of trusting familiar folder names.