- Learned artifacts deserve their own review boundary.
- Benign samples cannot exclude every hidden trigger.
- Validate the path from model output to action.
An additional artifact boundary
A model-bearing skill introduces a learned component as part of its workflow. The component could classify, score, generate, or route information. Its outputs may shape later agent actions even if its implementation is presented as a routine helper.
BadSkill studies this surface in an OpenClaw-inspired simulation. It distinguishes behavior hidden in a bundled model from a conventional instruction-file injection. That distinction matters when deciding what evidence a review needs.
Understand the artifact’s role
Document how the model is loaded, which inputs reach it, and how its outputs affect the workflow. Is it advisory? Does it choose a command, destination, or permission-sensitive action? Can the consumer reject unexpected outputs?
Review the surrounding wrapper too. A model that only returns a category has a different exposure from a wrapper that maps that category to an unrestricted executable action.
Behavior testing and its limits
Test representative inputs, edge cases, and the range of outputs the downstream component accepts. Use an isolated environment and synthetic records. Compare behavior with the declared function of the component.
Normal behavior on a sample does not rule out a conditional backdoor. Triggered behavior may depend on combinations not represented in the test set. Record coverage and uncertainty rather than describing a finite test as a proof of absence.
Restrict the output-to-action path
Validate outputs against a narrow contract and check permission-sensitive actions independently. Avoid giving a learned component the power to select arbitrary code or destinations merely by returning text.
Keep the artifact’s identity, origin, revision, license, and deployment configuration with the skill review. Treat a changed artifact as a changed package even when the instruction file stays identical.
Questions for maintainers
- Why is the learned component needed for the stated task?
- Where did it come from, and can the distributed artifact be identified?
- What behavior and data were used to evaluate it?
- Which actions depend on its outputs?
- How can the skill run with narrower downstream authority?
A review that cannot answer these questions should preserve the uncertainty in its approval decision.
Worked example: a classifier controls a consequential branch
A skill bundles a classifier whose label determines whether a document may be sent to a partner service. The script simply follows that label. Inspection of the Python wrapper can reveal the branch but cannot establish the behavior of the learned artifact for every input. A benign-looking wrapper and a valid model file are different kinds of evidence.
Work through the evidence
Identify the model’s source, content identity, input features, output labels, and authority of each downstream branch. Test expected cases, relevant boundary cases, and non-trigger controls without real sensitive documents. Keep model behavior separate from whether an independent policy permits disclosure. Do not infer a backdoor merely from a surprising classification.
Decision criteria and a useful review record
A model output should not by itself authorize access or data movement. If the model cannot be inspected or its origin is uncertain, narrow the workflow or hold the artifact. Record tested conditions and remaining coverage gaps. A finite set of clean tests supports only those observations; it cannot certify the absence of all hidden triggers.
Sources & scope
This guide combines editorial explanation and practical review suggestions. Linked sources support the underlying concepts; this site has not independently replicated their experiments.
S06