The skill poisoning defense checklist

Package identity

• Record source, maintainer, version or commit, and artifact integrity.
• Assign an internal owner and intended task scope.
• Inventory all files, resources, dependency sources, and learned artifacts.
• Document unresolved provenance questions rather than silently accepting them.

Instruction and content review

• Compare the description and body with the actual task.
• Follow every reference and inspect how assets are consumed.
• Investigate unrelated prerequisites, concealment requests, and changed destinations.
• Separate task procedure from permission to perform sensitive actions.
• Record mutable remote resources and their change policy.

Code and runtime

• Review executable entry points, subprocesses, and dependencies.
• Test with synthetic records and no production credentials.
• Limit readable and writable paths to the workflow.
• Restrict network destinations and inspect data leaving the environment.
• Validate output-to-action paths, especially for model-bearing components.
• Test the complete composed workflow, not only each package alone.

Approval and observation

• Enforce sensitive actions outside the skill’s own instructions.
• Show the actual target and meaningful arguments in an approval.
• Log package identity, actions, approvals, and effects with sensitive values protected.
• Distinguish static warnings, attempted actions, and confirmed impact.
• Keep a known way to disable a revision and revoke associated credentials.

Changes and maintenance

• Pin the approved artifact and dependency state.
• Review content, code, resource, permission, and environment changes.
• Retain an approved rollback artifact.
• Remove unused skills and unneeded scopes.
• Re-run boundary tests after material changes.

Use the workbench for a review record and export it when complete. The checklist is an editorial baseline; adapt it to the system and keep evidence behind each decision.

Turn a checked item into a verifiable claim

A reviewer checks “network access defined.” Another person cannot tell whether that means the skill documentation mentioned a domain, the runtime enforced an allowlist, or a denied transfer was actually tested. The check is a summary of a claim, not the evidence that supports it.

Work through the evidence

For important checks, attach an artifact, observation, and owner. A file-inventory check points to a manifest; a permissions check points to the enforced profile; a test check points to input, expected result, action trace, and outcome. Record skipped checks and explain what blocks completion. Do not invent a reassuring percentage from the number of checked boxes.

Decision criteria and a useful review record

Close a check when its evidence answers the stated question for the exact reviewed state. “Not applicable” also needs a reason: absence of a bundled script does not establish that no external execution path exists. Use the checklist as a handoff between reviewers, and retain the unresolved items beside the final scope decision.