When skills combine: composition risk

Review the workflow, not only components

Agents may use several skills in sequence or combine their outputs. A package that has limited authority alone can affect another package that has more. Review how information and intermediate state move through the combined workflow.

SkillTrojan studies malicious behavior in skill implementations and activation through composition. The paper’s research setting is specific; the practical question is whether your workflow lets one skill’s output gain authority later.

Make handoffs visible

For each handoff, identify the producer, consumer, data format, and trust level. Does the consumer interpret the output as data or as a procedure? Can a generated file become executable? Does a later skill act on a path or destination supplied by an earlier one?

Write down which component validates each decision. “The previous skill checked it” should be backed by a defined contract and evidence.

Illustrative scenario: a changed destination

Synthetic scenario: a data-preparation skill produces a manifest for a publishing skill. The manifest contains a destination that differs from the user’s approved target. The publishing step should compare that destination with an independently authorized value rather than accepting the manifest as permission.

This example concerns data flow and authority. It does not describe a real exploit or imply that a particular product allows the sequence.

Reduce inherited authority

Pass only the data a downstream skill needs. Keep private context, credentials, and task authority from becoming general intermediate state. Recheck permission-sensitive targets at the point of action.

Use typed or validated handoff contracts where possible. Explicitly identify fields that carry paths, URLs, recipients, or commands, because those fields can become action parameters.

Evaluate the sequence

• Test each component on its own and in the actual order used.
• Observe intermediate files and memory, not just final output.
• Check whether one skill broadens another skill’s task scope.
• Verify that a rejected handoff leaves the workflow in a known state.
• Retain the versions of all participating packages.

Composition changes when a new package joins a workflow. Treat that integration as a new review event.

Worked example: a useful handoff changes meaning

One skill extracts addresses from public notes. Another sends a prepared message to an approved test address. A third merges outputs. If an extracted address is silently treated as the authorized recipient, the composed workflow has changed the user’s destination even though each component has a plausible individual purpose.

Work through the evidence

Write the handoff contract: field name, data type, origin, permitted uses, and validation rule. Distinguish an address mentioned in a source from an address approved for sending. Record intermediate artifacts and the point where data becomes an action argument. Test unexpected fields and values, not only the happy-path example.

Decision criteria and a useful review record

Enforce sensitive actions at the component that can perform them. Upstream text should not inherit that authority by appearing in a well-formed field. Review the whole sequence after changing any component. A safe handoff requires both a valid representation and a legitimate use; schema validation alone addresses only the first.