A quarterly bot access review asks six questions about every bot: who owns it, why it exists, what it can reach, how its credentials are stored, when it last ran, and who approved its last change. Anything with no good answer gets fixed or retired. It usually takes about an hour per group of bots.
Why review bots separately from people
People reviews work from an HR list. Bots appear on no such list. The OWASP Non-Human Identities Top 10 for 2025 includes overprivileged identities, long-lived secrets and improper offboarding, and each of those builds up silently between reviews. A bot review is how you catch them.
Before you start
Pull three things together: the bot inventory, the account list from each target system filtered to bot accounts, and recent run history. If the account list shows an account that is not in the inventory, that is your first finding.
The review table
Use one row per bot.
| Field | Question | Red flag |
|---|---|---|
| Owner | Is the named owner still in the role? | Owner left or is blank |
| Purpose | Does the business process still exist? | Nobody can describe it |
| Account | Is it dedicated to this bot? | Shared or a person's login |
| Permissions | Do they match the task today? | Admin rights, or access to systems the task no longer uses |
| Secrets | Where are credentials stored, and when were they last rotated? | In workflow files, or never rotated |
| Last run | Did it run recently and succeed? | No runs, or failing for weeks |
| Last change | Who approved the latest edit? | No record |
The steps
- Export the inventory and mark any bot whose owner has changed.
- For each bot, compare the permissions in the target system with what the workflow actually does. Anything the workflow never touches is a candidate to remove. The OWASP Secrets Management Cheat Sheet states that secrets must have the minimum privileges needed for their role.
- Check secret age. The same cheat sheet advises rotating regularly so stolen credentials work only for a short time, and setting expiry where possible.
- Look at run history for gaps. A bot that stopped running months ago may be dead weight. A bot that runs far more often than before may be misbehaving.
- Record each decision: keep, reduce access, rotate, reassign or retire.
- Assign a due date and a person to every action, then check those dates at the next review.
What to keep as evidence
Keep the dated table, the decisions and the follow-up. If a customer or auditor later asks how you manage non-human access, a dated record of a recurring review is a more convincing answer than a policy sentence. Do not describe the review as a certification or attestation, it is simply a control you operate.
Scale it with tiers
If you have many bots, review sensitive ones, such as those touching payments or personal data, every quarter, and the rest twice a year. Move a bot up a tier when it gets new access.
Where Safeguard fits
Safeguard's compliance and evidence automation can help you collect and keep review records over time, and asset discovery helps you find systems missing from your inventory.
Quick check
Who should run the review?
A person independent of the bot's builder, for example a security or IT operations lead, with each owner confirming their own rows.
What if a bot cannot lose any permissions without breaking?
Document why, set a date to revisit, and consider splitting the bot so only the part that needs the access has it.
Sources
Last reviewed: 19 October 2026.
