Respond to a suspected poisoned skill

Contain the active path

Disable the suspect package or revision and pause sensitive workflows that load it. Revoke credentials it could reach when exposure is plausible. Restrict suspicious destinations and isolate affected workspaces if harmful activity is ongoing.

Choose the sequence according to the incident. If activity is continuing, containment may take priority over a complete evidence snapshot. Follow your organization’s response process.

Preserve a reconstructable record

Keep the package artifact, loaded resources, revisions, host configuration, timestamps, approvals, and action logs. Protect the evidence and redact secret values where practical without removing essential context.

A package name alone cannot identify the state involved. Retain the exact artifact or a verifiable revision and record where supporting remote material came from.

Assess actual impact

Distinguish suspicious instructions, attempted actions, blocked actions, and verified effects. Correlate file, network, application, identity, and agent records. Determine which data was accessed, which records changed, and whether content left the environment.

Do not treat an alarming instruction as proof of successful exfiltration. Do not treat a reassuring final answer as proof that no side effect occurred.

Recover a known state

Use a reviewed artifact and a constrained permission profile. Rotate affected credentials, undo confirmed changes where possible, and check for downstream artifacts or persistence outside the skill itself.

Re-enable the workflow only after the entry point and stopping controls are understood and tested. If the root cause is unknown, preserve that uncertainty and limit authority accordingly.

Close the loop

• Record facts, assumptions, impact, and the response timeline.
• Update admission review and boundary tests.
• Review related packages and shared dependencies.
• Coordinate with the affected maintainer through official channels.
• Assign owners for improvements and verify completion.

Notification and disclosure obligations depend on the incident and jurisdiction. Use the organization’s applicable procedures rather than assuming a general playbook covers every requirement.

Worked example: package removal is only one containment step

An agent loaded a suspect skill that could access a test credential and create a scheduled action. Removing the skill stops one loading path, but may leave an issued credential, generated file, changed application setting, or background task. Recovery needs an effect inventory as well as a package inventory.

Work through the evidence

Preserve the artifact, host state, resource chain, timestamps, and relevant actions where feasible. If harmful activity is ongoing, containment can take priority over perfect evidence collection. Determine which effects are confirmed and which are only possible under the available permissions. Coordinate with the organization’s response owner and the affected maintainer.

Decision criteria and a useful review record

Re-enable a workflow from a reviewed state with bounded access and a known stopping control. Verify revocation of exposed access and reversal of confirmed changes where possible. Document uncertainty rather than calling the environment clean solely because the package disappeared. The response should produce a reproducible timeline, recovery evidence, and a test that prevents the relevant chain from silently returning.