AI-Assisted Secure Coding (Appendix C) · CI/CD Pipeline Hardening Specific to AI Augmentation
Ephemeral, isolated runners for AI tooling
Verify that self-hosted or persistent runners used by AI tooling are ephemeral (destroyed after each job), network-segmented, and isolated from production credentials. Persistent or long-lived runners do not process fork PRs or AI-generated untrusted artifacts under any circumstances.
OWASP AISVS v1.01, requirement AC.12.4
In plain English
Runners used by AI tooling should be ephemeral, meaning destroyed after each job, as well as network-segmented and isolated from production credentials. A persistent runner must never process fork PRs or untrusted AI-generated artifacts. Anything left behind on a reused runner is there for the next job to pick up.
What good looks like
- Runners for AI tooling are created for one job and destroyed afterwards.
- They sit in a segmented network with no route to production systems.
- No production credentials are reachable from them.
- Persistent runners are excluded from fork and AI workloads by configuration.
How teams usually do it
- Platform-hosted runners, or an ephemeral self-hosted setup such as Actions Runner Controller in ephemeral mode or autoscaled single-use virtual machines.
- Runner groups and labels that keep public and AI workloads off privileged runners.
- Network policy and separate cloud accounts for the runner pool.
Suggested evidence
- Runner configuration.
- Group and label assignments.
- Network design for the runner pool.
Common mistakes
- One self-hosted runner shared by public PRs and deployments.
- "Ephemeral" containers on a persistent host with a shared Docker socket or cache.
- Runner labels that any workflow can ask for.
Not sure which requirements apply to your system? Take the assessment, or browse every guide in this chapter.
Requirement text from the OWASP AI Security Verification Standard, licensed under CC BY-SA 4.0. This guidance is shared under the same licence.