Join our Newsletter — 33% off our NHI Course

Should organisations treat AI assistant plugins as part of their identity governance programme?

Yes. If a plugin can accept, store, or forward an API key, it is participating in identity and access control, even if it is not a formal IAM system. Organisations should inventory those tools, approve them explicitly, and revoke keys quickly when behaviour is suspicious.

Why AI Assistant Plugins Belong in Identity Governance

AI assistant plugins should be treated as part of identity governance when they can receive, persist, or forward API keys, tokens, or other secrets. At that point they are no longer just convenience features, they are access-bearing components that can change who can act, what can be reached, and how quickly access must be revoked when trust changes.

This is why organisations should inventory plugins alongside other access paths and not leave them to ad hoc approval. A plugin that can call external services with stored credentials is participating in the same control plane as traditional accounts and integrations, even if it is packaged as a productivity add-on.

That framing is consistent with core identity and governance practice in IAM and IGA Basics and Ultimate Guide to NHIs, Lifecycle Processes for Managing NHIs, because the security question is not whether the plugin is “official IAM” but whether it can establish or extend access.

What Changes When a Plugin Can Hold or Forward Credentials

The governance boundary shifts as soon as a plugin can touch a secret. A plugin that only renders content may be low risk, but one that stores an API key, transmits it to a remote service, or uses it to act on behalf of a user needs ownership, approval, scope limits, and revocation procedures.

The practical issue is blast radius. If the plugin is compromised, over-permissioned, or quietly updated, the attacker does not need a separate identity system to create damage, because the plugin already carries the trust needed to reach downstream systems. That is the same reason organisations manage access reviews, rotation, and offboarding for other access-bearing components.

For teams building the control model, Access Reviews and Certification Guide supports the review side of the programme, while Joiner-Mover-Leaver (JML) Guide is the right lens for removing stale access when a plugin, owner, or integration path changes.

How to Classify Plugins Inside the Governance Programme

Classify plugins by the access they can exercise, not by how they are marketed. If a plugin can read a secret from a vault, inject a token into a request, call an API on a user’s behalf, or forward credentials to another service, treat it as an approved integration with an access owner and explicit scope.

  • Inventory each plugin, its owner, and the secrets or tokens it can touch.
  • Define approval criteria before installation, not after deployment.
  • Limit each plugin to the smallest set of systems and scopes it actually needs.
  • Revoke keys quickly when behaviour changes, ownership changes, or the plugin is no longer trusted.
  • Review plugins after updates, because new tool permissions can silently expand access.

Where plugins are part of broader agent or automation flows, Agentic AI Identity Guide helps frame delegation and lifecycle, and Top 10 Agentic AI Identity Issues is useful for understanding how over-trust and shared credentials become control failures.

Risk and Threat Considerations

Plugins expand the attack surface because they can concentrate valuable secrets in a component that users may not inspect carefully. A compromised plugin, malicious update, or abused integration can turn a convenience feature into an authenticated path into production systems, data stores, and SaaS tools.

Failure mechanism: The plugin receives or forwards a key, token, or session material, then uses that trust to act in ways the organisation did not explicitly govern. If the plugin is over-permissioned or poorly inventoried, compromise or misuse can persist until the secret is rotated or the integration is removed.

Impact: Attackers may gain access to downstream systems, exfiltrate data, trigger actions on behalf of users, or bypass normal approval paths. At scale, unmanaged plugins create hidden identity sprawl and make revocation slow precisely when rapid containment matters most.

The threat pattern is familiar in supply-chain and token exposure scenarios, which is why JetBrains Marketplace AI Plugin Campaign and JetBrains GitHub plugin token exposure are both relevant examples of why plugin trust has to be governed like other access-bearing software.

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 SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP Non-Human Identity Top 10 NHI-02 — Secret Leakage Plugins that store or forward API keys create secret exposure risk.
NHI-05 — Overprivileged NHI Plugins with broad API scopes can exceed the access they need.
NHI-07 — Long-Lived Secrets Plugin-stored keys often persist beyond the trust window that created them.
Recommendation — Inventory plugin-held secrets and revoke them immediately when exposure is suspected. Constrain plugin credentials to the minimum scopes needed for each approved function. Replace durable plugin secrets with short-lived credentials where possible and rotate them aggressively.
NIST SP 800-53 Rev 5 IA-5 — Authenticator Management Plugin-held API keys and tokens require lifecycle control, rotation, and revocation.
AC-6 — Least Privilege Plugins should only receive the access needed for their intended functions.
SA-9 — External System Services Plugins act as external or third-party services that need defined trust and controls.
Recommendation — Manage plugin secrets through documented issuance, rotation, and revocation processes. Assign each plugin the minimum permissions needed to perform its approved tasks. Set explicit trust boundaries and contractual controls for plugin-integrated services.
OWASP Agentic AI Top 10 ASI03 — Identity & Privilege Abuse Plugins that act on behalf of users can be abused through delegated access.
Recommendation — Bind plugin actions to explicit authorization and review delegated privileges regularly.
NIST CSF 2.0 ID.AM-02 — Software, Platforms and Applications Are Inventoried Plugins that can access secrets should be inventoried as part of the access estate.
PR.AA-05 — Managed Access Control Plugin access should be approved, bounded, and removed through access controls.
Recommendation — Inventory all plugins that can hold or forward credentials as governed assets. Enforce approval, scope limits, and rapid revocation for plugin access paths.

Practitioner Guidance

What to prioritise: Start with plugins that can store long-lived secrets or call sensitive production APIs. Those are the ones where a compromise creates the largest blast radius and the strongest revocation urgency.

What to verify: Confirm who owns each plugin, which credentials it can access, whether those credentials are scoped narrowly, and whether the plugin can be removed or disabled without breaking the business process. If you cannot answer those questions quickly, the plugin is already under-governed.

Common mistake: Treating plugin approval as a software procurement issue instead of an access governance decision. The right question is not “is this tool useful?” but “what authority does it carry, and how fast can we take that authority away?”

Practitioner takeaway: If a plugin can handle secrets or delegated access, it belongs in identity governance as an access-bearing integration, with inventory, ownership, approval, and fast revocation treated as mandatory controls.