The control that breaks is the assumption that publication equals safety. In a skill marketplace, a listed item can carry machine-executable authority, so trust in the catalogue becomes trust in runtime behaviour. Once that assumption fails, approval has to move from community reputation to provenance, permission scope, and execution controls.
When a skill marketplace is treated like a trusted app store
A skill marketplace only behaves like a normal software store if listing quality, publisher identity, and runtime authority are tightly bounded. The failure mode here is not just malicious code, it is delegated capability. A skill can look like a benign catalog item while still carrying permissions, tool access, or automated actions that change state outside the review moment.
The practical break is the mismatch between discovery trust and execution trust. Community rating, marketplace moderation, or download popularity may help with selection, but they do not prove what a skill can do once installed, granted scope, or chained into an agentic workflow.
That is why provenance, scoped permissioning, and explicit execution policy matter more than storefront reputation. In this pattern, the marketplace is only the distribution layer; the security decision happens at install time, at consent time, and again at runtime when the skill attempts to act.
Why marketplace trust has to be redefined for execution
A trusted app store model assumes that a vetted catalogue item is mostly safe to execute once approved. A skill marketplace breaks that assumption because the item may not just present content, it may invoke tools, access data, or trigger actions on behalf of a user or agent. The object being evaluated is therefore not a static app, but a capability with delegated authority.
This changes the trust boundary. The key question is no longer only “Who published it?” but “What does it inherit, what can it reach, and under what conditions can it act?” If those answers are not visible before approval, then the marketplace is obscuring the real control point.
That is also why permission scope matters more than generic reputation. A highly rated skill can still be unsafe if it requests broad access, reuses credentials across contexts, or can chain into higher-value systems through hidden integrations.
For a related pattern of third-party trust failure, the lesson from SaaS-to-SaaS and OAuth App Governance Guide is that consent, scope, and revocation need to be treated as first-class controls, not post-install cleanup.
What has to be controlled before approval and at runtime
Approval should be based on provenance, explicit permission scope, and the ability to constrain execution. That means reviewing who signed or published the skill, what dependencies it pulls in, what data it can read, and which external actions it can initiate. If the skill can act on behalf of a user or service, the runtime controls must be as important as the marketplace checks.
For marketplaces that blend code, prompts, and automation, hidden dependency risk is real. A seemingly harmless skill can inherit dangerous behavior through linked extensions, opaque tool calls, or credential exposure inside its execution path. The same logic applies whether the skill is delivered as a plugin, a template, or an agent skill.
That is why the strongest control model is not “approved once, trusted always.” It is continuous constraint: least privilege, short-lived authorization, revocation paths, and monitoring for unexpected tool use or privilege escalation. A skill should be able to do only what the current task requires, not what the marketplace author imagined.
Marketplace trust also depends on whether the platform can prove it is isolating one skill from another. If permissions, secrets, or context can bleed across items, then the store itself becomes a risk amplifier rather than a trust filter.
For the malicious-plugin pattern, JetBrains Marketplace AI Plugin Campaign shows how a marketplace channel can be used to distribute software that steals credentials once it is allowed to run.
What breaks in governance when the catalog is mistaken for the control
Governance breaks first, because the marketplace begins to stand in for security review. Teams assume that publication status, vendor review, or storefront moderation is enough, and then skip the deeper question of whether the skill is allowed to exercise the authority it was granted. That is a category error, not just a process gap.
Operationally, the control plane should distinguish discoverability from authorization. A skill may be easy to find, well rated, and widely installed, yet still require restrictive permission boundaries, separate approval for sensitive actions, and periodic revalidation of the permissions it retains.
The same applies to secrets handling. If a marketplace item can access tokens or API keys, then the security problem is no longer about the item’s description, it is about secret exposure and what downstream systems those secrets unlock. In other words, listing trust is not a substitute for credential governance.
The simplest governance test is whether the platform can answer three questions at any moment: who published the skill, what it can do, and how that power is revoked. If any of those are unclear, the marketplace is functioning as a distribution channel, not a trusted control.
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 and OWASP Non-Human Identity Top 10 address 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 | ASI02 — Tool Misuse | Skill marketplaces can grant tools and actions to listed items. |
| ASI03 — Identity & Privilege Abuse | The question centers on delegated authority that can exceed intended scope. | |
| ASI04 — Agentic Supply Chain Vulnerabilities | Marketplace distribution creates third-party dependency and provenance risk. | |
| Recommendation — Restrict each skill’s tool access to the minimum required and monitor for unexpected calls. Enforce least privilege and separate approval from runtime authority for every skill. Verify publisher provenance and dependency integrity before allowing a skill to execute. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Marketplace skills are third-party capabilities that can carry hidden risk. |
| NHI-05 — Overprivileged NHI | The core failure is excessive runtime authority beyond the task need. | |
| Recommendation — Assess third-party skills as untrusted until provenance, scope, and revocation are confirmed. Constrain every skill to the narrowest possible permissions and revoke excess access. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Skills acting through machine or service authority need strong authentication and trust boundaries. |
| Recommendation — Authenticate non-human actors with distinct credentials and validate their asserted identity. | ||
Practitioner Guidance
What to verify: Verify the effective permission envelope, not just the publisher identity. A skill is only safe to approve if you can describe its data access, tool access, and revocation path in plain terms.
Decision rule: If a skill can modify systems, trigger workflows, or reach secrets, treat it as an execution risk and require scoped approval plus runtime monitoring, not marketplace trust alone.
What practitioners underestimate: The dangerous part is often not the obvious malicious item, but the ordinary-looking one that inherits broad authority after installation. That is where approval based on reputation collapses into approval based on runtime impact.
Practitioner takeaway: The control model must move from “Is this listing trusted?” to “What authority does this capability receive, and can we bound and revoke it cleanly?”