Unsigned images meet an autonomous puller. What could go wrong.

The pull is the review

You have already been running unsigned code on your production hosts for years. Sit with that for a second. The only thing that made it feel safe was that a human, somewhere, looked at the image name in a Dockerfile and thought about it for three seconds. On 2026-08-14, The New Stack ran a piece by Uma Sridharan titled "Your container images are unsigned. In the AI era, that's a ticking time bomb." The argument, in short, is that the three-second review is now being outsourced to something that does not review.

The verdict, up front

The piece is right, and it has been right for years. What changed is that the excuse got worse. When a developer pulled an image, there was at least a name a security team could yell at them about later. When an autonomous agent resolves a build recipe, picks a base image, and pushes the result, there is no name and no diff to grep. The trust boundary moved from "the human running docker pull" to "whatever the agent decided was a reasonable dependency this hour". If you have not put a check between the agent and the pull, the check does not exist.

What the piece actually argues

The New Stack article frames unsigned container images as an AI-era supply-chain hazard. Its concrete claim is that autonomous agents and autogen pipelines pull and run images without human review, which amplifies the risk of running an unsigned artifact. That is not a new problem in a new outfit. It is an old problem whose main mitigation, "a person is watching," is being removed on purpose, by design, in the name of throughput.

Read it. It states its case in the register you would expect from a supply-chain column, and if your reaction is "we already know," that is exactly the point: knowing has not been enough.

Why the agent era shifts the math

Consider what the review path actually looked like before agents. A developer wrote FROM some-image:1.2 in a Dockerfile, a colleague approved the pull request, and a build ran. That colleague was the signing check. The signature was social. It was also thin, but it was there.

Take the human out of the loop and the social signature evaporates. An agent resolving a base image at build time can pick from a registry mirror you did not vet, retag the result on the way to your internal registry, and hand it to a runner that holds your OIDC tokens. The runner does not care what the image is called. It cares whether it can pull it. That is the whole security policy at the pull site, unless you added one.

The unsexy fix has been sitting on the shelf

Container image signing is not a research problem. Sigstore has been shipping for years. Cosign generates a signature you can push next to an image and verify at pull time. Notation covers the same ground with a different trust model for organisations that already have a PKI they trust. Kubernetes admission controllers can be wired to refuse workloads whose images are not signed by a key you know. None of this is new. All of it is boring. Boring is why it has not been rolled out.

The bill for that boredom is the article's point. If your response to a signed-image mandate has been "we will get to it," an agent that pulls whatever is convenient will get to it first.

What signing changes at pull time

Signing does not stop a compromised publisher from shipping a malicious image. It stops everything else. Once verification is a hard gate at pull time, the failure modes shrink to the ones you have to fix at the source, and the ones you can fix at the source are the ones you can actually threat-model. Concretely:

• A tampered image at rest in a mirror fails verification.
• A tag swap on a public registry fails verification against a pinned digest.
• A push to your internal registry by a service account that should not push there fails verification against your signing key.
• An agent that fetched from somewhere convenient fails verification, and the pipeline stops before the runner does anything with it.

The wiring is a build-time signer, a verify step in the runner, and an admission rule where the workload lands. In a pipeline that pulls an image by digest, the reference and the verify step read like:

image: $REGISTRY/app@sha256:<digest>
verify:
  policy: signed-by-org-key
  key: <path-to-public-key>

Replace the placeholders with your real registry and your real key. Do not skip the verify step for a "temporary" agent workflow. The temporary workflow is what ships to production the second nobody objects.

The kicker

The uncomfortable read of this piece is not that the AI era invented a new risk. It is that the AI era removed the last excuse. Sign your images, verify at pull, refuse the rest. Or keep pulling by name and hope the agent's taste is better than yours.