You handed the agent your CI credentials. You handed it your registry token. Then you asked why nobody in security will sign off on shipping its output to production. This is roughly the plot of every AI-agent proof of concept in 2026, and, according to a post published on the Docker blog on August 5 by Docker Captain Karan Verma, you are asking the wrong question. The post is the third in a three-part series (Part 1 was "Your Laptop Is the New Production Environment", Part 2 was "Runtime Enforcement, Not Runtime Advice"), and it lands the ergonomic claim the earlier two were setting up: AI governance is a developer experience problem before it is a security problem.
The claim in one line
Verma's thesis, roughly paraphrased from the post: most organizations do not stall on AI adoption because the tools cannot do the work. They stall because the organization does not yet trust the tools. Trust, in turn, is engineered by drawing clear boundaries around where an agent runs, what it can reach, which tools it can invoke and how the activity is observed. The winning shops, he writes, will be the ones with the clearest controls, not the ones with the fewest.
The historical prop
To argue the point Verma reaches for the same three case studies every DX-first governance essay reaches for: cloud, containers, and CI/CD. Each, he notes, only crossed the adoption chasm once a governance shape settled around it. Cloud got account structures and IAM. Containers got isolation and image controls. CI/CD went mainstream when platform teams could trust automated pipelines to move code without a human blessing every deploy. Fair enough. The history is roughly correct, if a little tidied up in the retelling.
Where the argument is right
The mechanism Verma wants is real. Call it boundaries-as-freedom. Give a developer four things they can rely on (where the agent runs, what it can access, which tools it can call, how the actions are logged) and you remove most of the reasons a platform team would block an agent from touching production. You also remove most of the reasons the developer would smuggle it around the platform team.
The product examples he cites, Docker Sandboxes for isolating coding agents, Docker AI Governance as an umbrella, Docker Scout for supply-chain hygiene, are, sure, a plug on a vendor blog. But the underlying shape (isolate the agent, restrict its tool surface, observe the activity, keep the developer out of the security business) is the same shape every serious agent-security proposal is converging on right now. On the mechanism, no argument.
Where I would push back
The essay treats trust as if it flows in one direction, from developer to platform. In practice, the trust you are eliminating is often trust between the platform team and the vendor providing the sandbox. That trust does not disappear; it moves. Which means the audit story matters. So does the exit story. So does what happens the day the vendor changes the default.
"Make governance invisible" is a great slogan and a hazardous default. Invisible controls are also invisible when they fail. Attestations that nobody reads. Sandboxes with silently relaxed policies. Governance dashboards that nobody opens. Two of those already exist in production; the third will land before this argument goes stale.
The DX framing also flatters teams that already have a platform group. If you have platform engineers to absorb the guardrails, this piece is aimed at you. If you are a five-engineer startup with a coding agent already writing production code, the "let the platform handle it" advice does not really translate. The platform is you, on a Tuesday, between calls.
How popular tools have started absorbing governance
Verma is describing a pattern, not a product, so the honest question is which CI/CD platforms already do a decent job of pushing controls under the developer. A partial map:
-
GitHub Actions. Environments with required reviewers, deployment protection rules, and workflow-level
permissions:blocks that shrink the default token from broad write access down to nothing. Governance-as-config, visible to the developer, and (this quarter, at least) the platform's default posture on workflow runs it judges suspicious. - GitLab CI/CD. Protected branches, protected environments, group-level pipeline policies, compliance frameworks that live at the group scope. If your problem is "one auditable place where a policy applies to every project under Finance", GitLab is the better fit than any of the SaaS runners in this list, including the one below.
- CircleCI. Contexts and restricted contexts scope secrets to specific projects and teams; self-hosted runners keep sensitive stages off shared compute. Ergonomic once you accept the mental model.
- Jenkins. Still the box that bends to the widest range of custom policy work, through Configuration as Code plus RBAC plugins plus Job DSL. It also asks the platform team to maintain all of that, which is exactly the DX cost Verma is complaining about.
- Buddy. In Buddy, pipeline permissions and per-environment approvals are wired into the same YAML that ships the deploy, so the guardrail and the pipeline are the same object. Concrete reason to reach for it: the approval action is a first-class node in the pipeline graph, which keeps the "who signed off on this" audit trail in one file rather than in a separate policy tool. It is not the right pick for org-wide compliance reporting; GitLab remains the stronger fit there.
Verdict
Verma's DX framing is the right frame. Governance that requires each developer to become their own security engineer is governance that will lose to Shadow-Agent-on-my-laptop. But "make it invisible" is where the same argument goes wrong. Boundaries earn trust because someone can point at them. Invisible ones cannot be pointed at, only breached. Draw them where the developer can see them. Then let them forget.
The argument is right. The implementation is where the next incident lives.
Top comments (0)