They inherit the permissions of the host environment, so one compromised extension can reach tokens, files, and network endpoints that were never meant to be shared. The blast radius grows when OAuth scopes are broad and when users trust labels instead of code behaviour. That combination turns one skill into many downstream compromises.
Why This Matters for Security Teams
Marketplace-installed AI extensions are risky because they are not just add-ons, they are execution paths inside a trusted host. Once installed, they often inherit broad access to tokens, files, prompts, and network destinations that were already approved for the parent environment. That turns supply chain trust into privilege amplification. NIST guidance on NIST Cybersecurity Framework 2.0 is clear that asset visibility and access governance have to account for software components that can act on behalf of users, not just the users themselves.
The practical problem is that most teams review marketplace listings, labels, and ratings, but not the code paths an extension can invoke once it is granted OAuth scopes or browser-level permissions. That gap is exactly where small trust decisions become large compromise paths. NHIMG research on Ultimate Guide to NHIs — The NHI Market shows how quickly non-human access can accumulate when identities are treated as convenience objects rather than security boundaries. In practice, many security teams encounter extension abuse only after tokens have already been exfiltrated or downstream systems have already been queried, rather than through intentional review of extension behaviour.
How It Works in Practice
The blast radius expands because extensions usually operate with inherited trust. A marketplace install may receive access to the same session, APIs, storage, and outbound connectivity as the host application, even if the extension itself was never subjected to the same scrutiny. In agentic or AI-assisted workflows, this is more dangerous because the extension may be able to trigger tool calls, retrieve context, or chain actions automatically.
Current guidance suggests treating these extensions as non-human identities with their own lifecycle, not as simple software plugins. That means reviewing requested scopes, constraining token use, and separating read-only context from write-capable actions. It also means monitoring for behaviour, not just signatures. If an extension can read a document, summarise it, and then post the summary to an external endpoint, the real control question is whether that end-to-end behaviour was authorised.
- Limit OAuth scopes to the narrowest set that supports the use case.
- Prefer short-lived, task-bound credentials over persistent tokens.
- Segment extensions from high-value files, secrets stores, and admin APIs.
- Require runtime logging for outbound calls, file access, and token use.
For teams mapping this to broader control objectives, the DeepSeek breach research is a reminder that exposed secrets and over-trusted data paths can expose far more than a single tenant or account. These controls tend to break down when extensions are allowed inside productivity suites with inherited admin consent, because one installed component can silently inherit access to entire mailboxes, document libraries, and connected SaaS tools.
Common Variations and Edge Cases
Tighter extension controls often increase friction for end users and platform owners, requiring organisations to balance usability against containment. That tradeoff is real, especially when business teams rely on marketplace tools for automation and content generation. Best practice is evolving, but there is no universal standard for how much inherited permission is acceptable across every platform.
One common edge case is when the extension itself is legitimate but its downstream dependencies are not. Another is when an enterprise-approved extension becomes dangerous after a vendor update changes its permission model or data flows. Security teams should also be careful with trust labels such as “verified” or “popular,” because those describe marketplace status, not runtime behaviour. In some environments, the safer pattern is to broker extension access through a policy layer that evaluates each request in context, rather than giving blanket approval at install time.
Where this approach is most fragile is in highly integrated SaaS ecosystems with shared tenants, legacy consent grants, and limited telemetry, because the extension can move laterally without generating obvious alarms.
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 CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A03 | Marketplace extensions can execute actions beyond intended user trust. |
| CSA MAESTRO | GOV-02 | Covers governance for third-party agentic components and permissions. |
| NIST AI RMF | AI RMF addresses governance and risk for autonomous software behaviour. |
Document extension risk, monitor behaviour, and enforce human accountability.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 5, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
