Why do marketplace security scores fail to stop malicious skills?

Why marketplace scores miss the real skill risk

Marketplace scores are usually a trust signal about the listing, not a proof of what the skill will do once installed. That matters because the security decision is not just “is the package approved?”, but “what code can execute, what data can it reach, and what happens after the initial review boundary is crossed?”

That gap is why an apparently clean score can coexist with a harmful runtime path. A skill can hide behaviour in bundled assets, delay execution until a later trigger, or use obfuscation and external callbacks to shift the actual risk away from the surface that the score evaluated.

A useful way to think about this is that the score covers one control point, while the malicious behaviour lives in another. When the assurance model is shallow, plugin and extension architecture security depends on isolation, permission boundaries and runtime control, not just listing review. The same logic applies here: the reviewer sees the declared package, but the endpoint experiences the executed behaviour.

What malicious skills exploit after approval

Once a skill is installed, the attacker does not need to win the marketplace review twice. The common abuse pattern is to make the published artefact look ordinary while reserving the harmful action for runtime, where scripts, deferred logic, configuration switches or remote calls can be used to change behaviour after approval.

That is especially effective when the skill can reach outside the host environment. If the skill can call out to a remote service, fetch instructions later, or assemble actions from multiple files, the marketplace score often has no direct way to measure the actual post-installation path. This is why OWASP Agentic Skills Top 10 (AST10) is relevant: the risk is not just the named skill, but the behaviour that emerges from skill chains, permission inheritance and hidden execution paths.

Published scores also tend to miss abuse of scope. A skill may request modest permissions on paper while still using them in a way that is broader than a reviewer expected. That mismatch is why least-privilege review matters even when a marketplace says the item is “trusted”, and why the boundary between declared capability and observed behaviour must stay under scrutiny.

How to evaluate scores without trusting them blindly

A security score is useful only if it is treated as one input to a deeper validation process. For marketplace skills, the important question is whether the review examined the skill’s actual execution paths, dependency behaviour and outbound connectivity, not just the metadata shown to buyers.

Practical verification means checking what the skill can do at runtime, what files or callbacks it can invoke, and whether any behaviour is deferred until after installation. The strongest control is not a higher score, but a review model that inspects the same surfaces an attacker can abuse. For that reason, the Agent Skills Security Guide is the right place to anchor a vetting process around manifests, allowed tools, scripts and ongoing monitoring.

Scores are most fragile when they are used as a purchase filter instead of an operating control. If the buyer assumes a high score means safe runtime behaviour, the organisation may skip sandboxing, telemetry or revalidation after updates. That is the failure mode the score cannot see: trust gets assigned at acquisition time, but the harmful action happens later under a different set of conditions.

Practitioner Guidance

What to verify: Treat the score as a starting point, then verify whether the skill has any hidden execution route, external callback, deferred action or permission path that the marketplace review did not exercise. If the answer is unclear, assume the review was incomplete until runtime evidence says otherwise.

Decision rule: If a skill can reach data, tools or network destinations that would matter if abused, require a runtime control such as isolation, restricted egress or explicit reapproval for scope changes. If you cannot observe that path, do not rely on the score as your primary assurance signal.

Common mistake: Teams often look for malicious intent in the listing text and miss malicious behaviour in the package structure, loader logic or post-install callback chain. The real test is whether the skill can do something different after approval than it appeared able to do before approval.

Practitioner takeaway: Marketplace scoring should reduce review workload, not replace behavioural validation, because the attack surface is the executed skill, not the marketed description.

Related resources from NHI Mgmt Group

• How should security teams stop AI agents from installing malicious skills?
• How should security teams stop browser AI agents from trusting malicious web content?
• How should security teams stop malicious CI/CD workflow commits from executing?
• How should security teams stop malicious open-source packages before they reach developers?