Analyst(s): Vikram Rathnam, Mitch Ashley
Publication Date: October 6, 2026
EZ Control, now in Early Access from env zero, is a software-as-a-service (SaaS) control plane that identifies gaps between intended and actual cloud state and remediates them according to policy. Its value rests on telling an intended change from an accidental one, and env zero has not yet explained how EZ Control does that.
What Is Covered in This Article:
- What env zero announced with EZ Control on September 29, 2026, and what Early Access includes.
- How EZ Control’s four autonomy levels and ownership context are meant to govern remediation.
- Why are AI agents changing cloud infrastructure, turning drift remediation into a governance question?
- How EZ Control compares with remediation from AWS, Spacelift, and Firefly.
- What platform and security leaders should test before granting EZ Control authority to act?
The News: On September 29, 2026, env zero announced the Early Access launch of EZ Control at DevOpsCon & AI Platform Engineering Day, New York. The company describes it as an autonomous cloud control plane that detects gaps between the state an enterprise intends, whether written as infrastructure as code (IaC), a cloud security posture rule, a policy-as-code repository, or a cloud provider guardrail, and the state actually running, then remediates them under policy. The product builds on env zero’s March 2026 merger with CloudQuery.
According to env zero, EZ Control discovers cloud and software-as-a-service (SaaS) resources through more than 80 integrations, covering nearly 2,300 resource types across Amazon Web Services (AWS), Microsoft Azure, Google Cloud, and Kubernetes, and links each resource to the code that declared it, its owning team, cost, dependencies, policies, and risks. Teams set autonomy for each resource class: observe only, propose a fix, act with approval, or act autonomously within guardrails. The company says EZ Control reapplies IaC to correct unintentional drift, opens a pull request against the owning repository for intentional changes, and runs a scan after each fix to confirm it is closed. It also says AI agents working through EZ Control need no raw cloud credentials.
EZ Control is delivered as a SaaS solution, and the initial connection is agentless and read-only. The company did not disclose pricing or the names of EZ Control customers; the customers it lists, including PayPal, Visa, and Walmart, use its existing platform. Details are in env zero’s EZ Control launch announcement.
env zero EZ Control: Telling a Fix From a Mistake
Analyst Take: The promise of env zero EZ Control is to find the gap between what a company’s cloud is supposed to look like and what is actually running, a gap engineers call drift, and to close it without waiting for an engineer. Whether that saves platform teams time or causes outages depends on how EZ Control decides whether a change was intentional.
The company’s existing platform already reads cloud audit logs to show who changed a resource and when, for AWS and Azure. Knowing who made a change is not the same as knowing why, and nothing env zero published shows EZ Control reading the context that answers why.
Drift Is a 30-Year-Old Problem, and AI Agents Made It Urgent
Mark Burgess built CFEngine at the University of Oslo in 1993 so that administrators could describe the state they wanted their machines to be in and let the tool converge on it. HashiCorp released Terraform in July 2014 and made the same loop the default method for managing cloud infrastructure. Since then, the sources of drift have grown, and env zero’s list now includes AI agents provisioning infrastructure at machine speed alongside console edits, emergency fixes, and automated pipelines.
Organizations remain hesitant to allow autonomous AI to manage their infrastructure configurations. In The Futurum Group’s 2H 2026 Software Lifecycle Engineering Global Enterprise Decision Maker Survey (n=839, fielded June 2026), semi-autonomous and fully autonomous agents are the dominant mode of AI use at just 19% of organizations. Where agents do act, safeguards lag; only 32% of organizations use human approval gates for irreversible agent actions.
The survey asked about agents in software development, and agents that change cloud infrastructure act directly on production systems, where the same gaps carry more risk.
The Hard Part Is Knowing What Was Meant
The company’s pitch is that “the bottleneck in cloud operations is no longer knowing. It is acting.” Half of that is right. Platform engineers have plenty of alerts and too little time to find a resource’s owner, check what depends on it, and decide what to do.
Steve Corndell, env zero’s CEO, puts context at the center of the claim. He says “autonomy is only ever as trustworthy as the context underneath it,” and that context is “what lets EZ Control act rather than alert, under policy, with a named owner and a complete audit trail.” He has named the right dependency.
A named owner and an audit trail record showing who changed a resource and when. Neither records why, and the why is what separates an intentional change from an accident or an out-of-process change. By publishing how EZ Control establishes why a change was made, env zero would close the largest gap between what it claims and what it has shown.
IaC is the written definition of how the cloud should be configured. The running cloud is how it is right now. Some differences are mistakes, and others are repairs someone made in the middle of the night for a good reason.
According to env zero, EZ Control responds to a difference in one of three ways: it reapplies IaC to unintentional drift, opens a pull request against the owning repository for an intentional change, and flags a source code defect when the declared state itself is wrong. That is three buckets sorted from one signal. A deliberate change, an accidental one, and a bug in the IaC itself arrive looking alike, and the whole design depends on telling them apart.
An audit log alone cannot do that sorting, because the same on-call engineer, using the same role in the same console, can make an emergency fix at 2 a.m. and a careless change at 2 p.m., and both entries look identical. Telling them apart takes context from outside the cloud, such as an incident record, a change ticket, an emergency-access session, or a change window.
If EZ Control treats an emergency fix as accidental, it reapplies the old configuration, bringing the outage back. If it treats an agent’s unauthorized change as intentional, the change arrives as a pull request that a busy reviewer may approve, which writes the mistake into the IaC.
The announcement also calls EZ Control’s autonomy “attributable, reversible, and auditable.” Its evidence is that every change runs through the owning repository and its review process, followed by a scan to confirm the fix, which supports attribution and audit, but does not show how env zero EZ Control undoes a deleted resource or recovers lost data.
env zero EZ Control Enters a Field Others Already Occupy
The announcement’s claim that agents need no raw cloud credentials follows a pattern security teams know from privileged access management, where administrators give up standing credentials and request access through a broker that limits and records it. Revoking agents’ direct cloud access is an enterprise security program decision, and EZ Control cannot make that decision.
AWS Config already remediates noncompliant resources through Systems Manager Automation, and Spacelift and Firefly offer drift detection and remediation for IaC. What env zero adds is combined inventory across clouds, one set of policies applied to all of it, and fixes written back to the owning repository. The fix-writing part builds on env zero’s existing IaC governance platform, which the company says PayPal, Visa, and Walmart already use.
The cloud providers own identity and access management (IAM), and AWS already runs a credential vault for agents in Amazon Bedrock AgentCore Identity, which stores the tokens agents use to access other services, so the cloud providers could offer the same brokering within their own platforms.
Spending on agent governance is growing faster than any other segment that The Futurum Group tracks in software lifecycle engineering. The 2H 2026 Software Lifecycle Engineering Market Sizing & Five-Year Forecast (July 2026) projects agent control plane and governance at a 48.7% compound annual growth rate from 2025 to 2030, reaching $12.9 billion. That growth helps explain why inventory and IaC vendors such as env zero are moving toward agent governance.
Earn Autonomy One Resource Class at a Time
For platform engineering and cloud security leaders evaluating env zero EZ Control:
- Measure before you grant autonomy. Run env zero EZ Control in observe and propose only, and for each drift event, record how it classified the change and what your engineer would have done. Set the agreement rate you need before the pilot starts, grant “act with approval” only to resource classes that meet it, and reserve full autonomy for classes where a wrong call is cheap, such as resource tags or oversized development instances.
- Ask env zero three questions before widening the pilot. Which contexts beyond the audit log, such as tickets, incident records, or emergency-access sessions, does EZ Control read? What does “reversible” mean for a deletion? Which policy wins when EZ Control’s rules conflict with your posture tool’s?
- Plan the credential cutover. Run the removal of agents’ direct cloud access as a security project with an owner and a date.
Granting authority by resource class fits drift remediation because the targets are fixed resources, such as databases or security groups. It does not settle the problem our colleague Fernando Montenegro raised in June 2026: agents authorized for a goal take actions that nobody listed in advance, so the agents making changes still need governance of their own.
As autonomy grows, the platform engineer’s job shifts from fixing drift to writing the policies that decide which drift gets fixed and how. Those engineers will need evidence, and env zero can supply it by publishing how EZ Control classifies intent and how often Early Access customers overrode it.
What to Watch:
- Whether env zero publishes how EZ Control decides a change was intended, with override or error rates from Early Access, before general availability.
- Whether AWS, Microsoft, or Google extends native policy remediation to mediate changes made by AI agents, turning the broker into a cloud feature.
- Whether Spacelift, Firefly, or HashiCorp adds agent-mediated change paths that keep cloud credentials out of agents’ hands.
- Which resource classes do Early Access customers move past propose-only first, and whether any reach full autonomy in production?
- Whether EZ Control integrates with incident and ticketing systems such as PagerDuty, ServiceNow, or Jira, it needs to know the context of why a change was made.
See the complete press release on the cloud governance launch on the env zero website.
Disclosure: Futurum is a research and advisory firm that engages or has engaged in research, analysis, and advisory services with many technology companies, including those mentioned in this article. The author does not hold any equity positions with any company mentioned in this article.
Analysis and opinions expressed herein are specific to the analyst individually and data and other information that might have been provided for validation, not those of Futurum as a whole.
Other Insights From Futurum:
OpenAI Moves Up the Stack and Competes With the Platforms It Powers
Docker Reruns the Container Playbook, This Time for Cloud Sandbox Kit
Anthropic’s 80% Prompt Cut Shows AI Creating Its Own Technical Debt
Can Zscaler Own the AI Agent Control Plane?
Author Information
Vikram Rathnam is Research Director, Software Lifecycle Engineering at The Futurum Group. His research examines how software is built, tested, secured, and operated as AI agents move from assisting developers to doing the work. His coverage includes observability, platform engineering, and the control planes that govern agents. Before joining Futurum, he spent 24 years on the vendor side: ten in engineering at Silicon Labs and fourteen in product and partner strategy, with roles at Cisco, Secureworks, Dell, and CMIT Solutions. Across those roles, he managed B2B cybersecurity, IoT, and AI products, with partner and channel ecosystems as the common thread. At CMIT Solutions, he led product strategy across a franchise network of 180 locations. He reads a vendor’s roadmap as someone who has had to ship one and take it to market.
Mitch Ashley is VP and Practice Lead for the CIO & Technology Buyers and Software Lifecycle Engineering practices at The Futurum Group. A multi-time CIO and CTO with 30+ years leading technical organizations, Mitch built and operated production systems spanning cybersecurity for the U.S. Department of Defense, PKI services for the broadband and 5G industries, SaaS platforms, large-scale telecom and banking systems, and a national broadband network. His work with AI began early, developing expert systems that diagnosed and repaired complex mainframe environments. That operator foundation grounds his analysis in operational consequence, covering the technology buyer's world of software engineering, cybersecurity, DevOps, cloud, and AI.
