The Cloud Project Junk Drawer
Tables, datasets, pipelines, and service accounts spread across random cloud accounts, projects, and subscriptions because every urgent AI-assisted task created one more place data might be hiding.
What it is
The cloud estate stops looking like an architecture and starts looking like someone dumped a drawer onto the floor. Accounts, projects, subscriptions, datasets, tables, jobs, and service accounts exist because they helped one task finish once, not because they fit a designed environment model. Some are empty. Some contain data. Some run jobs. Some have permissions nobody is comfortable deleting because nobody can prove what they do.
How it happens
Someone gets a narrow task: load this file, test this pipeline, build this report, make this forecast, prove this integration works. They are not necessarily a cloud engineer. They may know the business problem, but not the account structure, environment model, naming conventions, data boundaries, or privilege rules. Then an AI assistant joins the loop with the same missing context.
The agent optimizes for the prompt it was given, not for the infrastructure you wish existed. If it needs a place to stage data, it creates a table. If it needs a container for the work, it creates a dataset, project, subscription, or account if the credentials allow it. If a name looks plausible, it uses it. The local outcome is success: the test ran, the chart loaded, the sync completed. The global outcome is another artifact with no durable owner, no lifecycle, and no relationship to the target architecture.
You usually discover it later as a scavenger hunt. The place that sounds like the obvious home is empty. Another account has most of the warehouse. A third looks like a leftover experiment. A shared dataset has random tables from one prompt, one test, one diagram, or one attempted migration. The agent did not maliciously choose the wrong structure. It had no structure to choose from, so it jammed the task into whatever surface area was available.
Why it’s dangerous
Cloud platforms are generous in all the wrong ways. They let people create another account, project, subscription, dataset, table, job, role, and key. AI makes the creation step even cheaper, which means the governing step has to get stronger. If it doesn’t, the company accumulates infrastructure and data artifacts faster than anyone can name, own, secure, or shut down.
The risk is not just clutter. It is data lineage nobody trusts, reports built on incomplete tables, duplicate tables with different answers, credentials with unnecessary blast radius, abandoned jobs still moving data, and cleanup work that becomes scary because the team cannot tell the difference between trash and load-bearing trash.
The AI-era hinge: the assistant is short-term focused by default. It is trying to satisfy the one-off test in front of it. Unless you give it the environment model through docs, skills, prompts, or policy-backed tooling, it has no way to infer the responsible future structure. The missing architecture becomes invisible input, and the output looks helpful right up until someone has to operate it.
How to prevent it
Before asking AI to touch cloud or warehouse resources, give it the map: what environments exist, which accounts or subscriptions are in scope, where scratch work belongs, which datasets are authoritative, what naming conventions apply, and what it may never create or modify. If that map does not exist, have AI help draft it first from the current estate and then treat the draft as something to review, not as permission to keep mutating the estate.
Scale rigor to stakes. A throwaway local CSV transform does not need an environment design. A task that can create cloud resources, persistent tables, service accounts, jobs, or data paths does. The friction signal is simple: if you cannot tell the agent where it is allowed to write, it should not have write access yet. Let AI explore with read-only credentials, produce the scavenger-hunt map, and propose changes. Do not let discovery become creation by accident.
The serious team fix
Three things, reinforcing each other:
- A documented account and environment model that agents can read. Write down the boring architecture: which accounts, projects, or subscriptions exist; which environments they represent; where shared data lives; where scratch work goes; what names mean; who owns each boundary; and what the target structure is supposed to become. Put that in a repo, runbook, or agent skill so the AI does not have to infer your cloud strategy from whatever resource names happen to exist today.
- Privilege boundaries that keep experiments from becoming architecture. People doing one-off analysis and the agents assisting them should not have standing access to create accounts, projects, subscriptions, service accounts, persistent tables, or pipelines wherever they want. Give them read-only discovery roles and constrained scratch areas. New durable resources go through the platform or admin path, where someone with the right context decides where the thing belongs before it exists.
- Automated drift detection for unmanaged cloud and data artifacts. Use policy, infrastructure-as-code checks, scheduled inventory, or an AI-assisted scout to flag resources that do not match the model: unexpected accounts or projects, persistent tables outside allowed datasets, jobs with no owner, service accounts with broad grants, names that violate convention. The system should notice the junk drawer forming before a human has to rediscover it by hand.
AI can move fast inside a structure. Without the structure, it will make a very helpful mess and call the prompt complete.