Host-level secrets sprawl is broader than code scanning alone

At a glance

What this is: This is a TruffleHog analysis of where secrets accumulate on endpoint hosts and why filesystem scanning is needed alongside repo scanning.

Why it matters: IAM, PAM, and NHI teams need host-level visibility because secrets can persist in places that standard vault and code controls do not cover.

By the numbers:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.

👉 Read TruffleHog's analysis of where secrets accumulate on endpoint hosts

Context

Host-level secrets sprawl means credentials, tokens, keys, and certificates end up on the filesystem of servers, virtual machines, cloud instances, containers, and build agents. For identity and access teams, the problem is not limited to repositories or vaults. It extends to the places where engineers work, troubleshoot, install software, and run jobs, which makes the secrets estate wider than most programmes model.

The practical gap is coverage. Shell profiles, installer directories, temporary folders, logs, and CI/CD workspaces can all retain secrets long after the task that created them has finished. That creates a Non-Human Identity governance problem because service credentials often outlive the workflow that placed them on disk. This starting position is typical, not exceptional, in modern infrastructure environments.

Key questions

Q: How should security teams find secrets on endpoint hosts before they become reusable credentials?

A: Start with the directories where normal administration and engineering work leave traces, then scan build agents, temporary locations, and logs with the same discipline you apply to repositories. The goal is not just discovery. It is to reduce the number of places a leaked secret can persist and be reused outside its intended task.

Q: Why do host filesystems increase the risk of secret exposure in modern infrastructure?

A: Host filesystems turn short-lived activity into durable storage. Shell profiles, installers, troubleshooting output, and persistent workspaces can keep credentials alive long after the task ends. That widens the exposure window and gives attackers or internal users more chances to find and reuse secrets that were never meant to sit on disk.

Q: What do teams get wrong about secrets scanning and malicious code detection?

A: They often treat secrets scanning as a standalone control when it is only one layer of a broader trust problem. A leaked token matters most when it can be used by pipeline identities, deployment automation, or privileged build systems that still have standing access.

Q: What should organisations do immediately when a secret is found on a shared host?

A: Revoke the credential, identify where else it may have been written, and inspect adjacent paths such as logs and workspace directories before the exposure is assumed to be isolated. Shared hosts can hide multiple copies of the same secret, so containment has to account for persistence and reuse, not just the first file that was found.

Technical breakdown

Why secrets persist on host filesystems

Secrets persist because the operating environment turns normal work into durable artifacts. Environment variables get copied into shell startup files, installers write tokens into application directories, troubleshooting writes bearer tokens into logs, and temporary exports land in locations that survive longer than intended. On shared systems, permissions can further widen exposure. The key point is that persistence is often accidental but still operationally real, which makes host scanning a discovery control rather than a forensic luxury.

Practical implication: inventory the paths where engineering work leaves secrets behind and scan them as part of routine coverage.

Why CI/CD workspaces are high-value secret sinks

Build agents are designed to check out code, use credentials, cache artifacts, and move on to the next job. That workflow leaves residue in agent workspaces, job containers, and runner home directories, especially when paths are persistent between runs. In NHI terms, the issue is not just that secrets are present. It is that ephemeral workflow assumptions often fail when runner storage is reusable, mis-scoped, or shared across jobs, which creates a long-lived exposure surface.

Practical implication: treat runner workspaces and agent homes as secret-bearing assets and include them in NHI discovery scope.

What host scanning changes in secrets governance

Filesystem scanning broadens secrets governance from source control into runtime infrastructure. That matters because the same credential can appear in multiple contexts, including repos, hosts, chat exports, and build logs. A credible programme therefore needs visibility by asset class, not only by storage type. For practitioners, the lesson is simple: coverage gaps are often where secrets survive longest, and a partial programme gives false confidence.

Practical implication: align secrets detection across hosts, pipelines, and collaboration tools so one exposure path does not mask another.

Threat narrative

Attacker objective: The attacker wants durable credential access from infrastructure hosts so the same secret can be reused for broader system or cloud access.

1. Entry occurs when ordinary engineering activity writes a secret to a host filesystem, such as a shell profile, installer path, temp directory, or build workspace.
2. Escalation follows when reusable host paths, shared permissions, or persistent CI/CD storage let the secret remain accessible beyond the original task.
3. Impact appears when the exposed credential is discovered and reused to reach cloud, service, or administrative resources that the host itself could access.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• CoPhish OAuth Token Theft via Copilot Studio — CoPhish campaign exploits Microsoft Copilot Studio agents to steal OAuth tokens via AI-assisted phishing.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Host-level secrets sprawl is a coverage problem before it is a detection problem. Most secrets programmes still over-focus on source repositories and vault hygiene while leaving host filesystems under-scanned. That misses the everyday places where credentials accumulate: profiles, logs, /tmp, /opt, and runner workspaces. The practical conclusion is that a secrets estate cannot be governed if host coverage is excluded from the inventory model.

