Almost never. A bot needs the specific permissions its steps use and nothing more. Admin rights are usually granted to make setup easier, and then stay. They turn a small mistake or a stolen credential into a large incident. Overprivileged non-human identities are the fifth risk in the OWASP 2025 list.
Why admin sneaks in
During build, a bot fails with an access error. The fastest fix is a higher role. The bot works, the project moves on, and nobody lowers the access. Months later the bot can read and change far more than its task requires.
The OWASP Secrets Management Cheat Sheet states the principle directly: secrets must have the minimum privileges assigned to enable their required use or role.
How to find the minimum
- Write down every action the bot performs, in order, per system. Read this record, create that record, update this status.
- Map each action to the smallest permission that allows it. Many systems offer custom roles or field level rights.
- Create a role with only those permissions. If the system has only broad roles, pick the narrowest and record the exception.
- Run the bot in a test environment using that role and see what fails.
- Add back only what a failing step proves is needed, and write down why.
- Repeat after each workflow change.
Read, write and delete are different
| Permission | Typical need | Note |
|---|---|---|
| Read | Most bots | Limit to the tables or folders used |
| Create | Bots that enter data | Often safe to allow without edit |
| Update | Bots that change status | Limit to the fields touched |
| Delete | Rarely | Prefer marking as inactive |
| Admin or configuration | Almost never | Needs written justification |
Other ways to shrink the blast radius
- Time. If a bot runs once a night, restrict sign in to that window.
- Place. Allow the account to sign in only from the machines that run the bots.
- Data. Give the bot access to the subset of records it processes, not the whole set.
- Approval. For high impact actions, require a person to approve, so the bot cannot complete them alone.
Document exceptions
Some legacy systems force broad roles. Record the exception, the compensating controls such as extra logging, and a date to review. This is a normal result of working with old systems, as long as it is written down.
Check it again later
Bots drift. Workflows change, systems add features and roles expand. Include permission checks in your regular access review, as in our quarterly bot access review checklist.
Where Safeguard fits
Safeguard's policies, gates and guardrails apply to the software supply chain work it covers. It does not set permissions in your RPA or business applications.
Quick check
What is the quickest way to cut a bot's access?
Remove admin first, then test. Add back only what a failing step proves is needed.
Is a read only bot risk free?
No. A read only bot with broad access can still expose a lot of data if its credentials leak, so scope the reads too.
Sources
Last reviewed: 19 October 2026.
