Who is accountable when one plugin steals another plugin’s API keys?

Why This Matters for Security Teams

When one plugin steals another plugin’s api key, the failure is rarely just “a bad extension.” It is a governance and containment problem that spans approval, secret scope, runtime isolation, and revocation. In extension ecosystems, the platform owner decides whether plugins can read shared secrets, inherit host privileges, or access one another’s storage. That makes accountability operational, not merely forensic.

This is why NHI governance has to treat plugin identities as distinct workloads, not as interchangeable add-ons. If one extension can decrypt another’s tokens, the environment has effectively collapsed least privilege at the identity layer. Current guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls still applies, but practitioners need to map it to extension trust boundaries and secret brokerage, not only to human admin access.

NHIMG research on the JetBrains Marketplace AI Plugin Campaign shows how quickly a trusted extension channel can be abused when plugins are allowed to overreach their intended scope. In practice, many security teams discover shared-secret exposure only after the plugin ecosystem has already been used as the lateral movement path.

How It Works in Practice

The accountable party is the platform owner, because only the platform can define the rules that make cross-plugin theft possible or impossible. That means the security model has to separate plugin identity, plugin permissions, and secret access paths. A plugin should authenticate as its own workload, use only the secrets explicitly assigned to it, and receive short-lived access based on task context rather than standing entitlement.

Operationally, that usually means combining workload identity, secret vaulting, and runtime policy checks. The most effective pattern is to issue per-plugin or per-task credentials, enforce vault-level binding between secret and plugin identity, and deny direct secret read access between extensions. This aligns with the direction of the SPIFFE workload identity model, where the identity of the workload, not the container or host, becomes the basis for authorization.

For teams evaluating controls, the practical checklist is straightforward:

• Assign each plugin a unique workload identity and prohibit shared decryption keys.
• Scope API keys to one plugin, one tenant, or one function whenever possible.
• Use just-in-time issuance and automatic revocation instead of long-lived static secrets.
• Evaluate access at request time using policy as code rather than fixed allowlists alone.
• Log secret access, token exchange, and inter-plugin calls as separate events.

NHIMG’s Guide to the Secret Sprawl Challenge and BeyondTrust API key breach both reinforce the same lesson: once secrets are broadly readable, the trust boundary is already broken. These controls tend to break down in plugin platforms that share a single runtime, a single secret store, or a single service account because isolation is then only logical, not cryptographic.

Common Variations and Edge Cases

Tighter plugin isolation often increases development and operational overhead, requiring organisations to balance faster extension onboarding against stronger containment. There is no universal standard for this yet, especially for marketplaces, desktop add-ins, and agentic plugin frameworks that mix first-party and third-party code.

One common edge case is a plugin that does not steal keys directly but abuses a host-provided token broker or cache. Another is a “helper” plugin that inherits permissions from a more privileged extension and becomes the easiest route to exfiltration. In those cases, accountability still sits with the platform governance process, because the architecture allowed privilege inheritance without meaningful separation.

Best practice is evolving toward intent-based authorization, secret scoping by workload identity, and runtime attestation for high-risk extensions. NHIMG’s Moltbook AI agent keys breach is a useful reminder that exposed or overbroad keys are rarely a single-point failure. They are usually the result of weak boundaries, weak revocation, and weak accountability all at once.

Related resources from NHI Mgmt Group

• How should security teams govern API keys used for generative AI access?
• What problem does ownership attribution solve for service accounts and API keys?
• What challenges do unmanaged API keys pose within MCP?
• Why do Lumos alternatives look so different from one another?