Block it when it cannot be tied to an owner, cannot be scoped to a specific action, or introduces code execution and secret exposure without a reviewable control. The decision should be based on the capability's blast radius, not on whether it is popular or convenient for users.
When governance is not enough
Governance works when a skill or plugin can be assigned an accountable owner, constrained to a narrow and reviewable purpose, and monitored in a way that matches its actual blast radius. If you cannot say who is responsible, what it is allowed to do, and how that allowance is enforced, the control is too weak to justify exposure.
That is why the blocking decision is less about convenience and more about control integrity. A small feature that can read secrets, call external services, or execute code may create far more risk than a larger feature with tight scoping and strong review points.
When a plugin sits in that grey area, it should be treated like any other high-trust integration: if the trust boundary cannot be made explicit, the safer choice is to deny it until the design changes.
What makes a skill or plugin safe to permit
A permit decision should rest on three things: ownership, bounded action, and reviewability. Ownership means there is a named team or function accountable for changes and incidents. Bounded action means the capability can only do the one thing the user expects, not a wider set of side effects. Reviewability means the organisation can inspect what it did, why it did it, and whether it stayed within policy.
That usually pushes teams toward a narrower allow list rather than broad approval by category. A plugin that merely enriches a workflow is easier to govern than one that can chain actions across systems, infer user intent, or inherit permissions from a larger runtime context.
For governance to be credible, the permission model must match the real execution path. If the skill can indirectly reach data stores, APIs, or automation hooks, then those downstream paths are part of the control decision, not hidden implementation detail.
Why blast radius should drive the decision
The key question is not whether users want the capability, but how far damage could spread if it is misused, misconfigured, or compromised. A plugin with broad access to data, external calls, or execution privileges can turn a small mistake into a large incident.
Popular tools are often the most dangerous to approve casually because they are reused widely, trusted by default, and rarely re-evaluated once adopted. The right governance test is whether the capability can be safely constrained, not whether it is already part of the workflow.
Where the blast radius cannot be reduced to something the organisation is willing to absorb, blocking is a rational control outcome, not an overreaction.
Risk and Threat Considerations
Skills and plugins become risky when they combine delegated trust with opaque behaviour, because that creates a direct path from convenience to secret exposure, code execution, data leakage, or lateral misuse. The danger is greatest when the organisation cannot independently verify the action boundary or recover cleanly if the capability is abused.
Failure mechanism: An unscoped plugin can overreach its intended purpose, inherit excessive permissions, or trigger side effects that were never visible to the approver, especially when secrets, tokens, or execution hooks are available at runtime.
Impact: A single approval can expose credentials, alter systems, or amplify a compromise across multiple tools and environments, making containment slower and remediation more expensive.
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 OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | Skills and plugins are tool-like capabilities whose misuse must be bounded. |
| ASI03 — Identity & Privilege Abuse | Approval hinges on whether the capability inherits or expands privilege beyond its intent. | |
| Recommendation — Restrict tool actions to the minimum approved capability and block unsafe chained execution. Constrain delegated authority and prevent privilege inheritance that exceeds the approved scope. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Plugins often fail when they can access more secrets or systems than their task requires. |
| Recommendation — Apply least privilege and block capabilities that cannot be narrowly scoped. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The decision depends on whether the plugin's access can be limited to its necessary function. |
| SI-7 — Software, Firmware, and Information Integrity | Plugins that can execute code or alter workflows need integrity controls before approval. | |
| Recommendation — Limit access to the minimum permissions required for the approved action. Validate plugin integrity and block unreviewable code execution paths. | ||
Practitioner Guidance
What to verify: Confirm that the capability has a named owner, a narrow action boundary, and an auditable control point before you consider governance approval. If any one of those is missing, treat the request as a block candidate rather than a candidate for exception handling.
Decision rule: If the plugin can execute code, access secrets, or act outside a clearly defined scope, require redesign or deny it until those paths are constrained. If the capability is useful only because it is broadly empowered, that is usually a sign the design is too risky to permit.
Practitioner takeaway: Approve only what you can bound, explain, and recover from, because governance is effective only when the organisation can prove the control keeps the capability inside a known blast radius.
Related resources from NHI Mgmt Group
- When should organisations block a build for a security finding instead of allowing it through?
- When should organisations block or restrict access to an AI model instead of allowing broad use?
- Why do AI agents make non-human identity governance harder?
- What is the difference between human identity governance and AI agent governance?
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