Subscribe to the Non-Human & AI Identity Journal

Package import execution

A behaviour pattern where code runs automatically when a dependency is imported, not only when a user explicitly launches a program. For identity security, this matters because a trusted package can silently become an execution point that exposes secrets and escalates access across the host.

Expanded Definition

Package import execution describes a dependency behaviour where code runs as soon as a package is imported, before any explicit business logic starts. In NHI and agentic systems, that distinction matters because import time can become an unexpected execution boundary for secret access, network calls, filesystem changes, or privilege checks. The term is not always treated consistently across ecosystems, and usage in the industry is still evolving, especially where package managers blur the line between installation hooks, import hooks, and module side effects.

From a security perspective, the risk is not just that code executes, but that it executes implicitly inside trusted workflows such as build jobs, CI runners, notebooks, or service startup. That makes it adjacent to supply chain compromise, but narrower in scope: the package itself becomes an execution point even without a user calling a function. NIST SP 800-53 Rev 5 Security and Privacy Controls treats software integrity, least privilege, and code provenance as core concerns, which maps directly to this pattern.

The most common misapplication is assuming an imported library is inert, which occurs when engineers review only explicit function calls and ignore module-level side effects.

Examples and Use Cases

Implementing package import controls rigorously often introduces startup and review overhead, requiring organisations to weigh developer convenience against tighter execution governance.

  • A Python package reads environment variables during import and exposes an API token to logging code before the application initialises.
  • A dependency performs outbound telemetry calls at import time, creating unexpected data egress from a CI runner or ephemeral build host.
  • An agent framework loads tools on import and immediately opens filesystem or network handles, expanding the blast radius of a compromised dependency.
  • During incident analysis, teams trace secret exposure to a package that executed code in LiteLLM PyPI package breach-style supply chain behaviour rather than to a direct operator action.
  • Build engineers use NIST SP 800-53 Rev 5 Security and Privacy Controls to require dependency review, pinning, and restricted execution before import in production images.

Why It Matters in NHI Security

Package import execution becomes especially dangerous in NHI environments because service accounts, API keys, and other secrets are often available to the runtime by default. NHIMG reports that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which means import-time code may encounter credentials before any guardrail is applied. In agentic systems, that can allow a trusted library to read a token, call an internal tool, or persist credentials long before a human notices abnormal behaviour. The threat is amplified when imports happen in automation, where reviewers assume the dependency graph has already been trusted.

This is why import-time execution belongs in dependency governance, secret segmentation, and runtime containment, not just in application development review. NIST SP 800-53 Rev 5 Security and Privacy Controls supports this through control families focused on software integrity, least privilege, and monitoring, while the NHIMG guidance on NHI governance and lifecycle management frames the operational need to reduce secret exposure and excessive privilege. Organisations typically encounter this consequence only after a package update, CI failure, or credential leak, at which point package import execution becomes operationally unavoidable to address.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP Non-Human Identity Top 10 NHI-02 Import-time code can expose or misuse secrets through dependency execution paths.
OWASP Agentic AI Top 10 A-03 Agent tool loading and dependency execution can trigger unintended actions at import.
NIST CSF 2.0 PR.DS Protecting data during software execution covers secrets exposed by dependency imports.
NIST SP 800-53 Rev 5 SI-7 Integrity checking supports detection of unauthorized or malicious package behavior.

Treat imported packages as execution surfaces and review secret access before trust is granted.