A chatbot is usually the visible interface, but a skill or plugin changes what the agent can actually do. It can expose secrets, run code, and reach internal systems, often without passing through the same approval checkpoints that would govern a normal application. The risk is broader because the capability is attached where the work happens.
Why unapproved skills and plugins change the risk model
The key difference is not visibility, it is delegated capability. A chatbot can be watched, but a skill or plugin often expands what the agent can read, send, execute, or trigger. That means the real control point shifts from the chat surface to the permissions, data paths, and trust assumptions behind the extension.
Once a skill is attached, it can become a shortcut around normal review, especially when it is introduced by a user, developer, or third party without the same approval and inventory process as a standard application. The result is a larger attack surface, because the agent may be able to touch internal systems and sensitive data through a component that was never treated as a full production dependency.
How plugins create hidden exposure even when the chatbot looks harmless
A visible chatbot is easy to notice, instrument, and restrict. A skill or plugin is different because it can act as an embedded capability inside the workflow, where users assume the agent is simply “helping” rather than carrying out a privileged action. That is why unapproved additions can expose secrets, generate unintended requests, or chain into internal tools in ways the front-end conversation does not make obvious.
The risk also grows when the plugin inherits trust from the agent itself. If the system treats the skill as part of the assistant experience, the user may never see a separate security boundary even though the extension can reach authentication material, internal APIs, or external services. This is the same pattern that makes tool-layer abuse dangerous in agentic systems, where the harmful action is not the chat response but the action behind it.
For a deeper view of that control gap, see the AI Agent Tool and Plugin Security Guide, which focuses on tool permissions, validation, and plugin abuse paths.
What makes unapproved skills more dangerous than approved integrations
Approval matters because it forces someone to answer basic questions before the capability is live: what data can it access, what can it invoke, what secrets does it need, and what happens if it is compromised. Unapproved skills often skip that discipline, so the system ends up with opaque permissions, weak provenance, and no reliable owner for revocation or review.
The most dangerous cases are the ones that look small. A plugin that only formats output may still be able to read prompt context, call downstream services, or relay sensitive tokens if the platform grants broad access by default. In practice, the security issue is not whether the skill is visible in a UI. It is whether the capability has been bound to the agent with enough authority to cause material harm.
If the question is how the visible chatbot relates to a wider agentic risk profile, the AI Agents vs Agentic AI guide is useful because it separates the interface from the action layer.
What practitioners should verify before allowing a skill or plugin
Practitioners should treat every new skill as a privilege change, not as a cosmetic extension. The first check is whether the plugin can access secrets, session material, internal APIs, or code execution paths, because those are the points where a simple assistant becomes an execution channel. The second check is whether the capability is approved, inventoried, and owned like any other production dependency.
At scale, the hard part is not adding controls one by one, it is maintaining visibility into which skills are active, which data they can touch, and which approvals they bypassed. That is why governance, inventory, and risk tiering belong around the agent ecosystem, not just around the chat interface. A visible chatbot can still be the least risky part of the system.
AI Governance Guide helps frame that ownership problem in terms of use case registers, oversight, and decommissioning.
Risk and Threat Considerations
Unapproved skills and plugins widen the blast radius because they can turn a conversational interface into an execution path. The main risk is not the text the chatbot returns, but the privileged actions the attached capability may perform behind the scenes, often with weak visibility and incomplete approval history.
Failure mechanism: A malicious or poorly reviewed plugin inherits agent trust, then uses that trust to read context, exfiltrate secrets, call internal systems, or trigger actions that would normally require separate authorization and review.
Impact: The organisation can lose confidential data, create unauthorized system changes, and expose internal services through a capability that users perceive as low risk because it appears inside a familiar chatbot experience.
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 expand tool use and can be misused through the agent. |
| ASI03 — Identity & Privilege Abuse | Unapproved plugins can inherit excessive authority from the agent. | |
| Recommendation — Restrict tool actions to approved scopes and validate every tool invocation. Bind each agent capability to least privilege and separate human approval from runtime authority. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Plugins often act through non-human credentials or delegated access with excess privilege. |
| NHI-03 — Vulnerable Third-Party NHI | Third-party plugins create supplier risk when they can reach secrets or systems. | |
| NHI-02 — Secret Leakage | Plugins can expose tokens, keys, or other secrets through tool access or context. | |
| Recommendation — Audit plugin credentials for excess access and remove any privilege not strictly required. Assess third-party plugins before deployment and monitor their access paths continuously. Prevent plugins from reading or exporting secrets unless that access is explicitly required. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Plugin actions often depend on service-to-service or workload authentication. |
| AC-6 — Least Privilege | The core issue is a capability that can do more than the chatbot surface suggests. | |
| Recommendation — Use strong service authentication for every plugin integration and rotate credentials on compromise. Limit each plugin to the minimum actions and data it needs to function. | ||
Practitioner Guidance
What to prioritise: Treat plugin onboarding, permission scope, and revocation as the control plane. If a skill can touch secrets, code, or internal APIs, require the same ownership, approval, and removal discipline you would apply to a privileged integration.
What to verify: Confirm whether the plugin can access prompt context, tokens, file contents, or internal endpoints, and whether those permissions are narrowly bounded. If the answer is unclear, do not treat the capability as safe just because the chatbot itself looks benign.
Practitioner takeaway: The chatbot is only the interface, the risk lives in the attached capability, so security decisions must follow the permissions and trust boundary where the work actually happens.