A bot should be retired by its named owner, with a second person confirming, using a short checklist: stop the schedule, revoke credentials, disable the account, remove access and secrets, archive the workflow and update the inventory. Improper offboarding is the first risk in the OWASP Non-Human Identities Top 10 for 2025.
Why bots outlive their purpose
A process changes, a team reorganises, the person who built the bot moves on. The bot keeps running because nobody told it to stop, and nobody wants to be the person who breaks a quiet job. Its account keeps a valid password, and its permissions stay as they were. That is the exact scenario the NHI list calls improper offboarding.
Decide when a bot is due to retire
Retire a bot when any of these is true:
- The process it supports no longer exists.
- The owner has left and nobody has accepted ownership.
- The target system is being replaced.
- It has not run successfully in a period your team sets, such as a quarter.
- A review could not name a business reason for it.
The checklist
- Confirm the owner and a second approver. If there is no owner, a manager approves.
- Check what depends on the output. Search for downstream reports, files or jobs that read what the bot writes.
- Pause the schedule or trigger. Wait a short, agreed period to see if anyone notices.
- Revoke or delete the bot's credentials in the secret store. The OWASP Secrets Management Cheat Sheet says secrets that are no longer required must be securely revoked.
- Disable, then later delete, the bot's account in each target system.
- Remove the bot from any group, role or approval list.
- Remove API tokens, keys and webhooks it used, and check whether another bot shares them.
- Archive the workflow definition and run logs according to your retention rules, then delete the live copy.
- Update the inventory with the retirement date and who approved it.
- Record any exceptions, for example a shared credential that must stay for another bot.
Common traps
Shared credentials. If three bots share one login, retiring one cannot revoke it. That is another reason to give each bot its own identity.
Borrowed personal logins. When a bot runs as a person, offboarding the person breaks the bot, and keeping the person's account alive for the bot is the wrong fix.
Forgotten copies. Test and development copies of a bot often hold the same credentials as production.
Make it routine
Add bots to your joiner, mover and leaver process. When a person leaves, list the bots they own and reassign or retire each one. A short quarterly review of owner, last run and purpose catches the rest. We describe a related clean-up for connections in zombie connections in low-code platforms.
Where Safeguard fits
Safeguard's asset discovery and compliance evidence automation can help you keep an inventory current and keep the retirement records, though it does not disable bot accounts for you.
Quick check
Should I delete a retired bot or just disable it?
Disable first, wait a short agreed period in case something depends on it, then delete according to your retention rules.
What if nobody knows who owns a bot?
Pause it, ask the likely teams, and if no one claims it within a set time, retire it with manager approval.
Sources
Last reviewed: 19 October 2026.
