How should security teams handle packages that resolve control endpoints at runtime?

Why This Matters for Security Teams

Packages that resolve control endpoints at runtime sit in a risk class closer to remote administration than ordinary dependency management. The package hash may remain stable while the operator can silently redirect data flow, alter control planes, or change the location of executable content after approval. That creates a supply chain problem that static scanning alone will not catch, especially when the endpoint is fetched from a mutable source such as a config service, DNS record, or externally editable object.

This matters because security teams often evaluate packages as if integrity is fixed at install time. For runtime-resolved endpoints, integrity depends on what the package does after installation. That shifts the control question from "is this package authentic?" to "can the package be induced to talk to an untrusted target, and can that target change without review?" NIST guidance on software and access controls supports treating dynamic trust boundaries as a governance issue, not just a build issue, and the Ultimate Guide to NHIs — Standards is explicit that non-human control paths need lifecycle oversight, not one-time approval. In practice, many security teams discover the problem only after a package has already been repointed to an unexpected endpoint, rather than through intentional review.

How It Works in Practice

The safest way to handle these packages is to treat runtime endpoint resolution as an exception pattern that requires explicit governance. The package should be inventoried as a high-risk dependency, then classified by what it can reach, what it can execute, and whether that destination can be changed by someone outside the organisation. If the package fetches code, configuration, or policy from a mutable location, it should be blocked from production build paths unless there is a documented business need and a compensating control set.

Good practice is to combine provenance checks with runtime restraint. Provenance attestation can help verify where the package came from, but it does not prove where it will connect later. That is why NIST SP 800-53 Rev 5 Security and Privacy Controls matters here: access enforcement, configuration management, and monitoring need to extend beyond the artifact to the network path and the execution context. For teams managing NHI-heavy pipelines, the LiteLLM PyPI package breach is a useful reminder that package trust can fail after publication when behaviour or routing changes.

• Require approval for any package that downloads executable content or live configuration from an externally editable source.
• Pin destinations where possible, and restrict outbound egress to approved domains, IP ranges, or service identities.
• Separate build-time dependencies from runtime control channels, and do not let production builds inherit mutable control endpoints.
• Log endpoint changes, not just package installs, so repointing events are visible in change review and incident response.
• Quarantine packages that depend on external editability until the trust boundary is reviewed by security and platform owners.

These controls tend to break down in highly dynamic environments such as ephemeral test clusters and agentic execution platforms because destination churn makes allowlisting difficult without stronger workload identity and policy enforcement.

Common Variations and Edge Cases

Tighter endpoint control often increases operational overhead, requiring organisations to balance release velocity against the risk of hidden redirection. That tradeoff is real, especially when a package legitimately needs to poll a control plane, load feature flags, or retrieve tenant-specific policy.

Current guidance suggests handling those cases with compensating controls rather than blanket trust. For example, a package may be allowed to resolve endpoints at runtime only if the destination is bound to a signed manifest, a controlled service registry, or a narrowly scoped internal control plane. If the endpoint is user-editable, public, or governed by a third party, the package should be treated as untrusted until the control path is isolated. This is where NHI governance and software supply chain control overlap: the package is not just a dependency, it is also a remote actor with execution reach.

Edge cases include legitimate multi-tenant products, canary systems, and agent workflows that switch tools on demand. In those environments, the right question is not whether runtime resolution exists, but whether each resolution is authenticated, authorized, and logged. The State of Non-Human Identity Security shows why this matters: organisations already struggle with visibility into non-human access, and dynamic endpoints make that gap worse. Best practice is evolving, but there is no universal standard for this yet: the practical bar is to make endpoint mutation explicit, reviewable, and reversible.

Related resources from NHI Mgmt Group

• How do security teams know whether exposed legacy services are actually under control?
• Why are NHIs a critical concern for security teams?
• What steps should security teams take to prevent Shadow AI risks?
• Why is the abuse of NHIs a priority for security teams?