Audit third-party AI skills and MCP servers before install

Skill Security Audit reviews a third-party Agent Skill, MCP server, connector or desktop extension before you install it. It traces code, dependencies, permissions, credentials, data flow and irreversible actions. The default workflow is read-only: during static review the agent does not install dependencies, execute project code, sign in, provide credentials or connect the project to a real account. The skill is CC0-1.0 licensed and marked safe.

Use it before installing an unfamiliar Skill, MCP server, connector, plugin or desktop extension, when a project handles files, credentials, browser sessions, external accounts, network requests or destructive actions, and when a release, binary, dependency or remote installer cannot be independently verified.

Static review has limits. It cannot prove runtime behavior or the contents of an opaque remote service. A green validator, marketplace entry, star count or successful installation is evidence about only that narrow property and never a safety certificate. The audit is bounded by the public revision and files that can be inspected, and a missing policy or undocumented data destination stays unresolved and must not be silently inferred away. The skill says to stop if the review would require real credentials, production data or an unapproved external action.

The input is the project under review. The process has seven steps:

1. Record the exact repository, revision or release, license, archive status, latest meaningful update and files reviewed, and state any scope limitation.
2. Read the complete SKILL.md or equivalent instructions and every file it directly invokes, following references to scripts, hooks, manifests, package-install steps, binaries, remote URLs, environment variables and bundled assets.
3. Inventory capabilities: filesystem access, command execution, network access, browser control, account actions, publishing, messaging, deletion, payment, credential access, persistence and self-update behavior.
4. Trace sensitive data from its source to local stores, subprocesses, logs, models, APIs, MCP servers, analytics services and other network destinations. Missing documentation is an unresolved question, not proof that data stays local.
5. Inspect dependency manifests, lockfiles, install scripts and release provenance, noting unpinned remote execution, broad dependencies, opaque binaries and mismatches between source and distributed artifacts.
6. Separate confirmed findings from contextual risks and unanswered questions, citing file paths, line numbers, configuration fields, commands or primary documentation for every material claim.
7. Propose a minimal-permission test using disposable data or accounts, and do not run it without explicit user approval.

The report begins with the audited identity and one of three verdicts. Lower observed risk means no material concern was found in the reviewed scope, and it is not a guarantee. Review required means important behavior, provenance, permissions or data flow remains unclear. High observed risk means confirmed behavior could expose sensitive data, weaken account or device security, cause irreversible action or bypass informed control. After the verdict come six parts: scope and limitations, a capability and permission table, a data-flow table, findings ordered by severity with evidence, impact and mitigation, unanswered questions, and a minimal-permission test plan.

Two worked examples set expectations. For a local, read-only Skill containing only SKILL.md and Markdown references, the report records the reviewed revision and files, marks command, network and credential capabilities as not observed in scope, notes missing license or provenance evidence, and recommends a disposable-data trial only if remaining questions are resolved. For an MCP server whose setup reads an API_TOKEN and whose tools can create or delete records, the report traces the token and request destinations, classifies write and delete capability separately from read access, requires a least-privilege test account and action-time confirmation, and does not run the server with production credentials during review.

Best practices: prefer implementation and current primary documentation over badges, screenshots, descriptions or popularity; pin revisions and inspect manifests, lockfiles, checksums and release provenance; use disposable data, least privilege, localhost binding, dry runs, backups, confirmation gates and rollback where applicable; and mark unknown behavior explicitly. Do not call a project safe, malicious, official or compliant without evidence for that claim, and do not execute install commands, remote scripts, binaries, account actions or credential flows during static review. Severity depends on capability, exposure, control and reversibility and not on keywords alone.

It applies to Agent Skills, MCP servers, connectors, plugins and desktop extensions, and its metadata lists compatibility with Claude, Codex, Cursor, Gemini and WorkBuddy.

Security-conscious developers, platform teams and users who install third-party agent extensions and want an evidence-based, read-only vetting step first.