By separating development freedom from governance authority. Teams should allow apps to be built and shared, while still enforcing least privilege, code review, audit logging, and lifecycle ownership. Marketplace scale is manageable only when every extension has a named accountable owner and a tested path for removal or rollback.
Why This Matters for Security Teams
Marketplace extensibility often starts as a productivity feature and ends as an identity problem. Every plugin, app, or extension introduces code execution, API access, and lifecycle risk that must be governed like any other privileged workload. The challenge is not just whether an extension is useful, but whether its permissions, ownership, and revocation path are controlled well enough to survive scale.
NHI Management Group research shows how fast this risk becomes material: 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and only 20% of organisations have formal processes for offboarding and revoking API keys. That is why marketplace governance cannot rely on trust in developers alone. Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls is to treat these controls as standard security operations, not optional platform hygiene.
In practice, many security teams encounter excessive marketplace reach only after an extension has already been embedded in critical workflows and the rollback path is unclear.
How It Works in Practice
The control model should separate build freedom from governance authority. Product teams can create and publish extensions, but security should enforce a registration gate that records the app owner, requested scopes, data access, signing status, and dependency chain before activation. This is where marketplace policy becomes an identity and access problem, not just a code review problem. The extension should run with least privilege, with permissions bounded to the smallest functional set and reassessed when its behavior changes.
Operationally, the strongest pattern is to require named ownership, approval for high-risk scopes, continuous audit logging, and an offboarding procedure that can disable the extension without breaking the host platform. That aligns with the broader NHI lifecycle guidance in the Ultimate Guide to NHIs — Standards and with marketplace-scale risk lessons from the Ultimate Guide to NHIs — The NHI Market. Security teams should also baseline review requirements for source provenance, secrets handling, update channels, and revocation testing before an extension is made available to users.
- Require a named owner for every extension and make ownership a release requirement.
- Approve permissions by risk tier, not by developer request alone.
- Log installation, scope changes, token use, and removal events centrally.
- Test rollback and disablement paths as part of release readiness.
These controls tend to break down when third-party extensions can self-update or inherit broad tenant-level permissions because the governance team loses visibility into what code is actually running.
Common Variations and Edge Cases
Tighter marketplace control often increases release friction, requiring organisations to balance developer speed against blast-radius reduction. That tradeoff is real, especially in internal app ecosystems where teams expect quick publishing and broad reuse. Best practice is evolving here, and there is no universal standard for every marketplace design.
For low-risk extensions, a lighter review path may be acceptable if permissions are narrow and the data exposure is limited. For apps that can read messages, create tickets, trigger workflows, or access secrets, the bar should be much higher: code signing, security testing, human approval for elevated scopes, and periodic recertification of active apps. This is especially important in environments where plugin ecosystems resemble supply-chain entry points, as highlighted by the JetBrains Marketplace AI Plugin Campaign. In parallel, platform owners should map marketplace controls to NIST SP 800-53 Rev 5 Security and Privacy Controls so extensions are governed as software with privilege, not as harmless add-ons.
The edge case that most often surprises teams is delegated publishing, where business units can approve apps faster than security can revoke them, creating shadow privilege that survives long after the original use case has changed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 | Marketplace apps are NHIs with lifecycle and privilege risk. |
| OWASP Agentic AI Top 10 | A2 | Extensions can behave like autonomous tool-using agents. |
| CSA MAESTRO | GOV-01 | Marketplace governance needs accountable ownership and policy controls. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is central to controlling extension blast radius. |
| NIST AI RMF | GOVERN | Extension ecosystems need accountability, oversight, and traceable decision-making. |
Inventory each extension as an NHI, enforce least privilege, and revoke access on removal or scope change.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
