Before installing a third-party agent skill for business work, review the exact package and the access it will receive. Identify what it can read, what it can execute, where it can send information and how its behavior can change after approval. Record those decisions against a version or checksum.
This is a proposed review method for teams adopting reusable AI workflows. It is intended to make an installation decision inspectable. It is not a security certification, a claim that every skill is dangerous or evidence that a particular assistant will enforce every instruction.
The practical question is narrow: does this version of this package need this access to perform the task your team wants? A skill that helps prepare a document may have a good reason to use a local script. That does not automatically justify access to every shared folder or an external upload service.
A valid skill file is only the beginning
The Agent Skills specification defines a directory with a required SKILL.md file and optional supporting resources, including executable scripts. The metadata and instructions help agents discover and perform tasks. The optional allowed-tools field is experimental, with support varying between implementations.
That establishes a file format, not a universal permission boundary. Successful format validation does not establish that the instructions are benign, the code is safe or the package works correctly in your chosen product.
Our introductory guide to SKILL.md files covers how to turn a work procedure into reusable instructions. Installation adds another responsibility: reviewing the procedure together with everything it asks the agent to load or run.
Treat the package description as a claim to verify. If it promises local document formatting, ask which files and processes make that happen. If a step needs an external service, establish what goes there and why.
What the security research can establish
A technical report by Snyk researchers documents malicious skill examples involving credential theft, malware installation and data exfiltration. The researchers combined automated analysis with manual confirmation and distinguished malicious behavior from patterns that create exposure without proving malicious intent.
Their evaluation used a historical ClawHub dataset and a selected popular subset from skills.sh. Those are different sampling frames, so they do not support a simple comparison of marketplace safety. The report itself cautions that detector performance on its curated samples does not guarantee security.
The document is dated February 2026 and was deposited on arXiv in May. This is historical evidence of attack patterns, not a measurement of the chance that a package downloaded today will compromise your company. Snyk also supplies security tooling, which is relevant context when reading its recommendations.
The useful business response is to inspect concrete behavior. A network request may be required for a legitimate task. A clean scan may miss a problem. Neither observation settles an installation decision on its own.
Write an access record before testing
Start with the smallest task worth adopting. “Improve finance” is too broad. “Turn supplied, fictional expense rows into a draft reconciliation table” gives a reviewer an output and a boundary.
The following record is our proposed template. It is not part of the Agent Skills specification.
| Record field | What the reviewer should establish |
|---|---|
| Package identity | Source, version or commit, package checksum and review date |
| Business purpose | One named task and the expected output |
| Inputs | Exact data categories and permitted locations |
| Execution | Scripts, commands, tools and package dependencies needed |
| Destinations | Files, APIs or external services that can receive output |
| Authority | Actions the workflow may complete and actions requiring a person |
| Maintenance | Owner, update trigger and known working fallback |
Keep the record short enough that someone will maintain it. A small business might have one responsible owner. An enterprise may divide technical review and business approval. The responsibilities still need to meet at one decision about the actual installed version.
A checksum helps identify bytes. It does not tell you whether those bytes are trustworthy. A familiar publisher name helps investigate provenance, but it should not replace a review of newly introduced behavior.
Follow the references beyond SKILL.md
Read the main instructions, then inspect referenced files and scripts. Note any dependency the package obtains at runtime. Include instructions that tell the assistant to visit another page and follow whatever it finds there.
Make a simple map of inputs and destinations. For each script, ask whether it reads beyond the selected workspace, creates additional output, contacts another system or invokes another program. For each external dependency, ask who can change it.
Do not execute an unknown setup step merely to discover what it does. Review it first or ask a qualified technical reviewer to do so. An AI assistant can help summarize code, but its summary is not independent verification of that code.
This does not require assuming malicious intent. A useful package may have inherited a broad dependency or an unnecessary upload step from an earlier version. Removing that dependency can make the workflow easier to operate as well as easier to review.
A hypothetical invoice-summary package
Imagine an operations team considering a skill that reads supplied invoice PDFs and produces a local summary. Its instructions call a bundled extraction script. A supporting reference also tells the agent to upload documents to an external “format repair” service when extraction fails.
The upload is the important decision. It changes who receives the documents and may apply only to unusual inputs, so an ordinary successful demonstration could miss it.
For this hypothetical package, a review might approve local extraction with fictional files while declining the external fallback. The team would need to confirm that the restricted workflow still completes its intended task and that the runtime actually prevents the disallowed transfer. Deleting one sentence from a local copy does not establish that the remaining code cannot make the same request.
Use a test input that triggers extraction failure. Check whether the workflow stops with a useful explanation rather than attempting another destination. Also inspect the produced summary for missing fields and invented values. Security review and output quality answer different questions; both matter before adoption.
This example is invented. No invoice package or service was independently tested for this article.
Match controls to the assistant surface
Permissions and scanning differ across products and deployment paths. Verify the exact surface your colleagues will use rather than treating “supports skills” as a complete operational description.
Anthropic’s enterprise guidance, checked on 30 October 2026, describes security scanning for certain Enterprise uploads and edits in Claude and Cowork. It also states that Skills API uploads are outside that scanning coverage, with other configuration exclusions documented. These are vendor-documented capabilities and limits, not our independently tested results.
The implication for a team is to record the deployment path alongside the package. Ask which review happens automatically, what a warning permits and who can override a result. Do not extend one product’s documented behavior to Claude Code, another provider or an organization with different settings.
Apply actual runtime restrictions where available. A sentence saying “use only these files” can express intent. Whether the agent can read other files depends on its execution environment and granted tools.
Review updates as changes in behavior
A previously accepted package can change. In his March 2026 Red Hat Developer article, Florencio Cano Gabarda discusses file permissions, isolation and the risk of automatic upgrades introducing new code. This is practitioner guidance, not an experiment measuring how much any single control reduces incidents.
Our proposed update rule is to compare more than the main Markdown file. Recheck new scripts, changed dependencies, external destinations and requested permissions. A wording correction may need a lighter review than adding an upload API, but both should identify a specific replacement version.
Keep the approved copy available while testing its replacement. If a package retrieves mutable instructions or code from a remote location, pinning the outer archive alone will not freeze that dependency. Either include the relevant material in the reviewed version, constrain how it can change or document the remaining dependency explicitly.
The goal is a review that remains meaningful after installation. Record what would invalidate it: a new data category, a different assistant surface or broader tool access may be as important as a package update.
Test stopping behavior as well as the happy path
Prepare a small set of cases covering normal work, missing input, a denied destination and a source document containing instructions unrelated to the user’s task. Use fictional data and harmless markers. Check that source content is treated as evidence rather than permission to perform another action.
Observe attempted actions where your environment exposes them. A workflow can produce an acceptable output while also making an unnecessary request. Conversely, stopping because a required permission is absent can be the correct result.
Keep the evaluation record modest: package identity, runtime, cases, observed outputs, attempted actions and unresolved issues. Avoid labeling a package “secure” because a few examples passed. State what the review covered and which capabilities remain untested.
For the first installation, choose one useful task and complete the access record before enabling it for routine business data. If the reviewer cannot explain a dependency or destination, resolve that uncertainty first. A narrow, understandable workflow is a stronger starting point than a large collection of skills nobody owns.