An attended bot runs on a person's desktop and works alongside them, while an unattended bot runs on its own, usually on a server or virtual machine, on a schedule or trigger. Attended bots borrow a person's session and access. Unattended bots need their own identity and tighter monitoring because nobody is watching.
Product vendors use these terms with small differences, so check how your own platform defines them. The comparison below describes the general pattern.
Side by side
| Question | Attended | Unattended |
|---|---|---|
| Whose access does it use? | Usually the signed in person | A dedicated bot account |
| Who is watching? | The person at the desk | Nobody, unless you add monitoring |
| Where does it run? | An employee workstation | A server or virtual machine |
| Typical trigger | A person starts it | Schedule or event |
| Main identity risk | Person's broad access used by a script | Bot account that nobody reviews |
| Main data risk | Data copied to a laptop | Data processed in bulk without checks |
Attended bots: risks to plan for
The bot acts as the person, so every permission the person has is available to the script. If the workflow is edited, or the laptop is compromised, a malicious script has a real employee's access. Keep attended bots to tasks the person is allowed to do anyway, restrict who may install or edit them, and keep the workstation patched and managed.
Data handling is the other worry. An attended bot that copies records into a local spreadsheet creates a copy outside your controls.
Unattended bots: risks to plan for
An unattended bot runs without anyone to notice odd behaviour, so the controls must notice for them. That means a dedicated account per bot, minimum permissions, credentials fetched from a managed store, and alerts when a run is much larger, longer or at a different time than normal.
Where the machine runs matters too. A shared virtual machine that hosts many bots lets a flaw in one workflow reach the others. Segregate bots that touch sensitive systems from those that do not.
Controls that apply to both
- Inventory: every bot, owner, systems touched, account used.
- Change control: approval before a workflow goes live or changes.
- Logging: tie each action to a bot, a workflow version and an owner.
- Failure behaviour: decide what the bot does when a screen looks different from expected. Stopping and raising an alert is safer than guessing.
- Offboarding: someone retires the bot when the process ends.
The OWASP Non-Human Identities Top 10 for 2025 lists improper offboarding and overprivileged identities among its risks, and both show up most with unattended bots.
Which to choose
Pick attended where a person should stay in the loop for judgement or approval. Pick unattended for steady, rule based, high volume work, accepting that you must build the monitoring yourself. If the task touches money or personal data, prefer a design with an approval step that a person completes.
Where Safeguard fits
Safeguard's asset discovery can help surface machines and services you did not know about, which is a common gap for bots on unmanaged desktops.
Quick check
Is an attended bot safer because a person watches it?
Not automatically. It uses the person's access, so a bad workflow can do whatever that person can. Review who can edit it.
Do unattended bots need MFA?
Interactive MFA does not fit a bot. Use dedicated accounts, managed credentials, restricted sign in and monitoring instead.
Sources
Last reviewed: 19 October 2026.
