Threat-model a skill before you install it

Start with one workflow

Choose a concrete task and a specific package revision. Write down the host, user, skill source, inputs, outputs, and runtime. A generic diagram of “an agent” hides the details that determine exposure.

Define success and prohibited effects. For a report skill, success might be a local file from an approved input folder. Prohibited effects could include reading another user’s files or transferring records to an unapproved destination.

Map influence and assets

List people and systems that can change the package, references, dependencies, or learned artifacts. Separately list assets the agent can reach: files, credentials, private context, connected services, and the ability to publish or delete.

The resulting map should show where attacker-controlled content could affect an action. Include indirect routes: a reference loaded later, a dependency installed during execution, or an intermediate output consumed by another skill.

Mark enforcement points

For every sensitive step, identify the actual control: file policy, network restriction, tool authorization, or meaningful human approval. Record what the control knows and whether the decision is independent of the skill.

A skill’s own instruction to behave safely is useful guidance but should not be the only barrier to an action it can also request.

Use a scenario register

Describe a scenario as entry point, intended deviation, required authority, observable effect, and stopping control. Rate it according to your own asset sensitivity and environment. Avoid universal numeric severity without a defined scoring model.

Example: “A referenced note changes the upload destination; network policy must reject the unapproved host.” This is testable and specific enough to assign an owner.

Keep the map live

• Revisit it after package and dependency updates.
• Revisit it when the host gains new tools or data.
• Record known gaps and temporary exceptions with an owner.
• Maintain a tested way to disable the package and revoke access.

Use the lifecycle explorer to organize the review from admission through evolution. The map should be short enough that a maintainer can actually use it during a change.

Worked example: scope one workflow before listing every threat

A team uses a skill to summarize customer tickets in a sandbox. The input is a synthetic ticket directory; the intended output is a local report. There is no task need for cloud credentials, personal home files, or outbound transfer. This bounded description is more useful than an undifferentiated list of every possible AI attack.

Work through the evidence

Record assets, adversary-controlled surfaces, granted capabilities, trust transitions, and observable prohibited effects. For each scenario, ask what the attacker must control and what the environment must allow. A reference-based disclosure attempt requires an influential reference plus a reachable data source and transfer path; those assumptions should be visible.

Decision criteria and a useful review record

Select controls that interrupt a stated chain, and define how to test the interruption. For example, a denied destination needs an observable rejection while the permitted local report still completes. Avoid universal severity scores without an agreed model. Revisit the map when the host, package, data, or permissions change because those changes can alter the impact without changing the text of the skill.