Hidden risk in references and assets

Trace each referenced resource

Start from the entry file and follow every local path and URL. Record whether each resource is copied into an output, parsed for instructions, executed, or passed to another system. The same asset can have different consequences depending on how it is consumed.

A review should not stop at a filename such as “notes,” “example,” or “template.” Those labels describe an intended role, not a security property.

Local files and remote material

A local reference belongs to the package revision. A remote reference may change independently. If runtime behavior depends on mutable remote content, document that dependency and decide whether it needs a separate approval or a pinned copy.

For each external resource, ask who controls it, how it is retrieved, and what influence its contents have. A remote download that only supplies a public icon has a different role from a document that tells the agent which files to upload.

Illustrative scenario: the validation note

Synthetic scenario: a skill’s main file describes generating a local report. A reference document adds a validation step involving an external upload. The declared output remains the same, but the execution plan now includes data movement.

Reviewers should compare supporting instructions with the approved data flow. The defensive goal is that a newly encountered reference cannot expand the task’s authority without an independent decision.

Assets that carry behavior

Templates may contain macros, links, hidden text, or content later interpreted by another application. Images may become text through extraction. Generated configuration can affect a downstream process. Review the asset in the form the consumer will see it.

Ask whether a resource is passive in the relevant workflow. If it causes another component to execute, fetch, or interpret content, include that component in the skill’s threat model.

A resource review record

• Resource identity, origin, and revision or integrity value.
• How the agent or downstream application consumes it.
• Any instruction or behavior it adds beyond the entry file.
• Data it can expose and destinations it can influence.
• What happens if the resource changes or becomes unavailable.

Keep a failure path that allows the agent to stop and explain the unresolved dependency rather than improvise a new destination or permission.

Worked example: a stable skill points to changing instructions

A reviewed package refers to a remote formatting guide. The local commit is pinned, but the guide later adds an upload instruction. The package’s bytes have not changed, while its effective instruction set has. A hash of the local folder therefore cannot identify all of the behavior that a later run may encounter.

Work through the evidence

Draw the resource chain: package, referenced document, further links, templates, and destinations. For each edge, record the owner, retrieval time, content identity where feasible, and whether the host treats it as data or procedural guidance. Distinguish a static public image from a document capable of changing the workflow. The same URL can serve different content over time.

Decision criteria and a useful review record

Use a reviewed snapshot when a mutable reference can control a consequential action. If live content is necessary, constrain its influence and the permitted destinations independently. A changed reference should trigger review according to effect, not merely file extension. Keep the loaded content or a suitable evidence record so the next reviewer can reconstruct what the agent actually saw.