What should organisations do when an agent skill can silently replace another skill?

Why This Matters for Security Teams

Silent replacement turns an ordinary change-management issue into an identity and trust problem. If an agent skill can be swapped without an explicit prompt, provenance check, and policy decision, then the system can no longer distinguish maintenance from substitution. That breaks the assumptions behind software trust, change approval, and least privilege. Current guidance suggests treating the skill registry as an execution boundary, not a convenience layer.

This is especially important in agentic systems because skills often carry tool access, data access, and delegated authority. A replacement that looks identical by name can still change what the agent can reach, how it chains actions, and which downstream secrets it consumes. In practice, many teams discover the issue only after a trusted skill has already been replaced and used to move laterally or exfiltrate data, rather than through intentional review.

That risk profile is consistent with findings in the Ultimate Guide to Non-Human Identities, which reports that 97% of NHIs carry excessive privileges. For agentic attack patterns, the OWASP Top 10 for Agentic Applications 2026 and NIST AI RMF both point toward stronger runtime governance rather than trust by label alone.

How It Works in Practice

Security teams should block silent replacement at the policy layer and require runtime verification before a skill can be activated. The control objective is simple: a skill name is not an identity, and a new artifact should not inherit trust from an old one just because the label matches. For autonomous systems, the safer pattern is to bind approval to provenance, version, publisher, and policy state.

In practice, this means three checks should happen before execution:

• Provenance validation: confirm the skill came from an approved repository, signed release, or trusted build pipeline.
• Explicit authorization: require a human or policy decision when a replacement changes behavior, permissions, or data scope.
• Runtime enforcement: evaluate the request against current context, not only against the stored skill name or previous allowlist.

That approach aligns with the NIST AI Risk Management Framework, which emphasizes governance, measurement, and operational controls for AI systems, and with the CSA MAESTRO agentic AI threat modeling framework, which treats agent actions and tool use as security-relevant events. The same logic appears in NHIMG research on OWASP NHI Top 10, where trust in non-human execution paths must be continuously validated.

For higher-risk environments, best practice is evolving toward policy-as-code, signed artifacts, short-lived credentials, and separation between skill publication and skill activation. These controls tend to break down when teams allow direct repository writes into production skill registries because the replacement becomes indistinguishable from routine maintenance.

Common Variations and Edge Cases

Tighter replacement controls often increase operational overhead, requiring organisations to balance rapid patching against trust preservation. That tradeoff is real: some teams want emergency fixes to propagate immediately, while others need every replacement to be reviewed because the skill itself can invoke tools, read secrets, or trigger downstream automations.

There is no universal standard for this yet, but current guidance suggests a tiered model. Low-risk skills can be replaced only within a signed, immutable release process. High-risk skills, especially those with network access, code execution, or credential access, should require explicit re-approval and a fresh provenance check. If the replacement alters scope, the old trust should not carry over.

Edge cases often arise in marketplaces, plugin ecosystems, and multi-agent orchestration layers where the skill registry is shared across teams. In those environments, a name collision can mask a supplier change, a dependency update, or a malicious substitution. The safest posture is to treat any unannounced replacement as untrusted until the publisher, hash, policy version, and permission set all match. NHIMG guidance on the Analysis of Claude Code Security and the AI LLM hijack breach shows how quickly trust can be abused once execution paths are blended into ordinary development workflows.

Related resources from NHI Mgmt Group

• How can organisations reduce the blast radius of compromised agent identities?
• How do organisations operationalise NHI ownership at scale?
• Why is single-provider AI agent governance not enough for enterprise security?
• When should organisations treat an NHI as a high-priority risk?