The approval model breaks because users think they are authorising one package, but the runtime can pull in a second payload with different behaviour. That creates an invisible trust expansion. Security teams should require post-install inspection, dependency provenance checks, and runtime containment for any skill that can modify its own execution path.
Why This Matters for Security Teams
Hidden dependencies turn a simple approval into a moving target. A team may review one ai skill, approve one package, and then inherit additional code paths, permissions, or network behaviour that were never visible at decision time. That is not just a software supply chain issue. It is an identity and trust problem, because the runtime can expand what the skill can do after the original review.
Current guidance from the NIST Cybersecurity Framework 2.0 still applies here, but it needs to be applied to dynamic execution rather than static inventory. NHIMG research on the State of Secrets in AppSec shows how fragmented controls and weak developer practices make it easy for sensitive material to escape normal oversight. The same pattern appears when AI skills are allowed to resolve, fetch, or execute dependencies after approval. In practice, many security teams encounter the hidden payload only after the skill has already executed with broader effective trust than was reviewed.
How It Works in Practice
The failure starts with the assumption that approval equals containment. In reality, an AI skill may download packages, invoke toolchains, or hydrate modules at runtime based on prompts, environment state, or model output. If those downstream components are not predeclared, the original approval no longer matches the actual execution path. That is why post-install inspection matters: the control point must move from “was the package approved?” to “what code, secrets, and network actions are now present?”
For AI and agentic systems, this aligns with the broader shift described by OWASP Top 10 for Large Language Model Applications and NIST AI governance guidance. NHI Management Group recommends treating every skill as a workload with an evolving trust boundary. That means:
- Require dependency manifests before approval, then verify the installed tree after deployment.
- Use provenance checks for packages, including signed artifacts where available.
- Block or sandbox any skill that can self-modify, fetch new modules, or execute opaque installers.
- Apply runtime containment so new dependencies cannot inherit unrestricted access to secrets, APIs, or internal networks.
- Log dependency resolution events separately from normal application logs for forensic review.
Where possible, pair this with workload identity and policy evaluation at request time. The issue is not only malicious code, but also behaviour drift caused by legitimate updates that change capability without changing the approval record. NHIMG coverage of the DeepSeek breach illustrates how quickly exposed components and embedded secrets can become operational risk when code paths are not tightly governed. These controls tend to break down in environments that allow runtime package installation from the public internet because dependency state becomes non-deterministic.
Common Variations and Edge Cases
Tighter dependency control often increases build friction, so organisations need to balance safety against developer velocity. Best practice is evolving, and there is no universal standard for how much runtime flexibility an AI skill should retain. The right answer depends on whether the skill is read-only, tool-using, or allowed to modify its own execution path.
Some edge cases are especially difficult. A skill that loads plugins from a private registry may look safe in review but still inherit risk if registry trust is weak. A skill that installs a dependency only under rare prompt conditions may evade pre-production testing. And a skill that uses generated code or just-in-time tool assembly can bypass static allowlists entirely. In those cases, static approval is a poor proxy for actual exposure.
Security teams should treat the following as warning signs:
- Approval based only on package name or version.
- Hidden transitive dependencies pulled from multiple registries.
- Skills with permissions to write, install, or execute secondary code.
- Long-lived credentials available during dependency fetch or install.
Where an AI skill can change its own dependency graph, the trust model must assume that execution can outgrow approval. That is where current governance most often fails.
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, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 | Hidden dependencies change agent behaviour after approval. |
| CSA MAESTRO | A2 | MAESTRO addresses dynamic agent trust and tool expansion. |
| NIST AI RMF | AI RMF covers governance for unpredictable model-driven behaviour. | |
| OWASP Non-Human Identity Top 10 | NHI-05 | Secondary dependencies often introduce new secrets exposure paths. |
| NIST CSF 2.0 | PR.DS-1 | Runtime installs can expose data and credentials unexpectedly. |
Scan installed components for secrets access and restrict secret reachability.
