TL;DR: AI agent skill marketplaces now carry the same supply chain risk pattern as software packages, but static code checks and LLM-based review both miss malicious behavior that only appears at runtime, according to Permiso Security. Runtime detonation is becoming the deciding control because executable trust cannot be inferred from code alone.
At a glance
What this is: Permiso Security argues that static code scanning and LLM-based review miss runtime-only malicious behavior in AI agent skills, so controlled execution is needed to see what a skill actually does.
Why it matters: This matters because AI agent skills inherit existing agent permissions, so IAM, PAM, and NHI teams need controls that evaluate behavior at execution time, not just code at rest.
By the numbers:
- One industry audit found over 1,100 malicious skills on a single marketplace.
Context
AI agent skill marketplaces are creating a new identity security problem: downloadable capability packages can execute with the permissions already granted to the agent. Static review cannot tell whether a skill will behave safely once it inherits those IAM roles, API tokens, and service connections.
The security gap is not just code quality, but runtime trust. If a skill can make network calls, access environment variables, or exfiltrate data only after execution begins, then source-based screening is looking in the wrong place.
Permiso Security frames this as the same supply chain pattern defenders learned in software and malware analysis, but with agent identities and delegated access amplifying the blast radius.
Key questions
Q: What fails when AI agent skill scanners only inspect source code?
A: They miss behaviors that appear only during execution, such as unauthorized network calls, file writes, credential access, or data exfiltration. A skill can look clean in review and still act maliciously once it runs with the agent's inherited permissions. That is why source review alone is not a trust decision for agent skills.
Q: Why do AI agent skills create supply chain risk in enterprise environments?
A: AI agent skills create supply chain risk because they can look harmless in review while delivering malicious behavior only when executed. If an agent accepts untrusted content and acts on it, attackers can hide instructions, pull payloads from remote servers, or abuse the agent as a dropper. The risk grows when organisations rely on popularity or static checks as proof of safety.
Q: How should security teams validate AI agent skills before installation?
A: They should execute each skill in a controlled sandbox with real agent context and inspect actual behaviour, not just source code. The review should cover tool calls, file access, DNS resolution, outbound traffic, and credential access attempts before the skill is allowed to inherit production permissions. Behavioral evidence is the only reliable trust signal for downloaded skills.
Q: What breaks when organisations rely only on static analysis for AI agent skills?
A: Static analysis breaks down because it can only inspect what is written, not what happens at runtime. Hidden links, delayed instructions, self-reinstalling behavior, and remote payload retrieval can all remain invisible until the skill is executed. That creates false confidence, delayed detection, and missed opportunities to block persistence or exfiltration before deployment.
How it works in practice
Why static skill scanning misses runtime-only abuse
Static scanning inspects code signatures or asks an LLM to judge likely intent, but neither method executes the skill. That matters because malicious behavior often emerges only when the skill interacts with tools, environment variables, network destinations, and inherited permissions. In an AI agent context, the object being assessed is not just code quality, but the actual behavior of an identity-enabled runtime. A source file can look harmless and still perform unauthorized web requests, file access, or exfiltration once the agent invokes it.
Practical implication: security teams need an execution-time control for agent skills, not only pre-installation review.
What dynamic sandbox detonation adds to agent skill validation
Dynamic detonation runs the skill inside an instrumented environment and observes the full action chain. That gives defenders evidence at both the LLM and operating-system levels, including network calls, DNS resolution, file writes, credential access attempts, and encrypted outbound traffic. For AI agent skills, this is closer to how malware sandboxes work than how traditional code review works. The important shift is from inferring intent to measuring behavior under real execution conditions.
Practical implication: use sandbox-based detonation when a skill can change state, reach external services, or touch secrets during execution.
Why agent identity turns skills into a supply chain risk
A skill does not arrive with its own identity. It inherits the agent's permissions, which means marketplace distribution becomes a software supply chain problem with identity consequences. If the installed skill is malicious, the attack does not require credential theft first because the agent already holds the access. That is why agent skills sit at the intersection of NHI governance and supply chain validation: the package is distributed like software, but it executes like an identity-backed workload.
Practical implication: treat skills as governed runtime artefacts, with the same scrutiny you would apply to privileged NHI-enabled code paths.
NHI Mgmt Group analysis
Runtime validation is now the governing control for AI agent skills: static review can reduce obvious risk, but it cannot prove what a skill will do once it inherits live permissions. The decisive question is no longer whether the code looks suspicious, but whether the skill produces unsafe behavior when executed against real tools and data. Practitioners should treat execution evidence as the primary trust signal.
Agent skill marketplaces have become a supply chain layer, not a code repository: downloadable skills are distributed like software but operate with the agent's identity and access scope. That means a compromise does not need to defeat authentication first, because the access path is already provisioned. The governance model has to follow the runtime, not the package format.
Observed behavior beats inferred intent in this category: LLM-based review fails for the same reason prompt-driven systems are easy to manipulate, namely that judgment about code is not the same as watching the code run. The industry needs to stop confusing model confidence with security evidence. The practical conclusion is that identity-backed execution paths need detonation-grade inspection before installation.
Dynamic sandboxing is the right named control concept for this problem: a sandbox that records LLM actions, OS events, network traffic, and file activity turns agent skill validation into a forensic decision rather than a probabilistic one. That is the correct pattern for AI agents because their behavior can change at runtime under inherited access. Security teams should align their evaluation process to behavioral evidence, not source-level inference.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: AI Agent Observability, Audit and Incident Response Guide
What this signals
Runtime detonation is the right boundary for agent skill trust: security programmes that stop at code review are assuming that safe-looking source predicts safe runtime behavior. That assumption fails when the skill can inherit agent permissions and interact with tools only after installation.
AI agent skills should be governed like identity-enabled software supply chain artefacts: the package is not the risk by itself, but the access it activates is. Teams need to align review, approval, and observability around execution, because the dangerous action is often invisible until the skill is already running.
For practitioners
- Define runtime approval gates for agent skills Require every downloadable skill to pass a controlled execution check before it can be installed into an agent workflow or internal skill registry.
- Instrument skill execution with behavioral evidence Capture LLM actions, network calls, DNS resolution, file access, and environment variable reads so security reviewers can verify what the skill did, not what it claimed to do.
- Separate skill review from source review Do not treat static code analysis or LLM judgment as a complete trust decision when the skill can act on live credentials, APIs, or internal services.
- Scope inherited permissions before deployment Inventory which agent roles, tokens, and service connections would be available to each skill so that high-risk access paths are not exposed by default.
- Maintain a searchable verdict history for submitted skills Keep prior analysis results so repeat submissions can be compared against earlier behavioral findings and so risky packages can be rejected consistently.
Key takeaways
- AI agent skills inherit the access of the agent that installs them, so marketplace distribution becomes an identity-backed supply chain risk.
- Permiso Security cites an audit finding of over 1,100 malicious skills on a single marketplace, showing that the problem is already present at scale.
- Static scanners and LLM-based review are insufficient on their own because only runtime detonation can prove what a skill actually does.
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, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST AI RMF sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | Agent skills can misuse tools and services only at runtime, which is the core risk here. |
| Recommendation — Validate agent skills in execution so unauthorized tool use is detected before deployment. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Marketplace skills behave like third-party NHIs that can bring hidden runtime risk into the environment. |
| NHI-05 — Overprivileged NHI | Installed skills inherit agent permissions, creating overprivileged execution paths by default. | |
| Recommendation — Treat third-party skills as governed non-human identities and require runtime validation before trust is granted. Review inherited permissions for each skill and remove unnecessary access before activation. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The article describes skills accessing credentials and exfiltrating data at runtime. |
| Recommendation — Map malicious skill behavior to credential access and exfiltration detections in your threat hunting pipeline. | ||
| NIST AI RMF | MANAGE — AI Risk Management | The topic is about governing AI system risk across the lifecycle of agent skill execution. |
| Recommendation — Apply AI risk controls to gate, monitor, and review agent skill execution before production use. | ||
Key terms
- Agent Skill: A reusable package of task-specific knowledge and procedures that an autonomous agent can load when needed. In practice, it separates general awareness from operational detail, which makes enterprise context easier to govern than a single oversized prompt.
- Dynamic Sandbox Detonation: A validation method that runs software inside a controlled environment and records what it actually does. For AI agent skills, it is the behavioural test that observes tool use, network calls, file activity, and credential access rather than inferring safety from source code alone.
- Runtime Trust: Runtime trust is the idea that access should remain valid only while current context justifies it. Instead of trusting a setup decision indefinitely, teams continuously re-evaluate whether a workload or agent still deserves privilege. This approach is especially important for AI agents that can change behaviour mid-task.
- Inherited Permissions: Inherited permissions are access rights passed from the authorizing user or application to a connected integration. They become risky when the granted scope is broader than the integration needs, because the downstream app can retain high privilege long after the original business need has changed.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 23, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org