Treat it as untrusted until it passes provenance review, dependency inspection, and policy checks. The fact that a skill appears productive does not make it safe, especially when it can influence agent decisions or move data externally. Organisations should block unverified skills rather than trying to police them after installation.
Why an unverified marketplace skill is a supply-chain risk, not just a productivity shortcut
A marketplace skill can look helpful because it solves a real workflow problem, but that same convenience is what makes it risky. Unverified skills can inherit trust from the platform while still hiding malicious logic, weak dependency hygiene, or unexpected data egress. Security teams should treat the decision as a supply-chain trust problem, not a feature-evaluation exercise.
Marketplaces compress review pressure because the skill arrives packaged as something already vetted. That assumption breaks down when the skill can call tools, read context, or interact with external services. Even a benign-looking skill can widen the attack surface if it expands what the agent can see, send, or execute.
That is why the JetBrains Marketplace AI Plugin Campaign matters here: it shows how a marketplace listing can hide supply-chain abuse that steals secrets after installation. The lesson is not limited to one platform. Any unverified skill that reaches into credentials, prompts, files, or external APIs deserves the same suspicion.
What security teams should check before allowing installation
Provenance review should answer who built the skill, what repository or publisher it came from, whether the package identity is stable, and whether the release history looks credible. Dependency inspection should look for opaque transitive packages, unexpected network calls, and any component that can change behaviour after review. Policy checks should decide whether the skill is allowed to access data, tools, or destinations that the business would not permit to a new third-party integration.
A useful rule is to review the skill as if it were an external code package with runtime authority, because that is effectively what it is. If the skill can influence agent decisions, it is part of the trust boundary even when it seems to be “just a helper.” If it can move data externally, the review must include data handling, destination control, and whether the skill’s purpose justifies that path at all.
For agent-facing extensions, the strongest comparison is OWASP Agentic Skills Top 10 (AST10), which focuses on the skill layer where permission inheritance, malicious skills, and credential exposure become operational problems. That lens is useful because the security issue is often not the model itself, but the skill that changes what the agent is allowed to do. Teams should use that mindset to gate skills before they are ever connected to production workflows.
Why block-first is safer than post-install monitoring
Blocking unverified skills is safer because installation itself creates new trust, new reach, and sometimes new persistence. Once a skill is installed, it may be difficult to distinguish normal behaviour from malicious behaviour, especially if it is designed to look productive while quietly harvesting context or redirecting outputs. Post-install monitoring is useful, but it is not a substitute for approval.
Best practice is to keep the default posture narrow: only approved skills should be installable, and any exception should be time-bound and explicitly owned. If the skill cannot pass provenance, dependency, and policy review, it should not be “watched” into safety. That is particularly true when the skill can touch sensitive data, alter decisions, or interact with systems outside the original application boundary.
From a control perspective, NIST SP 800-53 Rev 5 Security and Privacy Controls supports that position through access control, configuration management, system integrity, and audit expectations. The practical takeaway is to prevent unreviewed capability from entering the environment, not to assume telemetry will compensate for an unsafe allow decision.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI04 — Agentic Supply Chain Vulnerabilities | Unverified skills are a supply-chain trust issue for agentic systems. |
| Recommendation — Review skill provenance and block untrusted packages before they reach production. | ||
| NIST SP 800-53 Rev 5 | SA-12 — Supply Chain Protection | Marketplace skills require supplier and component trust checks before approval. |
| CM-8 — System Component Inventory | Teams need an inventory of installed skills and dependencies to govern exposure. | |
| AC-6 — Least Privilege | Skills should receive only the access needed for their approved function. | |
| Recommendation — Require provenance validation and supplier controls before installing third-party skills. Track approved skills and dependencies so unreviewed components are visible and removable. Limit skill permissions to the minimum access needed for the approved use case. | ||
Practitioner Guidance
What to prioritise: Treat the skill as a supply-chain and authority decision first, not a user-request convenience. The first question is whether the skill is allowed to exist in the environment at all; only after that should you consider whether its output is useful.
What to verify: Confirm publisher identity, release provenance, dependency tree, outbound connections, and the exact data or tools the skill can reach. If any of those answers are unclear, the skill is not ready for production use.
Decision rule: If an unverified skill can influence agent behaviour, access sensitive context, or send data externally, block it until it passes review. Do not rely on detection controls to make an untrusted skill acceptable after installation.
Practitioner takeaway: A useful skill is not a trusted skill, and productivity value should never outrank provenance when the component can extend an agent’s authority.
Related resources from NHI Mgmt Group
- How should security teams govern machine identity credentials in agentic AI environments?
- How should security teams manage permissions for AI agents?
- How should security teams govern AI agents that use OAuth access?
- How should security teams limit the risk from AI agents that have access to production systems?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org