Install-time identity exposure

Expanded Definition

Install-time identity exposure occurs when a package, extension, or dependency can execute code during installation or import and can read credentials that were meant for a trusted runtime. That includes API keys, tokens, certificates, cloud metadata access, CI variables, and automation secrets available too early in the delivery chain.

In NHI security, the issue is not simply that a dependency exists. The risk begins when the package manager, build hook, or installer phase inherits identity context that exceeds what the software should receive before trust is established. This is why the term sits at the intersection of supply chain security, secrets hygiene, and least privilege. Industry guidance still varies on how broadly to scope the problem: some teams focus only on malicious packages, while others treat any install-time access to credentials as exposure that must be controlled. NIST’s Zero Trust Architecture principles support the narrower trust model needed here, because execution should not inherit more access than the current step requires.

NHIMG’s Ultimate Guide to NHIs frames this as part of the broader problem of secrets exposure in modern delivery systems. The most common misapplication is assuming installation is a passive phase, which occurs when organisations allow package scripts or build hooks to run with credentials already mounted in the environment.

Examples and Use Cases

Implementing package installation with strict identity isolation often introduces friction, requiring teams to weigh developer convenience against the reduced blast radius of credential exposure.

• A CI job installs a dependency from a public registry, but the same job has access to cloud deploy tokens. A malicious postinstall hook can exfiltrate them before any code is tested.
• An internal build plugin runs during import and reads secrets from environment variables that were intended only for later deployment steps.
• A monorepo uses automated dependency refreshes, and a compromised package manager script captures signing keys that are temporarily present on the runner.
• A security team reviews JetBrains GitHub plugin token exposure alongside the Anthropic report on AI-orchestrated cyber espionage to understand how early execution can turn trusted tooling into a credential collection point.
• An organisation hardens a supply chain pipeline after reading NHIMG’s Guide to the Secret Sprawl Challenge, separating install-time execution from secret-bearing jobs.

Why It Matters in NHI Security

Install-time identity exposure is dangerous because it compresses attack timing. A dependency does not need to wait for production runtime if it can harvest credentials during setup, when monitoring is weaker and trust is often assumed. That makes package ecosystems, plugin frameworks, and build systems especially attractive to attackers targeting NHIs, service accounts, and automation keys.

NHIMG’s Why NHI Security Matters Now material shows why this is not theoretical: 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage. When install-time execution can see those secrets, a single compromised package can become a full identity compromise path. The operational lesson is straightforward: installation must be treated as an untrusted identity boundary, not a harmless setup step.

Organisations typically encounter the true cost only after a dependency update, build plugin compromise, or poisoned install script has already accessed a credential store, at which point install-time identity exposure becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Identity Blast Radius
• Secrets Exposure
• When does secret exposure become a broader identity risk?
• Should identity teams use just-in-time access for NHIs?