By KYN AI Advisory Team — AI implementation specialists, Singapore
Autonomous agents orphan cloud resources when ownership is a label added after creation instead of a required field in the provisioning call. Weeks later nobody can say which agent or trigger created a database, queue or instance, so nobody dares delete it. This is resource cleanup paralysis. The fix is protocol design: a resource cannot be created unless it carries an owner, a purpose and an expiry, and the record of who made it is written at the same moment.
What is resource cleanup paralysis?
Infrastructure accumulates because deleting feels riskier than leaving it running. If you cannot attribute a resource, you cannot know what depends on it. So it stays, and it costs money and widens your attack surface.
Fact: this article reasons from design patterns in adjacent systems. We have no billing dataset or incident report on orphaned resources to cite. Treat the cost claims as questions to test in your own account.
Where does the ownership record get lost?
At one narrow moment. An agent decides a resource is needed and issues the provisioning call. The resource exists. Ownership is meant to follow from a separate tagging pass or a governance sweep. In that window the resource exists and its owner record does not.
Multiply that window by every agent that can provision. The question stops being about policy and becomes structural: does the protocol make the metadata mandatory at creation, or optional and reconstructable later?
Why do human tagging habits fail for agents?
Tag conventions assume a person filling in a form. That person remembers the project, the budget line and the expiry. Their name is on the request, which gives them a reason to tag properly.
An agent running a workflow step has none of that. It remembers intent only within the current step. An incomplete tag costs it nothing. Nothing in a typical protocol forces it to supply ownership before the call succeeds.
A tagging policy written as a document assumes someone will reconcile it by hand. That fails once agents provision faster than a person can review.
What should a provisioning call require?
Make these fields mandatory. Reject the call if any is missing.
| Field | Content | Why | |---|---|---| | Owner | A named person or team, not an agent | Someone can answer "can this go?" | | Requesting agent | The agent's own account identity | Traces the decision | | Trigger | The workflow, ticket or event that caused it | Explains why it exists | | Purpose | One line in plain words | Tells a reviewer what depends on it | | Expiry | A date, or "review by" date | Forces a decision | | Environment | Production, staging, test | Sets deletion risk |
Name the missing field in the rejection. "Missing owner" lets the agent correct itself in one round. "Request denied" does not.
Cap the retries. If the agent cannot supply the fields after a few attempts, the request goes to a named person.
How does the record stay current?
Write ownership to the system of record when the resource is created, not in a nightly job. Batch reconciliation reopens the window that causes orphaning.
Borrow the ledger idea from accounting. A double-entry ledger gives every transaction two sides and a permanent trail. A provisioning ledger gives every resource an owner entry that travels with it for its whole life. Reconciliation then becomes mechanical: list resources with no live claim against them.
What does a watchdog for orphans do?
Autonomous systems must police themselves because no person watches each job. A scheduler watchdog retries failed jobs. The infrastructure equivalent runs on a schedule and flags:
- Resources whose owner no longer exists in the directory.
- Resources past their expiry.
- Resources with no traffic or reads over a set period.
- Resources whose creating agent has been retired.
The watchdog flags. It does not delete. Deletion waits for a named person, with a short grace period and a snapshot before removal.
How should deletion work?
- The watchdog lists candidates with owner, age and last use.
- The owner confirms or extends the expiry.
- If no owner responds within the set period, a named administrator decides.
- The system takes a snapshot, deletes, and logs the actor and the evidence.
Deletion is irreversible, so it never runs unattended.
How do you measure success?
- Count of resources with no owner. The target is zero, and it should be checked daily.
- Share of provisioning calls rejected for missing fields. A high rate early on is normal. It should fall as agents learn the schema.
- Median age of flagged resources.
- Monthly cost of resources past expiry.
A worked example of one orphan
This example is illustrative. The resource and the sequence are invented.
An operations agent receives a task: "reconcile last month's supplier statements". It creates a temporary database to load the files and a storage bucket for the extracted PDFs. The task finishes. The agent moves to the next job, and the database and bucket stay.
Three months later a cost review shows a small database with low traffic and a bucket with 400 files. The creating agent has been retired. The ticket that triggered the job is closed. The tag says "ops". Nobody on the ops team created it, and nobody dares delete it in case an auditor needs the files.
With a mandatory provisioning call, the same creation would have recorded:
| Field | Value | |---|---| | Owner | Finance operations lead | | Requesting agent | Statement reconciliation agent | | Trigger | Task for the month-end close | | Purpose | Temporary store for supplier statement extracts | | Expiry | 30 days after task close | | Environment | Production |
On day 30 the watchdog flags it. The owner confirms that the extracts can go, a snapshot is taken, and the resources are removed. Total effort: one confirmation.
What are the typical sources of orphans?
| Source | Example | Control | |---|---|---| | Temporary stores | Scratch databases and buckets for one job | Expiry set at creation | | Test environments | Staging copies of production | Environment field, shorter expiry | | Failed runs | Resources created before a job crashed | Cleanup step in the failure path | | Retired agents | Resources whose creator no longer exists | Reassign owner when retiring an agent | | Snapshots and backups | Copies nobody reviews | Retention policy with a stated period | | Network pieces | Addresses, rules and routes left behind | Owner on every item, not only on the main resource |
Failed runs are the most overlooked. A job that creates three resources and crashes after two leaves a partial set. The failure handler must either finish the job or remove what it made.
What should happen when an agent is retired?
Retiring an agent is an offboarding event, and it needs the same checklist as a person leaving.
- List every resource where the agent is the requester.
- For each, confirm that a human owner is recorded. If not, assign one.
- Move any scheduled jobs the agent owned to a named person or turn them off.
- Revoke the agent's account and keys.
- Log the retirement with the date and the person who approved it.
If step 2 reveals resources with no owner, you have found the paralysis early, while someone still remembers what they are for.
How do you clear an existing backlog?
A backlog needs a different method than prevention. Work in stages, and do not delete first.
- Inventory. List every resource across all accounts and regions, with creation date, last use and any tags.
- Classify. Group into three: owner known, owner guessable (from names, tags or creator), and unknown.
- Ask. Send each guessable owner a list and a date by which to claim or release. Silence is not consent to delete.
- Quarantine. For unknown resources, remove public access and reduce them to the lowest running cost, without deleting. Watch for breakage for a set period.
- Snapshot and delete. After the period, with a named administrator's approval, take a snapshot and delete.
- Record. Log each decision with the actor and the evidence.
Expect the unknown group to be the smallest and the most tedious. The classify step makes the others tractable.
What edge cases catch teams out?
- Shared resources. A resource used by two teams has two owners. Name one accountable owner and list the other as a dependent.
- Resources that should live forever. Compliance archives and audit logs have no expiry. Use an explicit value such as "retain", with the reason and the review date.
- Auto-created dependencies. Some services create helper resources automatically. Tag the parent and make sure the tag is inherited, or the helpers become orphans.
- Cost allocation. If the owner field maps to a team, the cost shows in that team's report, which gives the owner a reason to act.
- Agents with elevated roles. An agent that can bypass tag rules will, whether by design or by a mistake in its instructions. Give agents the least privilege that lets them do the task.
What access should an ops agent have?
Provisioning rights should be narrow. Allow the agent to create the resource types its job needs, in the environments it works in, and only through the provisioning call that enforces the required fields. Do not give it rights to change tags after creation, remove tag policies or delete resources it did not create. Because every action is logged with the actor, an investigator can reconstruct what an agent did without relying on the agent's own account of it.
Review the permissions each quarter. Remove rights for tasks that no longer exist.
Where KYN fits
KYN builds operations agents on cloud infrastructure in the client's own account. Agents have their own restricted accounts through the cloud provider's identity service, and every action is logged with the actor. Deletions wait for a named person. In a manufacturer's build, eleven systems became three on one AWS account.
The first 14 days are a review: an inventory of your stack and interviews with the team. A full build ships in under 90 days. See infrastructure and security.
Frequently asked questions
Can tag policies in the cloud console solve this?
They help by rejecting untagged creation, if you enforce them. Add owner, purpose and expiry as required keys, and make sure agents cannot bypass the policy with an elevated role.
Should an agent be allowed to delete what it created?
Not without a named person. Deletion is irreversible, and the agent may not know who else now depends on the resource.
Who should own an agent-created resource?
A named person or team, never the agent. An agent is the requester. The owner is the human accountable for the cost and the risk.
Checked 30 October 2026.
Curious whether Marketing agents fits your business? Talk to KYN on WhatsApp — no forms, just a conversation.
