The environment has thirty-four resources, including a VPC, subnets, an RDS instance, and a load balancer that hasn’t seen any traffic in weeks. The owner tag reads deploy-agent. Nobody typed that in; it was auto-populated because the identity that ran that apply doesn’t have an individual name, badge, or last day.

That last part is the crux of the problem. A departed employee at least leaves some kind of trail: an exit interview, a Slack history, the manager who inherited their mess. Agents leave none of that. The task finishes, the context window closes, and whatever they built keeps consuming resources like forgotten candles steadily burning up your cloud bill.

“The task finishes, the context window closes, and whatever they built keeps consuming resources like forgotten candles steadily burning up your cloud bill.”

This is the same discovery-and-transfer challenge our last two articles addressed, but it’s happening much faster and from unpredictable angles. A person’s ownership goes stale after a badge cycle or reorg. An agent’s goes stale the second the task is done, which in some instances could be minutes. Luckily, the fix doesn’t change: it’s still a query, a policy, and a guardrail. The only difference is what each checks for, because you’re not looking for a person this time; you’re hunting service accounts.

CloudQuery’s asset inventory already tells you who owns a tagged resource. All you have to do is extend the question to ask whether the owner is a person.

Source link