Governance breaks at the point of capability inheritance. The organisation loses track of what the agent can do, who approved it, and which systems it can reach, so review, accountability, and least privilege all become unreliable. That is why unapproved skills and plugins should be treated as controlled execution paths, not convenience features.
How central approval preserves skill inheritance
When skills and plugins are added outside a central approval path, the agent inherits capabilities that were never reviewed as a set. That matters because the approval point is where the organisation decides whether the new capability fits the intended use case, trust boundary, and operating model. Without that gate, the agent’s effective authority can expand faster than governance can track it.
Approval is not just a paperwork step. It is where teams define what the added capability may touch, what data it may see, and whether its behaviour is acceptable in the production environment. If that decision is skipped, the organisation may still own the agent, but it no longer fully owns the operational consequences of the agent’s toolchain.
A useful way to think about this is that the central approval process establishes the baseline the agent is allowed to inherit. The AI Governance Guide is most relevant where teams need a formal use-case register, approval roles, and human oversight around AI system changes.
What governance fails first
The first break is usually inventory and accountability. Once plugins or skills are introduced locally, the organisation may not have an accurate record of which capabilities exist, who introduced them, and which environments they can affect. That makes review inconsistent, because the control owner cannot reliably assess the full set of reachable actions.
The next break is least privilege. A skill or plugin often arrives with implicit trust, inherited permissions, or broad access to the agent’s context and tools. That can turn a narrowly intended automation into a much wider execution path, especially if the plugin can read data, invoke systems, or chain into other tools without a separate approval decision.
Governance teams should treat this as a lifecycle issue, not a feature request issue. The control objective is to keep the approved capability set visible and bounded, which is why the AI Agent Tool and Plugin Security Guide is a natural companion for understanding scoped permissions, validation, and plugin security.
Why unapproved plugins create operational and security exposure
Unapproved skills and plugins create two kinds of exposure at once: they weaken the management model and they widen the attack surface. Even if the plugin is introduced for convenience, it can become a hidden route to sensitive systems, secrets, or data flows that were never meant to be reachable from the original agent design.
The practical problem is that control failures become harder to distinguish from intended behaviour. If a plugin can invoke external services, transform prompts, or pull in third-party code, then a compromise can look like normal automation unless the organisation has explicit approval, logging, and change control around that extension point.
This is also where central governance and technical control need to meet. The AI Governance Guide helps with ownership and approval structure, while OWASP Agentic Skills Top 10 (AST10) highlights the risk of permission inheritance and malicious or unsafe skill behaviour in the skill layer.
Risk and Threat Considerations
When skills and plugins bypass central approval, the main risk is not just configuration drift. It is trust expansion without corresponding oversight, which can expose data, widen privileges, and allow a malicious or poorly designed extension to act inside a path that defenders assume is controlled.
Failure mechanism: The agent inherits capability from the added skill or plugin before governance, inventory, and privilege review can constrain it, so the organisation loses the ability to prove what was approved, what was inherited, and what systems became reachable.
Impact: Review becomes unreliable, privilege boundaries blur, and a compromised or unsafe extension can create unauthorised access, data exposure, or downstream abuse that is difficult to attribute quickly.
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 addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Unapproved skills can inherit and expand agent privilege. |
| ASI02 — Tool Misuse | Plugins extend tool access and can be misused outside approval. | |
| Recommendation — Scope and review agent permissions before adding any skill or plugin. Validate each tool action and restrict it to approved use cases. | ||
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | Adding plugins outside approval is an uncontrolled configuration change. |
| AC-6 — Least Privilege | Inherited plugin permissions can exceed intended access. | |
| Recommendation — Require formal change approval for every agent capability addition. Limit each extension to the minimum permissions it needs. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Plugins alter the approved configuration of the AI environment. |
| Recommendation — Track and approve extensions as controlled configuration items. | ||
Practitioner Guidance
What to verify: Confirm that every skill or plugin has an owner, an approval record, a scoped permission set, and a clearly defined removal path. If any of those are missing, treat the capability as ungoverned until the control gap is closed.
Common mistake: Teams often approve the agent platform but not the extension layer. That leaves the most dynamic part of the system outside the review process, even though it is often the part that changes the agent’s real authority.
Decision rule: If the extension can change what the agent can access, execute, or disclose, require central approval before deployment and reapproval when its permissions or integrations change.
Practitioner takeaway: The central question is not whether the skill or plugin is useful, but whether the organisation can still explain and defend the agent’s inherited capabilities after it is installed.
Related resources from NHI Mgmt Group
- What breaks when agent skills are added without central governance?
- What breaks when AI agents can chain skills without fresh approval?
- What breaks when AI agent approval is added too late in the authorization flow?
- What breaks when AI agents are added to joiner workflows without ownership and approval?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org