AI agents that run Terraform or similar apply steps now leave resources tagged with a generic owner like deploy‑agent. The change is that these tags no longer map to a human identity, so the usual person‑based ownership model breaks down. Practitioners need to detect such orphaned assets, enforce policies that require a real person’s email as the owner, and ensure that agent‑created environments have a finite lifespan.
Identifying AI‑Agent‑Owned Resources
The first step is to query the cloud inventory for any resource whose owner tag resolves to a non‑human principal. CloudQuery already stores a unified view of assets; extending the query to cross‑reference the tag against the organization’s identity directory surfaces the outliers. A representative SQL‑like statement looks like this:
SELECT cloud, account, resource_type, name, tags['owner'] AS owner
FROM (
SELECT * FROM cloud_assets
ORDER BY _cq_sync_group_id DESC
LIMIT 1 BY _cq_platform_id
)
WHERE tags['owner'] != ''
AND (
(cloud = 'aws' AND tags['owner'] IN (SELECT role_name FROM aws_iam_roles))
OR (cloud = 'azure' AND tags['owner'] IN (SELECT display_name FROM entraid_serviceprincipals))
OR (cloud = 'gcp' AND tags['owner'] NOT IN (SELECT primary_email FROM googleworkspace_users))
)
ORDER BY cloud, resource_type, name;
On AWS and Azure the IAM layer directly reports role names, confirming a machine identity. GCP lacks a comparable IAM field, so the check is inverted: if the tag does not match any known employee email, it is treated as non‑human. The result is a concise list of resources that may need human review.
Policy Enforcement to Prevent Stale Ownership
Detecting orphaned assets is only half the solution. Env0’s policy engine can block any deployment that does not explicitly name a person as the owner. The policy examines every taggable resource in the plan, validates the presence of an owner tag, checks that the value matches an email pattern, and rejects any match against a predefined list of agent identities.
package env0.is_deploy {
startswith(input.deploymentRequest.type, "deploy")
}
owners[[rc.address, owner]] {
rc := input.plan.resource_changes[_]
owner := rc.change.after.tags.owner
}
owners[[rc.address, owner]] {
rc := input.plan.resource_changes[_]
owner := rc.change.after.labels.owner
}
has_owner(addr) { owners[[addr, _]] }
tagged(after) { is_object(after.tags) }
tagged(after) { is_object(after.labels) }
deny[msg] {
is_deploy not input.policyData.agent_identities
msg := "policyData.agent_identities missing; cannot verify ownership"
}
deny[msg] {
is_deploy rc := input.plan.resource_changes[_]
tagged(rc.change.after) not has_owner(rc.address)
msg := sprintf("%s missing owner tag", [rc.address])
}
deny[msg] {
is_deploy owners[[addr, owner]]
not regex.match(`^[^@\s]+@[^@\s]+\.[^@\s]+$`, owner)
msg := sprintf("%s: owner %s is not a valid email", [addr, owner])
}
deny[msg] {
is_deploy owners[[addr, owner]]
lower(owner) == lower(input.policyData.agent_identities[_])
msg := sprintf("%s: owner %s is an agent identity", [addr, owner])
}
allow { count(deny) == 0 }
The agent_identities JSON file is small (e.g., {"agent_identities": ["deploy-agent", "svc‑agents@my‑project.iam.gserviceaccount.com"]}) and must be supplied to the policy. If the file disappears, the policy fails closed, preventing any apply from passing without a proper owner.
Lifecycle Management for Agent‑Created Environments
Even with query and policy in place, existing resources lack a “last‑day” trigger that would automatically start a review. Env0 provides an environment TTL feature that can destroy all assets after a configurable period. Applying TTL to agent‑generated environments gives a deterministic cleanup window, reducing the risk of forgotten resources inflating the cloud bill.
Key operational steps include:
- Assign a scoped API key to each agent rather than using an admin‑level key.
- Configure the key with a role limited to the specific environment the agent manages.
- Enable the TTL setting on those environments so that any resource without a subsequent human‑approved change is automatically terminated.
Related CloudNinjas coverage: DevOps.
What This Means For Practitioners
AI‑agent ownership introduces a gap in traditional human‑centric governance. Teams should immediately adopt a two‑pronged approach: run the cross‑cloud query to surface existing agent‑owned assets, and enforce an OPA‑style policy that blocks future deployments lacking a real person’s email. Pair the policy with scoped agent keys and environment TTLs to guarantee that any orphaned resources are reclaimed without manual intervention. Regularly audit the agent_identities list and update it as new automation accounts are introduced.