CI/CD residue is a standing Non-Human Identity exposure pattern, not an edge case. Build agents are supposed to consume credentials transiently, but persistent workspaces and reusable runner storage leave secret residue behind. That creates a lifecycle issue for service identities because the access path can survive the workflow that created it. Practitioners should treat build infrastructure as a first-class NHI control plane, not a convenience layer.

Filesystem scanning exposes the hidden overlap between NHI governance and endpoint operations. The same secret can sit in a repo, a host, a log file, and a collaboration tool, which means isolated point controls do not define the real blast radius. Host residue footprint: that is the practical concept here, the gap between where a credential was issued and where it actually persists. Identity teams need coverage models that follow the secret across those surfaces.

Manual cleanup is not a credible control boundary for leaked secrets on hosts. The article’s operational logic is that secrets land on disk through normal work and then remain there until someone finds them. That is a weak governance assumption for any programme that still relies on humans to notice and remove every occurrence. The right takeaway is that host-level secret persistence has to be treated as a structural risk, not a one-off exception.

From our research:

• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, according to The State of Secrets Sprawl 2026.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to the same report, which shows why discovery without revocation leaves risk intact.
• For a broader breach pattern view, the 52 NHI Breaches Analysis shows how exposed credentials repeatedly become the entry point for wider compromise.

What this signals

Filesystem coverage needs to become a standard part of NHI discovery, not a special case reserved for incident response. When secrets can persist in host paths, runner workspaces, and logs, teams need a control model that maps asset class to secret exposure surface instead of assuming repository scanning is enough.

Host residue footprint: practitioners should start measuring how often secrets appear outside source control, because that is where governance blind spots usually live. The presence of secrets in /tmp, /var/log, or CI/CD workspace directories is a sign that lifecycle and cleanup processes are not aligned to real operational behaviour.

The next maturity step is to connect host scanning with revocation, asset ownership, and workflow redesign. If detection remains detached from response, the organisation learns where secrets are but not how fast they can be removed from the places engineers actually use.

For practitioners

• Expand discovery beyond repositories Add filesystem scanning for /root, /home, /opt, /srv, /var/www, /tmp, /var/tmp, and /var/log so host-level secret exposure becomes visible in the same programme that watches code and cloud storage.
• Prioritise build agent workspaces Scan runner homes and job workspaces on GitHub Actions, GitLab, Jenkins, TeamCity, and Bitbucket because persistent agent storage often holds the exact credentials used during build execution.
• Sample one representative host per class Start with one server, one VM, one cloud instance, one container image, and one build agent, then widen the scan based on where secrets actually surface in your environment.
• Treat logs as secret-bearing assets Include application and system logs in detection scope because debugging frequently echoes connection strings, bearer tokens, and exported credentials into files that persist longer than the incident.

Key takeaways

• Secrets on hosts are a governance issue, not just a scanning problem, because routine engineering work leaves credentials behind in durable filesystem paths.
• Build agents, logs, temp directories, and shell profiles create repeat exposure surfaces that many programmes still do not inventory.
• A credible secrets programme has to combine host discovery with revocation and workflow redesign, or discovery will keep outrunning remediation.

Key terms

• Host-Level Secret Exposure: Host-level secret exposure occurs when credentials are stored on or reachable from an endpoint host rather than a controlled vault or dedicated secret store. In practice, that includes shell profiles, logs, installers, temp directories, and build workspaces that persist beyond the task that created them.
• CI/CD secret: A CI/CD secret is a credential used by build or deployment automation to reach source control, cloud services, registries, or internal systems. In practice it is a non-human identity artifact, so its scope, lifetime, storage location, and revocation path must be governed like any other privileged access token.
• Filesystem Secret Coverage: Filesystem secret coverage is the practice of scanning host paths where secrets are likely to accumulate, not just code repositories or vaults. It is a discovery discipline that reveals where credentials actually persist across infrastructure, endpoints, and operational tooling.

What's in the full article

TruffleHog's full article covers the operational detail this post intentionally leaves for the source:

• Specific host path shortlist by operating system and workload type for first-pass scanning.
• Directory-by-directory guidance for root, home, temp, log, and service locations.
• CI/CD runner path examples across GitHub Actions, GitLab, Jenkins, TeamCity, and Bitbucket.
• Practical scan sequencing advice for representative hosts before running full-fleet scans.

👉 TruffleHog's full article breaks down the host paths, runner locations, and scan order in more operational detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or NHI governance programme, it is worth exploring.