CI/CD and agent stacks: hardening checklist
Recent guidance for securing AI agent stacks recommends Docker isolation, strict API key management (for example AWS Secrets Manager), least privilege, audit logging, MFA, encryption, patching, IDS/IPS and incident plans. The same guidance emphasizes integrating SAST, SCA, IaC scanning, container scanning, provenance generation and artifact signing into CI/CD so security primitives are pipeline-native. Those controls align with defence-focused recommendations to treat SBOMs and scanning as operational artifacts tied to build evidence. (x.com/moltbot_builds (x.com/osodevops)
Continuous integration and continuous deployment pipelines are being recast as security controls, not just release plumbing, in new hardening guidance for artificial intelligence agent stacks. (nist.gov) An agent stack is the software layer that lets a model call tools, read data, and act on systems; that makes its build pipeline part of the attack surface. The National Institute of Standards and Technology says continuous integration and continuous deployment stages move code through build, test, package, and deploy steps across the software supply chain. (nist.gov) The hardening pattern is straightforward: isolate workloads in containers, lock down secrets, and limit permissions. The Open Worldwide Application Security Project’s Docker guidance recommends minimizing container privileges and hardening the host, while its logging guidance says application security events need dedicated audit trails. (owasp.org 1) (owasp.org 2) The pipeline side is equally specific: run static application security testing, software composition analysis, infrastructure as code scanning, and container scanning before release. GitHub’s supply-chain documentation groups dependency security, provenance, and artifact integrity as release controls, not optional extras. (docs.github.com) That approach tracks federal supply-chain guidance that treats build evidence as an operational record. The Cybersecurity and Infrastructure Security Agency says a software bill of materials is a key building block for software security, and the National Institute of Standards and Technology says it acts like an ingredients list for software components and relationships. (cisa.gov) (nist.gov) Provenance fills in the missing chain-of-custody. The Supply-chain Levels for Software Artifacts project says provenance tells consumers whether an artifact is authentic, and the National Institute of Standards and Technology’s National Cybersecurity Center of Excellence describes signed attestations that record source changes, continuous integration and continuous deployment components, dependencies, and produced artifacts. (slsa.dev) (nist.gov) Security agencies are also pushing buyers and operators to use those records after the build, not just generate them once. The National Security Agency said in December 2023 that software bill of materials tool management should support broader cybersecurity supply-chain risk management, and the Cybersecurity and Infrastructure Security Agency published additional software bill of materials implementation guidance in October 2024 and a joint international vision in September 2025. (nsa.gov) (cisa.gov 1) (cisa.gov 2) For teams shipping agents, the checklist now spans runtime and release engineering in one motion: container isolation, secret storage, least privilege, audit logging, multi-factor authentication, patching, scanning, signed artifacts, and incident response. The common thread across the official guidance is that security data has to travel with the build, or defenders cannot verify what actually reached production. (owasp.org 1) (owasp.org 2) (cisa.gov) (slsa.dev)
