SkillLifeBench tests lifecycle decisions for agent skills over a collection of scenarios, including cases where an updated package is available after a vulnerable version. One example has an agent correctly select the patched v1 package but continue to use a previously loaded v0 tool handle. The old handle can still expose files such as .git/config despite…
Inspect the ClaimsCase · DiggingBeagle record
An agent selected a patched skill but executed an old loaded handle in a benchmark
SkillLifeBench exposes a mismatch between the version an agent says it chose and the executable skill still cached by its runtime.
Controlled skill-lifecycle scenarios, not a count of exploited real installations. Outcomes depend on the benchmark harness and simulated package states.
Assessment profile
Assessment method- Setting
- evaluation
- Exploitation
- demonstrated
- Evidence
- Grade B
- Remediation
- mitigation available
- AI role
- AGAINST AI
Basis and provenance
SkillLifeBench provides a controlled lifecycle regression, without identifying live victims or a particular commercial platform patch. Impact remains unrated because the scoped record does not establish a calibrated severity-to-impact-band mapping.
Assessed Oct 31, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-C26-SKILLLIFEBENCH-STALE-HANDLE-1 · SkillLifeBench: skill lifecycle decisions and stale installed execution
At a glance
A correct version decision in text does not prove the executing capability or loaded artifact has been revoked.
Read the implicationsThe share of real agent systems retaining stale tool handles is not established. Update mechanisms that forcibly rebind and revoke existing handles need independent testing.
Limits and uncertaintyFull account
SkillLifeBench tests lifecycle decisions for agent skills over a collection of scenarios, including cases where an updated package is available after a vulnerable version. One example has an agent correctly select the patched v1 package but continue to use a previously loaded v0 tool handle. The old handle can still expose files such as .git/config despite the agent’s correct-looking version decision. This is a runtime identity and revocation failure, not necessarily a bad textual review of the new package.
The study also reports scenarios that satisfy ordinary task completion while reaching an attacker objective, a reminder that a final answer can hide intermediate side effects. The relevant regression checks compare installed artifact hash, current tool registry, active process handle and actual call target. Merely logging a planned update does not establish that the old authority has been removed.
Mechanism and trust boundary
- 01
Step
- 02
Step
- 03
Step
Timeline
- Oct 29, 2026disclosure
Public disclosure
Claims & evidence
CLM-C26-SKILLLIFEBENCH-STALE-HANDLE-1SkillLifeBench documents a controlled case in which an agent chose patched skill v1 but executed a stale v0 handle with an unsafe filesystem capability.supported
Basis: reported finding
- supportsSkillLifeBench: skill lifecycle decisions and stale installed executionprimary disclosure
SkillLifeBench paper, version-update and stale-handle experiment
Implications
A correct version decision in text does not prove the executing capability or loaded artifact has been revoked.
Controls and mitigations
- Bind tool calls to a current version hash and invalidate loaded handles during updates; test actual call targets after an upgrade.
Unknowns and contradictions
- The share of real agent systems retaining stale tool handles is not established.
- Update mechanisms that forcibly rebind and revoke existing handles need independent testing.
Sources and citation
Material revision history
- Oct 31, 2026 · Canonical change recorded · new in release · revision 208