Accountability is shared across the marketplace operator, the extension publisher, and the organisation that allowed the extension into a credential-bearing environment. Practically, security leaders own the policy for approval, monitoring, and revocation. If an extension can touch production access, it must be governed like any other third-party identity dependency.
Why This Matters for Security Teams
A marketplace extension that can read cloud tokens is not a minor add-on risk. It is a third-party identity dependency with the ability to act inside production trust boundaries, often without the same review, logging, or revocation discipline applied to human administrators. That makes accountability less about who clicked install and more about who approved the risk, who monitored the extension’s behaviour, and who could remove it fast enough when misuse appeared.
The practical failure is familiar: teams treat extensions as productivity tools, not as privileged software with access to secrets, API keys, or session tokens. Once tokens are stolen, the blast radius is determined by what the extension could reach before detection. This is why NHI governance must cover marketplace software in the same control plane as service accounts and other non-human identities. The pattern is consistent with breaches such as the JetBrains GitHub plugin token exposure, where trusted tooling becomes the path to credential theft, and the broader Guide to the Secret Sprawl Challenge, which shows how quickly secrets move beyond intended control.
Current guidance suggests treating extension approval as an access decision, not a software procurement formality. In practice, many security teams encounter compromise only after tokens have already been exported, replayed, or reused elsewhere.
How It Works in Practice
Accountability should be mapped to control points. The marketplace operator is responsible for platform-level review, sandboxing, policy enforcement, and removal pathways. The extension publisher is accountable for what the extension collects, how it handles secrets, and whether its behaviour matches its declared function. The organisation that installs the extension remains accountable for allowing a credential-bearing component into its environment and for enforcing limits on what that component can access.
For security teams, the question is not whether the extension is “approved,” but whether it is governed like any other privileged dependency. That means requiring least privilege, scoped tokens, short-lived credentials, logging on token access, and rapid revocation paths. NIST guidance on access control in NIST SP 800-53 Rev 5 Security and Privacy Controls supports this approach through strong authorization, monitoring, and account lifecycle controls.
- Approve extensions only for defined business use cases, not convenience.
- Separate development, admin, and production environments so extension reach is constrained.
- Inventory what secrets the extension can read, mint, cache, or transmit.
- Use just-in-time elevation and revoke access automatically after the task ends.
- Monitor for anomalous token use, unusual outbound calls, and data exfiltration patterns.
NHIMG research on the Salesloft OAuth token breach underscores the real-world consequence: once a third-party integration can access tokens, trust in the original boundary is already weakened. These controls tend to break down in environments where extensions run with broad browser, IDE, or CI/CD permissions because token access becomes implicit rather than explicitly brokered.
Common Variations and Edge Cases
Tighter extension control often increases rollout friction, so organisations must balance developer convenience against token exposure risk. There is no universal standard yet for how deeply a marketplace should inspect third-party extensions, which means governance usually has to be stricter than the platform baseline.
Edge cases matter. A browser extension that only reads public pages is not the same as one that can inspect authenticated cloud consoles. A developer plugin that operates in a sandbox is different from one that can access production credentials from a workstation profile. Best practice is evolving, but the safe default is to classify any extension with secret visibility as a privileged workload and to subject it to continuous review. That is especially important when secrets are duplicated across tools or stored in chat, ticketing, and code systems, a pattern highlighted in NHIMG’s Guide to the Secret Sprawl Challenge.
Practical accountability also depends on evidence. If a marketplace cannot show how it reviews code, isolates extensions, or supports emergency removal, the organisation must assume the residual risk. That is the lesson from extensions and integrations that silently overreach: the actor that enables token access is accountable when the token is stolen, even if the theft happens downstream.
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 and OWASP Agentic AI Top 10 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 Non-Human Identity Top 10 | NHI-01 | Third-party extensions touching tokens are non-human identities in scope. |
| OWASP Agentic AI Top 10 | A-03 | Autonomous or tool-using extensions can act beyond intended human oversight. |
| NIST AI RMF | Accountability for AI-enabled extensions needs governance, monitoring, and incident response. |
Constrain tool access and require runtime checks before any extension can use production secrets.
