Robotic process automation (RPA) is software that carries out tasks in business applications by imitating how a person uses them, following a predefined workflow. The main security risk is that each bot needs its own login and access, so bots become powerful accounts that few people review.
What RPA actually is
RPA uses scripts that mimic a person clicking, typing and copying data between screens. It is often used where an older application has no clean API. Wikipedia's overview describes it as following a predefined workflow, which separates it from AI that decides what to do.
That distinction matters for security. A bot does exactly what its workflow says, using whatever access its account has. If the workflow is wrong, or the account is over-broad, the bot does the wrong thing quickly and at volume.
Where the risk sits
The bot is code plus an identity. Most RPA risk comes from the identity side. The OWASP Non-Human Identities Top 10 for 2025 lists improper offboarding, secret leakage, overprivileged identities, long-lived secrets, identity reuse and human use of non-human identities among its ten risks. Every one of those applies to a bot.
| Area | What goes wrong | What to ask |
|---|---|---|
| Identity | One shared login for many bots | Does each bot have its own account? |
| Secrets | Passwords stored inside workflow files | Where do credentials live? |
| Privilege | Bot runs with admin rights "to be safe" | What is the least access it needs? |
| Change | Anyone edits a live workflow | Who approves changes? |
| Audit | Actions logged as "the bot" with no owner | Can you tie each run to an owner? |
| Offboarding | Bot outlives its builder | Who retires it? |
Why bots get less attention than people
People get joiner, mover and leaver processes. Bots rarely do. A bot built for a quarterly finance task may keep running, with a valid password, long after the team changed. The Wikipedia entry also notes that RPA tends to need ongoing maintenance when the underlying systems change, which means workflows get edited under pressure, often without review.
A short starting list
- List every bot, its owner, the systems it touches and the account it uses.
- Give each bot its own account, never a person's login.
- Move credentials out of workflow files into a managed store.
- Reduce each account to the permissions the task needs.
- Log runs so each action ties to a bot, a workflow version and an owner.
- Review the list on a schedule and retire what nobody owns.
None of this needs special tooling to begin. A spreadsheet and an honest hour with the team that built the bots is a fair start. The same ownership questions apply to no-code apps, covered in our post on what citizen developers mean for security.
Where Safeguard fits
Safeguard does not run or manage RPA platforms. It helps with the neighbouring problems: asset discovery to find systems and services you did not know about, and SBOM and dependency scanning for any custom code or libraries your automation team ships. You can try a free scan at https://gold.safeguard.sh/scan.
Quick check
Is RPA the same as AI?
No. RPA follows a predefined workflow. Some products add AI steps, which bring extra risks such as untrusted input, but the basic bot is rule driven.
Do bots really need separate accounts?
Yes. A separate account per bot lets you grant minimum access, trace actions to one bot and disable it without affecting others.
Sources
Last reviewed: 19 October 2026.
