How do security teams decide whether skills should be approved like code?

Why This Matters for Security Teams

Skills are not just configuration. When a skill can alter what an agent loads, how it interprets a task, or which systems it can reach, it becomes part of the control plane and should be treated like a governed artefact. That is why teams are increasingly evaluating skills with the same discipline used for code, especially when they affect authorization, data access, or tool chaining. The risk is not abstract: NHI Mgmt Group reports that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs.

Practitioners often miss the fact that a “skill” can bypass normal application review if it is allowed to expand agent behaviour at runtime. A skill that changes retrieval scope, prompts, or downstream API calls can introduce privilege escalation, data exfiltration, or hidden dependency risk. Current guidance from the NIST Cybersecurity Framework 2.0 supports governance, change control, and ongoing risk management, but there is no universal standard yet for skill approval thresholds. In practice, many security teams encounter skill abuse only after an agent has already chained a benign request into an unauthorized action path.

How It Works in Practice

The practical test is whether a skill can influence execution authority. If it changes system reach, access scope, memory behavior, prompt construction, or downstream tool selection, treat it as a controlled release rather than a user convenience. Teams usually define approval requirements around impact, not label. A low-risk formatting helper may only need catalog review, while a skill that can call ticketing, payment, or deployment systems needs formal change control, testing, and rollback.

Security teams are increasingly borrowing release-management patterns from software engineering: ownership, versioning, code review, signing, and traceable approval records. This lines up with the control expectations in the State of Non-Human Identity Security, where weak visibility and over-privilege repeatedly show up as the conditions that make governed lifecycle controls necessary. It also matches the basic warning from the Hard-Coded Secrets in VSCode Extensions: extensions and add-ons can silently carry privileged behaviour into production if they are not reviewed like software.

• Require a named owner for every skill, including a business approver and a technical approver.
• Store the skill definition in version control so diffs, reviews, and rollback are visible.
• Classify skills by blast radius: read-only, limited action, or privileged action.
• Revalidate whenever a skill changes the agent’s tool list, access scope, or system targets.
• Use allowlists for approved sources and block unmanaged side-loaded skills.

For higher-risk skills, many teams also require sandbox testing, security review, and runtime logging that shows which prompt or event triggered execution. That makes it possible to prove what the skill did, not just what it was supposed to do. These controls tend to break down in fast-moving agent marketplaces because skills are often updated faster than security review can keep pace.

Common Variations and Edge Cases

Tighter approval often increases release friction, requiring organisations to balance speed against the risk of hidden capability drift. That tradeoff is real, especially when product teams want to experiment quickly with agent behavior. Best practice is evolving, but current guidance suggests using a tiered model rather than approving every skill the same way.

For example, a read-only skill that summarizes knowledge base content may be governed with lightweight review, while a skill that can invoke SaaS admin APIs should follow full change-management controls. Skills supplied by third parties deserve extra scrutiny because they can introduce dependency risk even when their surface area looks small. The same concern appears in supply-chain incidents such as the Code Formatting Tools Credential Leaks and the JetBrains Marketplace AI Plugin Campaign, where trusted tooling became a delivery path for credential theft.

There is also a gray area around “composable” skills that do not look privileged on their own but become risky in combination. That is why approval should consider the skill plus the agent context, including where the agent runs, what memory it can access, and which tools are already enabled. In security teams that adopt this approach, the real decision is not whether the skill is code in a strict sense, but whether it can change trusted behavior enough to require code-like controls.

Related resources from NHI Mgmt Group

• How do security teams decide whether to keep Cognito-like tools in scope?
• How should security teams decide whether an identity-related code finding is actually exploitable?
• How should teams decide whether an AI control plane needs to stay self-hosted?
• How do security teams know whether a processing worker’s access scope is too broad?