They often treat skills and plugins as optional add-ons instead of part of the access model. In practice, those extensions determine which secrets the agent can see, which APIs it can call, and which external sources can steer its actions. If the extension layer is weak, the identity boundary is weak.
Why This Matters for Security Teams
Skills and plugins are not convenience features. They are the mechanism that expands an AI agent’s authority, data exposure, and blast radius. Once an extension can read prompts, retrieve secrets, call APIs, or fetch external content, it becomes part of the trust boundary and must be governed like any other privileged workload. That is why current guidance increasingly treats extension governance as an identity and access problem, not a UI problem.
Security teams often miss the fact that a plugin can silently change an agent from a bounded assistant into a tool-using system with chainable access paths. That is especially dangerous when the extension layer touches secrets or third-party services, because visibility tends to be incomplete. NHIMG research on the State of Non-Human Identity Security shows only 1.5 out of 10 organisations are highly confident in securing NHIs, which helps explain why extension governance is still immature.
In practice, many security teams encounter plugin abuse only after an agent has already queried the wrong source, disclosed a token, or triggered an external action that was never part of the original approval.
How It Works in Practice
Good control starts by treating every skill or plugin as a privileged integration with its own identity, policy, and review cycle. The agent should not inherit blanket access just because the core model is trusted. Instead, each extension should be bound to explicit scopes, short-lived credentials, and runtime policy checks that determine whether the agent may use that capability in the current context.
That means separating the identity of the agent from the identity of the extension provider, then evaluating both at request time. A mature implementation usually includes:
- Allowlisting only the skills and plugins that have a documented business purpose.
- Binding each extension to least-privilege scopes for data, tools, and outbound calls.
- Using short-lived tokens or JIT grants rather than standing credentials.
- Logging every prompt-to-tool decision, including what data was exposed to the extension.
- Reviewing whether the plugin can make outbound requests, because external retrieval can become a hidden exfiltration path.
This aligns with the direction of the NIST Cybersecurity Framework 2.0, which emphasizes governed, risk-based control over assets and access paths. It also fits the practical lessons in NHIMG’s JetBrains GitHub plugin token exposure, where extension trust and token handling became the real security issue, not the model itself.
Where teams go wrong is assuming the model can be approved once and the extensions can be bolted on later. These controls tend to break down when plugins can invoke nested tools or call external services with user-derived context, because the original access review no longer matches the real execution path.
Common Variations and Edge Cases
Tighter plugin control often increases operational overhead, requiring organisations to balance developer velocity against the risk of uncontrolled capability sprawl. That tradeoff is real, especially when teams want rapid experimentation with new skills while security wants deterministic access boundaries.
There is no universal standard for extension governance yet, so best practice is evolving. Some environments can safely use a small, curated plugin set with strong pre-approval. Others need more dynamic controls because the agent’s toolset changes by workflow, tenant, or task. In those cases, static approval lists quickly become stale.
Another common edge case is indirect influence. A plugin may not hold secrets itself, but it may fetch content that steers the agent into unsafe behaviour or causes it to request sensitive data from another system. That is why teams should evaluate not only what a skill can access, but also what it can persuade the agent to do. For broader identity and extension risk patterns, NHIMG’s research on the DeepSeek breach is a useful reminder that weak boundaries can turn a feature into an access path.
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 | A2 | Extensions expand agent tool access and attack surface. |
| CSA MAESTRO | T1 | Covers secure orchestration and external tool governance for agents. |
| NIST AI RMF | AI RMF addresses governance of risky AI capabilities and dependencies. |
Review every skill and plugin as a privileged tool path and enforce least privilege at runtime.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
