Who is accountable when a malicious skill persists after removal?

Why This Matters for Security Teams

When a malicious skill still acts after deletion, the issue is not just the artifact. The real risk sits in the surrounding control plane: cached instructions, persisted tool permissions, retained prompts, stored memory, and any approval record that was never revoked. That makes accountability a governance question as much as a technical one, because the team responsible for the skill lifecycle must also account for the runtime state that can outlive it. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it treats control effectiveness as an operational outcome, not a one-time configuration.

Security teams often assume deletion equals removal of risk, but agentic systems rarely work that cleanly. A skill may be gone from the catalog while its permissions, embeddings, cached context, or downstream references remain active. If the runtime can still invoke the skill logic, the organisation has not actually completed remediation. In practice, many security teams encounter this only after a post-incident review finds that the “removed” capability was still reachable through another path, rather than through intentional lifecycle governance.

How It Works in Practice

Accountability usually lands with the owner of the agent platform or skill management process, because that function controls the full lifecycle: creation, approval, deployment, monitoring, revocation, and recovery. In a mature setup, removal should trigger a chain of actions that clears both the visible skill and the hidden state around it. That includes memory stores, session caches, policy references, secrets, connector grants, and any delegated authority that the skill used to operate.

The practical sequence should look like this:

• Revoke the skill’s execution path in the runtime, not only in the catalog.
• Invalidate related credentials, tokens, and connector permissions.
• Check memory, prompt history, retrieval indexes, and policy stores for durable references.
• Review approval workflows to confirm no stale exceptions or standing privileges remain.
• Validate that monitoring and detection rules now alert on any attempt to reuse the removed capability.

This is where identity and agent governance intersect. If the skill acted with delegated authority, the team also needs to prove who approved that authority, when it was granted, and how it was withdrawn. A useful reference point is the OWASP Top 10 for Large Language Model Applications, especially where prompt injection, excessive agency, and insecure tool use can preserve harmful behaviour beyond the initial artifact. Current guidance suggests that removal controls should be tested the same way revocation controls are tested for privileged access.

Operationally, this means the accountable team should be able to produce an audit trail that shows what was removed, what was revoked, what was retained for legal or forensic reasons, and what was verified as inactive. These controls tend to break down when agent runtimes are distributed across multiple services because no single team has a complete view of persistent state.

Common Variations and Edge Cases

Tighter revocation often increases operational overhead, requiring organisations to balance rapid incident response against the need to preserve evidence and avoid breaking legitimate automations. The hardest cases arise when the removed skill was embedded in a broader agent workflow, reused through shared libraries, or mirrored across environments. In those environments, deleting one visible instance can leave cloned policies, cached tool schemas, or downstream agent instructions untouched.

There is no universal standard for this yet, but best practice is evolving toward treating removal as a multi-location purge with verification. That matters even more when the skill was connected to sensitive data, since residual access can become a compliance issue as well as a security one. Where the organisation uses autonomous agents, accountability should also cover whether the agent was allowed to self-reinvoke the skill or recreate an equivalent path after removal. For broader control mapping, NIST AI Risk Management Framework and MITRE ATLAS help frame the problem as both governance failure and adversarial persistence risk. The issue becomes especially messy in multi-tenant agent platforms, where shared memory and delegated access make it difficult to prove that one tenant’s removal did not leave a reusable residual path.

Related resources from NHI Mgmt Group

• Who is accountable when a malicious extension persists after store removal?
• Who is accountable when a malicious enterprise application persists after revocation?
• Who is accountable when an agent reopens the same PR or repeats a side effect after recovery?
• Who is accountable when a service identity retains access after the data need has ended?