The file area where CI/CD jobs check out code, cache artefacts, and write intermediate files. In practice, it can retain secrets from previous jobs if cleanup is incomplete, making it a recurring source of machine identity leakage.
Build Agent Workspace as a Residual-State Problem
A build agent workspace is not just temporary disk space. It is a shared execution surface where checkout content, caches, logs, and intermediate artifacts can survive longer than the job that created them, which makes cleanup discipline part of the security boundary.
In CI/CD systems, the workspace often becomes the place where sensitive material is first decrypted, expanded, or copied into files. If isolation is weak or cleanup is incomplete, the next job may inherit state that was never meant to persist.
Why Workspace Hygiene Matters in CI/CD
The main security concern is residual data, especially secrets, tokens, keys, generated config, and build outputs that remain visible to a later job. That turns an efficiency feature, such as caching or reuse, into a confidentiality and integrity hazard when trust boundaries are looser than expected.
This is why secure pipeline design treats workspace reuse as a controlled behavior, not a default convenience. A job should assume that any file left behind may be read, copied, or accidentally packaged into an artifact by the next execution.
Workspace hygiene is closely related to broader non-human identity exposure in build systems, especially where a job can inherit credentials from a previous run. For CI/CD-focused guidance on that pattern, see the AI Coding Agents Security Guide and the Zero Trust for AI Agents approach to eliminating standing privilege in execution contexts.
Common Failure Modes
The most common failure modes are incomplete cleanup, overly broad cache reuse, and mixing trusted and untrusted workloads in the same workspace. A pipeline that speeds up builds by persisting state can also speed up secret exposure if the previous job wrote environment files, lockfiles, credentials, or tool caches into the same directory tree.
Another failure mode is assuming container or runner teardown automatically removes every trace of job state. In practice, bind mounts, shared volumes, artifact staging areas, and self-hosted runners can preserve data outside the lifetime of the job container.
Workspace leakage is especially dangerous when generated files include embedded access material or when build tools echo environment values into logs or temp files. Once that happens, the problem is no longer limited to the current pipeline run, because later jobs, developers, or artifact consumers may encounter the residual data.
What Good Segmentation Looks Like
A safer workspace design separates each job by default, keeps caches narrow and predictable, and makes cleanup deterministic rather than best-effort. The goal is to preserve performance benefits without allowing one job to read another job’s secrets, intermediate outputs, or local configuration.
Good practice also means distinguishing between data that may be cached for speed and data that must never persist. Build dependencies can often be reused, but credentials, signed tokens, and transient auth material should be treated as disposable job-scoped inputs.
Where pipelines depend on shared runners or shared directories, the workspace should be treated as a cross-job trust boundary. That means the safest assumption is that anything written there must be either non-sensitive, explicitly scrubbed, or intentionally exported as a controlled artifact.
Risk and Threat Considerations
Residual workspace state can expose secrets to the next job, the next branch build, or a maliciously crafted pipeline step that knows where to look. The security issue is not the presence of files alone, but the combination of reuse, weak cleanup, and sensitive material written into a location that outlives the job that created it.
Failure mechanism: A previous job leaves credentials, tokens, or sensitive config behind, and a later job, attacker-controlled build step, or shared runner process reads or copies that state before cleanup occurs.
Impact: Secret disclosure can enable build tampering, artifact poisoning, unauthorized repository or cloud access, lateral movement inside the pipeline, and compromise of downstream environments that trust build outputs.
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 addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-3 — Data Protection | Workspace residue can expose secrets and sensitive build data. |
| Recommendation — Restrict sensitive files in build workspaces and remove them after use. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Build workspaces often retain tokens and keys that must be managed across runs. |
| AC-6 — Least Privilege | Shared build workspaces become safer when jobs can access only the files and secrets they need. | |
| CM-6 — Configuration Settings | Workspace cleanup, cache paths, and runner persistence depend on secure configuration. | |
| Recommendation — Rotate and revoke credentials that may persist in CI/CD workspace state. Limit each job's access to only its required workspace inputs and outputs. Harden runner and workspace settings to prevent unwanted state persistence. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The term directly centers on build-state retention that can leak credentials and tokens. |
| NHI-01 — Improper Offboarding | A workspace that is not scrubbed after a job behaves like incomplete identity teardown. | |
| Recommendation — Eliminate secret material from workspaces and cached build paths. Ensure every job teardown removes credentials, files, and cached state. | ||
Practitioner Guidance
Why practitioners should care: Treat the workspace as an attack surface, not a neutral temporary folder. If your CI/CD design assumes ephemeral jobs but your runner or cache model preserves state, your security posture depends on cleanup behavior that may fail silently.
What to watch for: Reused self-hosted runners, broad workspace mounts, lingering temp directories, and build steps that write secrets to disk are the strongest signals that the workspace needs tighter isolation. The most useful question is whether a later job could infer, reuse, or exfiltrate anything the prior job touched.
Practitioner takeaway: If a build system cannot prove that sensitive job state is removed or isolated, assume the workspace can leak credentials across runs.
Related resources from NHI Mgmt Group
- Should organisations build separate controls for AI agent deployments?
- What breaks when an AI agent can find and use exposed secrets in its workspace?
- How can security teams know whether workspace agent tokens are being over-trusted?
- What breaks when agent access is granted too broadly at build time?