Teams need a combination of endpoint discovery and instruction inspection. Discovery tells you what is installed, while instruction review reveals whether the skill tells the agent to ignore guardrails, collect workspace data, or route information externally. Detection is only useful if it feeds a blocking decision before execution.
What makes an agent skill unsafe before it ever runs?
An unsafe skill is usually visible in its instructions, metadata, or packaging before execution. The key question is whether it asks the agent to bypass guardrails, overreach on access, harvest more data than needed, or send outputs to an unexpected destination. That is why detection has to look at both what is installed and what it instructs the agent to do.
Skills become risky when they encode hidden authority. A skill that looks harmless at the title level can still instruct the agent to ignore policy, reuse credentials, or chain into external services. Security teams should treat the skill bundle as executable guidance, not documentation, because its text can directly shape agent behaviour.
Unsafe patterns are easiest to spot when they are specific, not vague. Watch for instructions that widen scope, such as “collect workspace context,” “use any available token,” “continue even if blocked,” or “forward results to this endpoint.” Those are practical warning signs because they change the agent’s decision boundary, not just its workflow.
How should teams inspect skills for dangerous instructions?
Start with inventory, then move into instruction review. Discovery tells you which skills exist across endpoints, repos, marketplaces, or shared folders; inspection tells you whether those skills embed policy bypass, data over-collection, or external exfiltration paths. In practice, teams need both a catalog and a parser, because manual review alone will miss drift once the skill set scales.
Review the parts of a skill that actually alter runtime behaviour: prompts, helper steps, tool references, environment assumptions, and any “fallback” logic. Pay special attention to phrasing that grants broad discretion to the agent or treats guardrails as optional. For agent skill security, the instruction layer matters as much as the code layer, because a skill can be harmful even when its implementation is technically valid.
Detection works best when it is normalized around known bad patterns. A team should define what counts as unsafe instruction wording, what metadata fields must be checked, and which destinations require review before the skill is approved. The OWASP Agentic Skills Top 10 (AST10) is useful here because it frames the skill layer as a distinct security surface, including permission inheritance and credential exposure through skill chains.
How do you stop a dangerous skill from spreading?
Detection has to feed a blocking decision before the skill is executed or copied into wider use. That usually means gating installation, approval, or publishing through a control point that can quarantine the skill, revoke access to it, or stop the agent from loading it at all. If a team only labels the skill after execution, the control has already failed.
Spread is often an operational problem as much as a security problem. Once a skill is shared across teams, imported into templates, or bundled into a common agent profile, its instruction set can replicate faster than human review can keep up. Blocking therefore needs to happen at the distribution point, not just at the endpoint where the skill first appears.
Practically, this is where discovery, review, and enforcement should meet. The Shadow AI and AI Agent Discovery Guide is relevant because it treats discovery as a governance input, while the AI Agent Observability, Audit and Incident Response Guide shows how detection should connect to attribution, alerting, and kill-switch decisions.
Risk and Threat Considerations
Unsafe skills create two main risks: they can quietly expand an agent’s effective privilege, and they can turn a trusted workflow into a data leakage path. The danger is not limited to malicious uploads; a poorly written skill can produce the same effect by normalizing overbroad access or external disclosure.
Failure mechanism: The skill instructs the agent to override safeguards, inherit excessive permissions, or route sensitive context to a third party before any human review can intervene.
Impact: Sensitive workspace data, credentials, or business content can be exposed, and the same skill can spread across reused agent configurations before the issue is noticed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10, OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 define the specific risk controls and attack patterns relevant to this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API6 — Unrestricted Access to Sensitive Business Flows | Unsafe skills can steer agents into unauthorized data and workflow paths. |
| Recommendation — Block skills that can trigger sensitive flows without explicit review and authorization. | ||
| OWASP Non-Human Identity Top 10 | NHI-10 — Human Use of NHI | Skill instructions often abuse human-trusted agent access and inherited authority. |
| NHI-05 — Overprivileged NHI | Unsafe skills commonly rely on excessive permissions to widen agent impact. | |
| Recommendation — Prevent skills from leveraging human trust to expand agent actions beyond approved scope. Audit skill-linked identities for excessive privilege before allowing execution. | ||
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | Unsafe skills can instruct agents to misuse tools or chain actions unexpectedly. |
| ASI03 — Identity & Privilege Abuse | Unsafe skills often exploit agent authority and guardrail bypass. | |
| Recommendation — Inspect skill instructions for tool misuse and block unapproved tool invocation paths. Enforce per-action authorization when skills can alter agent privilege or identity use. | ||
Practitioner Guidance
What to verify: Verify that every skill has a declared owner, an approved distribution path, and a reviewable instruction set. If a skill cannot be tied to an owner and a change record, treat it as untrusted until proven otherwise.
Decision rule: If a skill can influence tool use, data access, or outbound communication, require pre-execution blocking controls, not just logging. If it only describes a benign UI convenience, it still needs review once it can alter agent behaviour or data flow.
What to prioritise: Prioritise skills that can touch shared workspaces, privileged connectors, or external network destinations. Those are the places where a single unsafe instruction can produce broad blast radius.
Practitioner takeaway: The real control point is not whether a skill looks useful, it is whether its instructions can silently change what the agent is allowed to see, do, or disclose before anyone notices.
Related resources from NHI Mgmt Group
- How can security teams detect release storms before they spread?
- How should security teams detect AI agent escapes in Kubernetes before they reach the host or control plane?
- How should security teams detect unsafe Bash patterns in CI before they reach production scripts?
- How should security teams detect crypto miner botnets on Linux endpoints before they spread laterally?