The main failure is that malicious instructions can hide inside a skill that appears legitimate, then execute under the agent’s delegated access. Without manual review of the repository and skill content, users rely on marketplace reputation signals that can be manipulated. That turns installation into a trust shortcut and makes code execution a supply chain problem.
Why This Matters for Security Teams
Unreviewed skills turn agent installation into code execution with delegated trust. The problem is not just whether a skill is useful, but whether it can hide instructions, reach secrets, or trigger tools once the agent loads it. That is why current guidance for agentic systems treats installation-time trust as a security decision, not a convenience feature, as reflected in the OWASP Agentic AI Top 10 and NHI-focused research such as OWASP NHI Top 10.
For AI agents, a skill is not a passive plugin. It can carry prompts, code, configuration, and tool bindings that change the agent’s behavior immediately after installation. If that package is reviewed only by reputation, the reviewer is trusting marketplace signals instead of the actual repository contents. That is a poor fit for systems that can call APIs, read files, chain actions, and operate faster than a human approval loop.
NHI Management Group has highlighted how quickly agent risk becomes operational once access is granted; its AI Agents: The New Attack Surface report shows that 80% of organizations already report agents acting beyond intended scope. In practice, many security teams encounter skill abuse only after an agent has already installed the package and executed the hidden instructions, rather than through intentional pre-install review.
How It Works in Practice
The safest installation process treats each skill as an untrusted artifact until proven otherwise. Current best practice is evolving, but most mature programs now combine repository inspection, dependency review, policy checks, and runtime guardrails before the skill is allowed to influence an autonomous agent. The review needs to focus on what the skill can do, not just what the vendor claims it does.
A practical workflow usually includes:
- Inspecting the repository for concealed prompts, scripts, remote fetches, and post-install hooks.
- Checking whether the skill requests access to secrets, files, identity tokens, or external tools that exceed its stated purpose.
- Scanning dependencies and package integrity, including whether the code is pinned, signed, or reproducible.
- Requiring runtime policy evaluation so the agent can only invoke approved actions in the current context.
- Issuing just-in-time credentials or short-lived tokens rather than long-lived access that persists after installation.
This is where workload identity matters. For autonomous systems, identity should prove what the agent is and what instance is acting, not merely hand it a reusable secret. Frameworks such as the CSA MAESTRO agentic AI threat modeling framework and NIST AI Risk Management Framework both align with this shift toward contextual control and continuous oversight. The point is to prevent a skill from becoming a hidden privilege escalation path once it is installed.
NHI security research reinforces why this matters: the The State of Secrets in AppSec report shows how fragmented secrets handling already weakens control, and AI agents amplify that exposure when they can read or use secrets from installed components. These controls tend to break down when skills are auto-installed into high-trust agent workflows because no one is left with a stable approval boundary after the first execution.
Common Variations and Edge Cases
Tighter skill review often increases deployment overhead, requiring organisations to balance faster agent rollout against the risk of hidden behavior. That tradeoff is real, especially when teams want self-service installation for productivity. There is no universal standard for this yet, so guidance varies across vendors and internal governance models.
Some environments can use lightweight static review for low-risk skills, but that only works when the skill has no tool access, no secret access, and no ability to trigger external side effects. Once a skill can call APIs, move data, or manipulate files, manual review and policy enforcement become much harder to skip. This is especially important in multi-agent systems, where one compromised skill can influence downstream agents and expand blast radius without obvious user action.
Another edge case is open marketplace distribution. Reputation signals, download counts, and publisher badges are not enough when adversaries can ship a clean-looking package and activate malicious behavior only after installation. That is why NHI governance teams should pair repository review with runtime restrictions and incident response hooks. For broader threat context, the NIST AI Risk Management Framework and AI LLM hijack breach analysis both illustrate how quickly trust shortcuts become operational incidents. The standard answer breaks down in highly autonomous environments where skills can be loaded automatically and the agent can execute before a human review ever occurs.
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 CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 | Unreviewed skills can smuggle malicious instructions into agent execution. |
| CSA MAESTRO | I1 | MAESTRO addresses supply-chain and agent trust risks in autonomous workflows. |
| NIST AI RMF | AI RMF applies governance and lifecycle controls to risky agent deployments. |
Review every skill artifact before install and block hidden actions from reaching agent tools.
