On February 11, 2019, the runc maintainers disclosed CVE-2019-5736: a container process could overwrite the host's runc binary via /proc/[pid]/exe, escaping to the host without needing a privileged container. The fix — making runc's init process non-dumpable — shipped fast, but the deeper lesson didn't age out. A build-time image scan would have reported a "clean" image right up until the moment a malicious workload inside it invoked the escape at runtime. Seven years later, teams are wiring autonomous agents directly into that same gap: an LLM-driven pipeline that reads a scan result, rewrites a Dockerfile or Kubernetes manifest, and pushes the change toward production. That's useful — median time-to-patch drops from days to under an hour in well-instrumented environments — but it also hands a piece of software standing write access to registries, manifests, and sometimes clusters. The NSA and CISA's Kubernetes Hardening Guide (v1.2, August 2022) already told human operators to enforce policy at the admission boundary rather than trust what arrives there; agentic pipelines make that boundary the whole ballgame. This post covers how to get automated scanning and remediation into your Kubernetes workflow without quietly promoting an agent to a new, unaudited privilege class.
Why isn't build-time image scanning enough for an agentic pipeline?
Build-time scanning tells you what a component looked like at the moment the layer was assembled — it says nothing about what happens once the container is running. CVE-2019-5736 is the canonical case: the vulnerable code path only mattered when a container process was actually invoked against the host's runc binary, a runtime condition no static image scan models. Feeding a static scan's output straight into an autonomous rebuild-and-deploy loop compounds the gap — the agent "fixes" what the scanner saw and ships it with the same confidence whether or not the fix addressed anything exploitable. That's why NSA/CISA's Kubernetes Hardening Guide (v1.2, August 29, 2022) recommends running scanners at the admission boundary and continuously at runtime, not just at build time, and explicitly ties that to policy enforcement replacing the deprecated PodSecurityPolicy (removed in Kubernetes v1.25). An agent that only reads build-time results is reasoning from a stale, incomplete picture of risk.
What new trust boundary does an autonomous agent actually introduce?
The boundary isn't the scanner — scanners have always run in CI. It's the write path an agent gets once it can act on findings: pushing to a registry, opening or auto-merging a PR against a manifest repo, or triggering a rollout directly. Each of those is a privileged action that, in a human workflow, implicitly passed through a person's judgment about blast radius. An agent making the same call at machine speed, potentially across hundreds of services, turns one compromised or miscalibrated model output into a fleet-wide change. MITRE ATT&CK for Containers, folded into the Enterprise matrix in ATT&CK v9 (2021), gives defenders a shared vocabulary for this: techniques like T1610 (deploy container) and T1611 (escape to host) describe exactly the actions an agent's automation could inadvertently perform if its credentials or its plan are ever manipulated. The fix isn't to deny the agent write access — it's to route every write through the same policy control point a human change would have to pass.
How does admission control keep the agent from becoming the trust boundary?
Kubernetes admission control — validating and mutating webhooks evaluated before a pod is scheduled — is where you enforce that an agent's proposed change meets the same bar a human-authored one would. OPA Gatekeeper and Kyverno, both CNCF projects, are the two dominant open-source implementations, and both can gate on image signature, SBOM presence, or live vulnerability data rather than trusting whatever manifest arrives. Practically, this means an agent never gets to "self-certify" its own fix: it can propose a rebuilt image, but the admission controller — a separate control point with its own policy source — decides whether that image is actually allowed to run. Safeguard's guardrails documentation describes this pattern concretely: an admission-controller Helm chart (built on Kyverno/Sigstore's policy-controller) resolves the image digest, fetches its SBOM and signature, evaluates policy, and only then admits, warns, or denies — with audit mode available for dry-running new rules before they block anything.
Why does image signing matter more once an agent is doing the rebuilding?
Once a rebuild can be triggered by something other than a human running docker push, provenance — proof of who built an image and from what source — becomes the control that replaces the trust a human reviewer used to provide implicitly. Sigstore and its Cosign tool solved this for the ecosystem generally: free, OIDC-based signing lets any pipeline attach a verifiable signature to an image without managing long-lived keys, and an admission controller can then refuse to run anything unsigned. For an agentic rebuild loop specifically, this closes the exact gap CVE-2019-5736-style escapes exploit at a different layer — even if the rebuild step itself were compromised, an unsigned or wrongly-attested image simply never clears admission. This is also where SBOM attestation earns its keep: a signed CycloneDX or SPDX manifest generated at rebuild time gives you a record of exactly what changed, so a postmortem doesn't depend on trusting the agent's own change description.
How should staged promotion limit the blast radius of an agent's mistake?
Staged promotion — rebuild to a non-production tag first, require an explicit gate before promoting further — bounds how much damage a single bad automated decision can do, regardless of how confident the agent's plan looked. This mirrors how Safeguard's self-healing container capability is documented: it runs a four-step detect-plan-rebuild-promote loop with three selectable trust tiers — advisory (files a PR only, a human merges), autonomous-staging (rebuilds and promotes to a staging tag, but a human approves the promotion to production), and continuous (fully automated, with production policy still enforced as a backstop and automatic rollback on readiness-probe failure or policy violation). Every rebuilt image in that flow carries a signed provenance attestation and an SBOM diff, so even the continuous-mode path leaves an auditable trail rather than a black-box change. The point generalizes past any one vendor: the fewer irreversible actions an agent can take without a checkpoint, the less a bad plan — or a manipulated one — costs you.
What should teams verify before trusting runtime alerts to drive automated response?
Runtime detection is where over-trusting automation is most dangerous, because the action space includes killing or isolating live workloads. Continuous, in-cluster reconciliation matters here — Kubernetes workloads benefit from re-checking running state on a short interval (roughly every 15 minutes in Safeguard's documented model) rather than only at admission, since a pod's actual behavior can drift from what was approved at deploy time. But destructive responses — killing a process, quarantining a pod, isolating a workload — should stay policy-gated and require approval by default, precisely because eBPF-based runtime collection is still rolling out across the industry and is not universally GA; Safeguard's own runtime-protection documentation is explicit that its eBPF collector is a Linux-only, still-rolling-out component, and that kill/quarantine/isolate actions require approval unless a team has deliberately opted a high-confidence rule into auto-response. Alert-only should be the default until you've validated the detection's false-positive rate against your own traffic.
How Safeguard Helps
Safeguard's approach keeps agentic remediation inside the same control points defenders already trust rather than granting the automation a side channel. Continuous scanning drives Kubernetes-specific admission-time checks and 15-minute runtime reconciliation, so an agent's plan is always built on current data, not a stale build-time snapshot. The self-healing container loop runs detect-plan-rebuild-promote with selectable trust tiers — advisory, autonomous-staging, and continuous — so teams can start with an agent that only opens PRs and graduate to autonomous production promotion only once they trust the track record, with every rebuilt image carrying a signed SBOM, provenance, and Griffin-generated explanation attestation. Guardrails enforce policy at the same admission boundary NSA/CISA recommend, built on Kyverno and Sigstore's policy-controller, with BLOCK/WARN/AUTO_FIX effects, audit-mode dry runs, and time-boxed breakglass exceptions requiring two-person approval. And runtime protection keeps destructive response gated behind policy and approval by default, so an agent's confidence in a detection never substitutes for a human decision on a live production workload.