When an AI agent creates a virtual network, databases, or a load balancer, the problem does not end when the task is complete. The resource may remain running, consuming budget and requiring maintenance, while its ownership tag points to a machine identity such as deploy-agent rather than to a person who can be contacted or held responsible for the resource.
The article presents this issue as a governance gap in cloud infrastructure: the execution identity that created the resource is not necessarily its actual owner. As the number of agents and the speed at which they create resources increase, traditional employee-based ownership mechanisms become insufficient.
Discovering Resources Owned by Agents
The first step is to inventory resources that have an owner tag, then compare the value of that tag with the organization's identity directory. In AWS and Azure, the tag can be matched against records of roles or native service principals. In Google Cloud, the article proposes verifying that the owner's value exists in the employee directory; if it does not, then it is not a human identity under the checking rule being used.
The appearance of a machine identity does not mean that the resource is illegitimate; the automation may have been designed to operate infrastructure on behalf of the organization. However, this check narrows the review scope to resources that actually need a human owner to be assigned.
What Changes in Practice?
Instead of automatically accepting the person or account that executed the deployment plan as the owner, the approval policy should verify the ownership tag itself. The proposed rule is that no deployment should pass if the taggable resource has no owner, if the owner's value is not in the form of a person's email address, or if it matches one of the known agent identities.
The article recommends keeping the list of agent identities in a JSON file that is passed to the policy engine. If the list is absent, the policy should fail closed rather than allow deployment without inspection. It also warns against using API keys with administrative privileges; instead, it proposes giving each agent a User-type key within a separate team and with limited permissions on the environment in which it operates, while avoiding shared tokens.
Setting Environment Lifetimes
Deployment policies alone are not enough to address old resources that agents have already created. The article therefore proposes using an environment expiration period, with a person creating the environment and setting its lifetime while the agent performs the deployment inside it. In this way, expiration warnings reach a human party capable of taking action instead of being sent to a machine identity that does not have a mailbox.
The article states that env zero warns the environment creator before automatically destroying it at two intervals: two days and two hours and thirty minutes. It also refers to a model at Axiom that automatically deletes an account if it is not claimed within 24 hours.
Why Does This News Matter?
The article links the growing scale of the problem to the increasing number of agents within organizations. According to Gravitee's 2026 survey, the average number of enterprise agents nearly doubled over four months, between December 2025 and April 2026, while more than one-third of organizations were operating more than 100 agents. Surveys conducted by Larridin also found an average of 47 agents in enterprise environments without an assigned owner.
Investigation becomes more difficult when agents use a shared service account; the log may prove that the resource was created, but it does not clarify which execution, request, or decision led to it. Therefore, assigning an explicit human owner addresses not only costs but also part of the accountability gap in audit records.
The open limitations are also clear: the success of these controls depends on the accuracy of identity directories, on agents not bypassing authorization policies, and on the existence of a consistent organizational definition of who actually owns the resource. The source itself is a guidance article sponsored by env zero, so its product-specific recommendations should be treated as proposed solutions rather than as the market's sole standard.