Yes. Give every AI-built prototype an owner and an expiry date when it is created. On that date it is either promoted through review or shut down and deleted. Without an expiry, prototypes linger with live credentials, open endpoints and unpatched packages long after anyone remembers them.
The forgotten prototype problem
Prototypes are cheap to build, so teams build many. Few teams track them. Months later there is a deployed app nobody owns, running old dependencies, holding a key that still works, perhaps reachable from the internet. It was never meant to be production, so no one watches it. That gap is where trouble starts.
An expiry date turns "we should clean that up someday" into a scheduled decision.
What an expiry policy needs
- A registry. One shared list with the prototype name, owner, purpose, location and expiry date. A spreadsheet or a labelled repository topic is enough to begin.
- A default lifetime. Thirty days is a common starting point, long enough to learn something and short enough to stay in memory. Choose what fits your team.
- A named owner. A person, not a team alias.
- Two outcomes. Promote or retire. Extending is allowed once, with a reason.
- Automatic reminders. Notify the owner a week before expiry and again on the day.
What retiring means
Deleting the repository is not enough. Run through this list:
- Take down the deployment and release the domain or subdomain.
- Revoke every key and token the prototype used.
- Remove its service accounts and test users.
- Delete stored data and backups created for it.
- Mark the registry entry closed with the date.
Revoking keys matters most. A deleted app whose key still works is a loose end.
What promoting means
Promotion is not extension with a new label. It goes through your normal review: owner confirmed, risky code reviewed, dependencies vetted, secrets moved, gates enabled. The article on taking a prototype to production safely covers that checklist, at /resources/blog/take-an-ai-built-prototype-to-production-safely.
A worked example
A product manager builds an internal pricing calculator with an AI tool on a Monday. The registry entry says owner: the product manager, purpose: test a discount model, expiry: thirty days out. On day twenty-three a reminder arrives. The team decides the idea is useful, so the calculator goes through the promotion checklist, gets a code review and moves into the pilot tier. A second prototype from the same week gets no reminder response, so on expiry its hosting is shut down and its keys are revoked. Both outcomes were decided, not drifted into.
Making the habit stick
Put the expiry into the template. If every new prototype repository starts from a template with a small metadata file, the owner and date are filled in on day one. A scheduled job can then list repositories past their date.
Hold a monthly ten-minute review of the registry. Ask which prototypes are about to expire, which have been extended, and which have no owner.
Where Safeguard fits
Safeguard's asset discovery helps surface assets you did not know were running, which feeds a registry like this one. Dependency scanning shows which of them carry known vulnerabilities. Try the free scan at gold.safeguard.sh/scan.
Quick check
How long should a prototype live?
There is no fixed answer. A short default, such as thirty days, with one documented extension keeps the list small and the owners engaged.
What if the prototype is a hit?
Great, then promote it properly. Success is a reason to review it, not a reason to skip the review.
Last reviewed: 19 October 2026.
