How to Manage Credentials and Limit Risk for Enterprise Automation

Good credential governance starts with getting the secrets out of your scripts. Retrieve them from a vault at runtime, scoped to each automation, with central logging and revocation.

It only takes 40 minutes to farm your secrets

On March 24 at 10:39 UTC, a PyPI release (litellm 1.82.7) went live. But it contained a trojan. 13 minutes later, the likewise infected 1.82.8 followed. Both were live for roughly 40 minutes before the community flagged the payload and PyPI quarantined the package. That was enough. Build pipelines install dependencies fast. During that window, the trojan reached an estimated 434,000 CI/CD pipelines. The aftermath? Terabytes of secrets from major corporations including Microsoft, Amazon, Cisco, Samsung, Salesforce, and countless more ended up in a stolen archive that researchers obtained in August. Some of those credentials still worked five months on.

How did this happen? In a CI setup with something like GitHub Actions or Jenkins agents pulling dependencies during a build, a compromised package can execute inside the same environment that holds secrets. A classic supply chain attack. The interesting part is how the attackers got their publishing credentials in the first place.

Weeks earlier, they had stolen an automation token from Trivy, the open source security scanner. Aqua Security had rotated Trivy's credentials, but the rotation wasn't atomic. On March 19, the attackers poisoned Trivy. LiteLLM's build pipeline installed Trivy unpinned, so the poisoned scanner ran inside LiteLLM's own CI, harvested the PyPI publishing token, and handed the attackers everything they needed to push trojanized versions through LiteLLM's legitimate PyPI project.

The malicious code scraped accessible secrets including environment variables, SSH keys, cloud credentials and Kubernetes tokens, then exfiltrated them to attacker-controlled infrastructure.

What do leaked credentials cost?

The cost of a leaked automation credential is best measured in exposure time: how long it remains usable after compromise.

A vault alone does not guarantee that every automation consuming a credential is governed, attributable or safe to revoke. GitGuardian’s State of Secrets Sprawl 2026, published in March 2026, found that 64% of credentials confirmed valid in 2022 were still exploitable in 2026. It also found internal repositories were roughly 6× more likely than public ones to contain hardcoded secrets.

The Trivy end of the exploit is what really sticks out here. A rotated but insufficiently revoked automation token left the attackers with valid access for roughly 20 days before they used it. The attacker may need minutes; the organization can remain exposed for weeks because nobody knows every dependency.

That means longer containment, more audit risk, and potentially disruptive emergency rotations when undocumented scripts suddenly fail.

This is why credential management is also an automation-governance problem. When automation is scattered across local machines, scheduled tasks and ad hoc scripts, credential rotation becomes slower, riskier, and more disruptive. This visibility gap is behind many of the risks associated with shadow automation.

What good looks like for Microsoft-centric IT operations

Good credential security makes controls a property of the execution layer instead of relying on every script author to implement them correctly. Centralized execution makes it possible to separate automation logic from authentication and remove secrets from scripts. This way, scripts request the access they need at runtime, without embedding or owning long-lived credentials.

Microsoft already supports this model. Microsoft Learn’s guidance on using secrets in automation covers secure retrieval from a vault, while gMSAs and managed identities go further: the platform manages authentication so no password needs to reach the script at all.

That creates a clear maturity path:

Secrets in scripts → centrally managed credentials → governed runtime access with scoped identities and recorded execution

Yet the State of Microsoft Automation 2026 benchmark, covering 180+ IT teams and more than 45,000 scripts and workflows, found that only 28% of enterprises enforce full governance policies.

Closing that gap means treating credential handling as part of automation governance and compliance, with practical patterns such as removing credentials from PowerShell scripts with Azure Key Vault.

Five requirements for secure automation credentials

A mature execution model should support:

• no secrets in script bodies
• run-time credential retrieval
• per-automation access scoping
• recorded execution
• central revocation
  ‍

That is materially different than merely implementing a secrets manager. A vault can secure storage; the execution layer still determines how credentials are requested, which automation can use them, and whether that use is governed at run time.

It's essentially a Zero Trust decision: verify access at execution rather than treating possession of a credential as permanent authorization. That principle is explored further in Zero Trust principles for PowerShell governance, while secure delegation and RBAC-controlled PowerShell automation covers the authorization and approval layer in more depth.

For technical leaders, the payoff should be measurable: better audit readiness, lower operational risk, and shorter incident containment time when credentials must be revoked or replaced.

Where ScriptRunner fits

The above describes an operating model. Something still has to enforce it between the person requesting an action and the system where that action runs. This is where the execution layer comes in. Scripts should contain the automation logic, but not the credentials required to execute it.

With ScriptRunner, credential management, RBAC, policy controls, logging, and audit trails sit around the script, so access can be governed without embedding privileged credentials in the code itself.

You can manage credentials centrally in ScriptRunner’s encrypted vault, with role-based access controls, or integrated with supported password and secrets systems including 1Password, Bitwarden, and Azure. That means existing credential-management infrastructure does not have to be replaced simply to govern PowerShell automation.

This operating model also offers considerable advantages when it comes to audits. ScriptRunner’s security-by-design approach keeps security controls close to execution: actions are governed by policy, changes are logged, and reporting provides an audit trail of automated activity. Instead of reconstructing what happened across scripts, scheduled tasks, and individual machines, teams have a central record to work from.

For IT leaders, that translates into three practical outcomes: stronger audit readiness, lower operational risk, and safer delegation. Routine tasks can be handed to help desk teams or end users without giving them the privileged credentials or unrestricted system access that the underlying automation requires.

Centralize and secure your credentials before they become an incident

Centralized credential management does two things especially well:

1. It reduces exposure by keeping secrets out of scripts and ad hoc config.
2. It makes rotation and revocation much easier because the credential is managed in one controlled place rather than copied across dozens of scripts, jobs, and machines.

So if a credential is compromised, you can replace or revoke it centrally instead of hunting through every automation that might contain a copy. Central credential management reduces secret sprawl, limits unnecessary credential exposure, and makes compromised credentials much faster to rotate, revoke and investigate.

Book a demo and see exactly how ScriptRunner manages credentials from a central location and enables secure governance.

‍