People log in as a bot account because it is faster than asking for access: they debug a failing run, fix a record, or avoid an approval. It hides who really acted and spreads a password that was meant to live in one place. Stop it by removing the need, then blocking interactive sign in.
Two named risks
The OWASP Non-Human Identities Top 10 for 2025 lists human use of non-human identities as one risk and non-human identity reuse as another. They are close relatives. Once a few people know a bot password, it is shared, and any action under that account could be anyone.
Why people do it
| Reason | What it signals |
|---|---|
| To see what the bot sees while debugging | No test environment, or no read access for support |
| To fix a stuck record | No sanctioned way to correct data |
| To avoid waiting for access | A slow access request process |
| Because the bot has more rights than they do | An overprivileged bot, or an under-resourced team |
| Because the password is known to the team | Credentials stored in the open |
Each reason points to something fixable.
The fix, step by step
- Move bot credentials into a managed store so people do not hold them. The OWASP Secrets Management Cheat Sheet advises centralising storage, provisioning, auditing and rotation.
- Block interactive sign in for bot accounts where the target system allows it, so the credentials work only from the bot's machine.
- Alert on a bot account signing in from an unexpected place or time, since that is the footprint of a human using it.
- Give support staff read access to run logs and a test copy of the bot, so debugging does not need the live account.
- Provide a sanctioned way to correct data, with approval and a record.
- Speed up access requests for the support team, so waiting is not a reason to cut corners.
- Rotate the password whenever someone who used it moves on, and after you stop the practice.
What to say to the team
Frame it as protecting them. When an incident happens, shared bot logins make it impossible to show who did what, and that can put an honest person under suspicion. A clear trail clears them.
Spot check
Choose one bot each month. Check its sign in history for interactive sessions and compare against the schedule. A bot that was used by hand shows up quickly.
Exceptions
In a real emergency someone may need to use the account. Allow a break glass route with a named approver, time limit and logging, and rotate the password afterwards. The cheat sheet covers break glass as part of secrets management.
Where Safeguard fits
Safeguard's compliance and evidence automation can help you keep records of access reviews and spot checks like this one.
Quick check
Is it wrong to log in as the bot to debug?
It is better to give support a test copy and log access. Live logins hide who acted and spread the password.
Can we block interactive sign in for every bot?
Not always. Some older systems cannot tell the difference. Where they cannot, add alerts and shorter rotation.
Sources
Last reviewed: 19 October 2026.
