Agent Skills Security Audit: SKILL.md, Scripts and Permissions

An agent skill can influence tool choices, file access and commands even when its entry point is a Markdown file. An agent skills security audit should examine the whole package and the authority it asks the host to use. Reading the description alone does not establish what installation or execution will do.

This guide provides an installation-review and update-review method. The examples reference Penligent’s original open-source AIPentest_Skills repository. Source inspection is not a runtime security audit, and neither an open-source license nor a familiar publisher proves that every use is safe.

Record the exact package under review

Capture the repository owner, source URL, commit identifier, selected skill directory and installation method. Review a fixed revision. A moving branch can change between approval and installation, and a package with the same display name can come from another publisher.

For this article, the inspected repository revision is ac8f54233830fdd428f9924b3d77b842b7d80119, checked November 11, 2026. Its README describes a collection of reusable penetration-testing skills. The examples below are based on specific source files at that revision; they do not imply that every file or host integration was audited.

Read SKILL.md as requested behavior

Separate the skill’s description from its operational instructions. Identify requested network destinations, filesystem paths, tool calls, privilege assumptions, credential use and conditions for continuing or stopping. Follow each referenced local file during review, but do not execute it simply because the instructions say it is necessary.

The pinned scope-and-rules-of-engagement skill asks the operator to record authorized targets, accounts, methods, time windows and stop conditions. It explicitly distinguishes asset discovery from authorization. That is a useful instruction-level control to inspect; enforcement still depends on the host and workflow that use the skill.

Inventory executable and transitive content

List scripts, binaries, dependency manifests, installation hooks, configuration, linked downloads and nested packages. A review of one Markdown file does not cover a shell helper it invokes or a package manager hook installed by that helper. Record whether a reference is local, pinned externally or fetched from a mutable location.

Use a read-only inventory before any execution

In an already obtained local checkout, the following commands list files and inspect changes without running skill code or installing dependencies. Set the directory to your reviewed checkout. Treat Git status, missing history and untracked files as part of the review.

cd /path/to/reviewed/AIPentest_Skills
git rev-parse HEAD
git status --short
git ls-files
git diff --stat APPROVED_COMMIT CANDIDATE_COMMIT
git diff APPROVED_COMMIT CANDIDATE_COMMIT -- SELECTED_SKILL_DIRECTORY

The uppercase values are placeholders, not commands to copy unchanged. If the candidate is an archive without Git history, retain its origin and digest and compare extracted files with the approved package using your normal review tooling. A file inventory is evidence of what was reviewed, not a malware verdict.

Review permissions independently from instructions

Write a capability contract for the host: allowed directories, network destinations, tools, account roles and duration. A skill that promises to stay within scope should still run under controls that enforce that scope. Prefer a dedicated staging identity and synthetic fixtures when validating behavior.

OWASP’s AI Agent Security Cheat Sheet treats tool least privilege, memory, human approval and supply-chain risk as distinct controls. For a skill package, that means a static review of text should be paired with a review of what the agent host actually allows. A powerful shell or broad cloud credential can expand the consequences of an otherwise small instruction error.

Keep evidence collection from becoming another leak

The repository’s evidence-handling workflow calls for minimal, redacted, traceable evidence. Apply the same discipline when reviewing skills: never paste production credentials into a model transcript or attach unredacted customer records to an audit issue. Record the presence and handling of a secret, with a safe identifier, rather than copying its value.

Inspect output paths and retention behavior. Determine whether prompts, tool output, debug logs or generated reports leave the environment. If a package requires an external service, record the destination and data classes explicitly. An audit cannot claim that nothing is transmitted when the relevant script or service configuration was outside scope.

Validate only after the static review defines a bounded plan

If execution is needed, use an isolated staging environment with disposable files, no production credentials and restricted egress. Define the expected filesystem and network behavior first. Observe the actual actions and compare them with the reviewed contract. Do not let instructions embedded in the candidate package authorize additional permissions during its own evaluation.

Use four outcomes: accepted for the stated environment, rejected with a concrete finding, inconclusive because required evidence is missing, and not tested. A lack of execution evidence must remain visible. This article’s source examples have not been executed as part of a sandbox test.

Make an update reopen the right review

A documentation-only update and a new dependency or network destination need different scrutiny. Compare the candidate with the approved revision, then revisit the affected permissions and behavior. Re-pin the selected revision after review. A digest establishes artifact identity; it does not establish that the code is trustworthy.

Package: publisher / repository / skill directory
Candidate revision: exact commit or archive digest
Baseline revision: previously accepted revision
Referenced files inspected: explicit list
Requested capabilities: filesystem, network, tools, identity
Runtime validation: not tested / scoped result
Open findings: owner and required evidence
Decision: environment and limits, reviewer, date
Recheck triggers: code, dependency, permission or destination changes

Use the record to distinguish a reviewed skill from a skill whose name merely appears on an allowlist. For teams adopting AIPentest_Skills, start with the specific workflow needed for the engagement and review its real files. Keep source approval, engagement authorization and runtime permission as separate decisions.

について PentestSkill release article explains the project catalog and adoption workflow. Use this audit checklist to review the selected revision before granting it capabilities in your own environment.

Keep the package-review evidence with the remediation record. If you are evaluating AI-assisted penetration testing for the surrounding application and API attack surface, create a Penligent account and confirm the supported scope before starting. The assessment method here does not imply that every model, identity provider or agent runtime is automatically covered.

Keep skill review separate from execution

The official Penligent 3.0 video illustrates the product workflow, not the open-source skill catalog. Review skill provenance and permissions using the checklist above before any approved use of executable material.