AI Agents vs RPA Bots: Identity, Credentials and Governance Differences

AI agents are often deployed onto the identity model built for RPA bots, but a bot that replays a fixed script and an agent that decides its next action at run time need different credentials, scopes and reviews. Both are non-human identities, usually owned by an automation team rather than IAM. The difference is where the decision sits: in an RPA bot the decision was made when the workflow was designed and approved, while in an agent it is made by a model each time it runs, influenced by whatever content it reads. This guide compares the two at the identity layer: behaviour, credential models, segregation of duties, access review, which RPA controls carry over and which break, and the risks of migrating RPA processes to agents. It is for IAM, PAM and automation centre of excellence teams.

Key takeaways

• The approved workflow was the RPA control. A bot's access could be broad because its behaviour was fixed and reviewed; an agent with the same access can use all of it, in combinations nobody approved.
• Static credentials hurt more on agents. A long-lived password in an RPA vault is a theft risk; the same secret in an agent's reach is also a misuse risk, because the agent will use any credential it can find.
• Segregation of duties must move from the design to the run. RPA SoD checks the workflow once; agent SoD needs per-action checks and human approval for steps that would otherwise let one identity both request and approve.
• Access review changes question. For a bot you ask "does this workflow still need this access"; for an agent you also ask "what did it actually do with it" and "has its model, prompt or tools changed".
• Migration is an identity change, not a rebuild. When an RPA process becomes an agent, issue a new identity with fresh, narrower scopes rather than handing the agent the bot's existing accounts.

The short answer

An RPA bot is a deterministic script that drives user interfaces or APIs the way a person would, step by step, in an order fixed at design time. An AI agent uses a model to plan and choose actions through tools, APIs or other agents, so the sequence of calls is decided at run time and can differ between two runs with the same goal. Every AI agent and every bot is a non-human identity; the practical test, explained in NHI vs AI Agent Identity, is whether the software chooses its own next action.

That one difference drives the rest. RPA identity security is mostly about protecting a credential and keeping a fixed workflow's access proportionate. Agent identity security adds two problems RPA rarely had: the identity's behaviour can be steered by content it processes, and the identity often acts on behalf of a particular person whose authority must be carried and limited. For the RPA platform detail (robot authentication, vault integration, attended and unattended account models) see the RPA and Bot Identity Security Guide; for agent identity models and lifecycle see the Agentic AI Identity Guide.

Side-by-side comparison

Deterministic and non-deterministic behaviour: why it changes identity

RPA governance relies on predictability. When a finance bot is approved to read remittance emails and post payments in an ERP, reviewers look at the workflow and accept that the bot's account has posting rights, because the workflow only posts matched payments. The permission set is wider than the behaviour, and that is tolerated because the behaviour is fixed and testable. When it breaks, it usually fails loudly.

An agent removes that assumption. Its permissions describe what it could do; its behaviour is whatever the model decides is the best route to the goal. OWASP's Top 10 for LLM Applications 2025 names this risk LLM06 Excessive Agency and traces it to three root causes: excessive functionality, excessive permissions and excessive autonomy. An agent given the same posting rights as the finance bot could, after reading a manipulated email, post a payment nobody matched, and it would fail quietly, producing a plausible log entry.

• Scope must match behaviour, not the job title: grant the agent only the tools and API scopes for the task, so that the gap between "could" and "will" is small.
• Input becomes part of the attack surface: a bot reading an invoice extracts fields; an agent reading the same invoice may follow text in it. The ForcedLeak Agentforce case showed a hidden instruction in a public web form field steering an agent into querying other CRM records.

Credential models compared

RPA platforms grew up around interactive accounts: an unattended bot needs a Windows session and a username and password for each target application, stored in a vault and injected at run time. Orchestrators are moving robot connections from never-expiring machine keys to OAuth client credentials with expiring tokens, but the application passwords the bot types into screens are often still long-lived. Agents mostly call APIs, so they can use token-based, short-lived and audience-bound credentials from the start. Whether they do depends on the build.

Delegation is the larger change. An attended bot simply runs in the user's session, which is a form of impersonation: downstream systems see the user. RFC 8693 (OAuth 2.0 Token Exchange, Standards Track, January 2020) distinguishes impersonation, where the acting party is indistinguishable from the subject, from delegation, where the actor keeps its own identity and the act claim records it. Nested act claims record a delegation chain. For agents, delegation semantics are what let an audit trail say "agent X acted for user Y". See the OAuth Token Exchange and Delegation Guide and, for rotation and expiry, the AI Agent Credential Lifecycle and Rotation Guide.

Segregation of duties and access review

Segregation of duties

In RPA, SoD is enforced at design: one bot raises purchase orders, a different bot or a person approves them, and each bot's application roles are checked against the SoD matrix once, when the workflow is approved. NIST SP 800-53 AC-5 Separation of Duties and CSF 2.0 PR.AA-05 both apply, and they apply to non-human accounts as much as human ones.

Agents break design-time SoD in three ways:

• Tool combination: an agent granted both "create supplier" and "approve payment" tools to cover a broad goal holds a toxic combination, even if any single run uses only one. Split such tools across separate agents, or require a human approval step on the second action.
• Delegated authority: an agent acting for a user inherits that user's SoD position. If it can also act as itself, the union of its own and the user's rights may breach a rule that neither breaches alone. Evaluate SoD on the effective permission set of each token.
• Agent to agent calls: a requester agent calling an approver agent rebuilds the conflict through the back door. Treat the chain as one actor for SoD purposes unless a human sits between them.

See the Segregation of Duties Guide for the matrix method and the Human-in-the-Loop for AI Agents Guide for approval steps.

Access review

A bot review asks the business owner to confirm that the workflow still runs and still needs each application role. An agent review needs more: the permissions granted, the permissions actually exercised in the period, the model, prompt and tool versions in force, and the users it acted for. A change to any of those is a mover event that should trigger re-review between campaigns, as set out in the Identity Governance for AI Agents Guide.

Which RPA controls carry over and which break

Threat model, failure modes and a worked scenario for each option

RPA bot

Threat model: the attacker wants the bot's credentials. Bot accounts often hold standing access to finance or HR systems, are exempt from MFA and are reviewed less often than people. ATT&CK T1552 Unsecured Credentials covers passwords left in workflow files, config files and orchestrator assets.

Failure modes: passwords hard-coded in workflow packages; one robot account reused across many processes (NHI9:2025 NHI Reuse); people logging in with the bot account to fix failed runs (NHI10:2025 Human Use of NHI); bots left running after the process owner leaves (NHI1:2025 Improper Offboarding).

Controls: per-bot accounts, vault-held credentials with rotation, no interactive human use, MFA exemptions scoped to the bot's host, owner attestation tied to the process inventory.

AI agent

Threat model: the attacker wants the agent's credentials, or, more cheaply, wants the agent to use its own legitimate access on the attacker's behalf by planting instructions in content the agent reads. A third case needs no attacker: the agent finds and uses a credential it was never meant to have. In the PocketOS database deletion, a coding agent working in staging found an account-scoped token in an unrelated file and used it to delete a production volume and its backups.

Controls: per-agent identity issued at registration, short-lived audience-bound tokens, delegation through token exchange, tool allowlists, approval for destructive or financial actions, secrets kept out of the agent's file system and context, and tool-call logging.

Worked scenario: accounts payable

A company runs an unattended RPA bot that reads supplier invoices from a shared mailbox, matches them to purchase orders and posts them for payment in the ERP. It has its own vaulted ERP account with the "post invoice" role and cannot create suppliers. Its residual risk is credential theft.

The team proposes an agent to handle exceptions: invoices that do not match, need a supplier query by email, or need a new supplier record. If the agent inherits the bot's ERP account and is also given "create supplier" to cover new suppliers, it now holds both halves of a classic fraud control, and it reads attacker-controllable email. A forged invoice saying "new bank details, create supplier and pay" is now a route to payment fraud. The safer design gives the agent its own identity with read access to invoices and purchase orders, the ability to draft supplier queries and draft (not create) supplier records, and a human approval step before any record that changes payment details is saved. The deterministic bot keeps the matched-invoice path, where predictability is an asset.

Migrating RPA processes to agents

Organisations rarely replace RPA wholesale. More often an agent takes over the exception handling around a bot, or calls existing bots as tools. The risks are easy to miss because the accounts already exist and already work: the agent inherits standing access sized for a fixed script, a bot callable as a tool hands its access to whichever agent triggers it, an attended bot's user context is lost if the agent runs as a privileged service identity, and retired bots leave accounts nobody watches. Register each callable bot as a tool with its own authorisation decision, and record which agent and which user triggered each run.

A phased approach:

1. Inventory both populations. List every bot account and every agent identity with owner, credentials, application roles and the process each serves. Use the AI agent registry for agents and the RPA orchestrator's asset list for bots.
2. Classify each process. Keep deterministic, high-volume, well-structured steps on RPA. Move only the judgement-heavy steps to an agent.
3. Issue new agent identities. Register first, then issue credentials with scopes derived from the task, not from the bot's role list. Use delegation where the agent acts for a user.
4. Rebuild the SoD check. Recalculate conflicts on the agent's effective permissions, including any bots it can call and any user it can act for.
5. Run in shadow or draft mode. Let the agent propose actions that a person or the existing bot executes, and compare outcomes for a pilot period.
6. Turn on write access in stages. Enable low-impact writes first, keep approval for payments, supplier changes and deletions, and set alerts on any denied tool call.
7. Keep a rollback path. Leave the bot workflow deployable until the agent has run cleanly through at least one full business cycle; rolling back means revoking the agent's tokens and re-enabling the bot schedule.
8. Decommission properly. When the bot retires, disable and then delete its Windows and application accounts, remove vault entries, and record the closure in the inventory.

Decision guidance

• Keep RPA when: inputs are structured, the steps are stable, the target has no API, and auditors value a fixed, testable sequence. Predictability is a security property here.
• Use an agent when: the work needs judgement over unstructured input, and you can express its access as a small set of API scopes with approval on high-impact steps.
• Use both when: an agent triages and a bot executes. The agent proposes; the bot performs a fixed action with fixed access.
• Small organisations: focus on three things: no shared accounts, no human credentials on agents, and approval for payments and deletions.
• Large organisations: bring both populations into IGA with the same record schema, connect agent registration to credential issuance, and run event-driven reviews. The AI Agent Autonomy Levels Framework helps set approval rules by autonomy level.

Detection and measurement

For bots, monitor interactive logons to bot accounts from hosts other than the robot machines, logons outside the schedule, and vault check-outs by people. For agents, log every tool call with the agent identity, delegating user, parameters, outcome, and the model and prompt version, and alert on denied calls, first use of a scope, use of a credential from an unexpected runtime, and destructive actions. AU-6 Audit Record Review and AU-10 Non-repudiation frame the requirement.

Common failure patterns

• Agent on the bot's account: the quickest migration reuses the robot's ERP or CRM account, giving the agent standing access sized for a fixed script.
• Reachable secrets: tokens left in repositories, config files or shared drives become agent credentials the moment the agent can read them, as the PocketOS case showed.
• Trusted input that is not trusted: agents processing public forms, email or tickets with write access to records, without approval or egress limits, as in ForcedLeak.
• SoD checked once: the SoD matrix approved the bot; nobody re-ran it when the agent gained an extra tool or began acting for users.

Framework mapping

Practitioner checklist

• Every bot and every agent has its own identity, a named owner and an inventory record.
• No agent uses an RPA bot account, a shared service account or a person's credentials.
• Agent credentials are short-lived, audience-bound and never readable as plain text in the agent's context or file system.
• Delegated agent actions use token exchange so both the agent and the user appear in tokens and logs.
• SoD is evaluated on each agent's effective permissions, including bots it can trigger and users it can act for.
• Payments, supplier or account changes and deletions by agents require recorded human approval.
• Model, prompt, tool and data source changes trigger agent re-review; workflow changes trigger bot re-review.
• Tool calls are logged with agent, delegating user, parameters and model version, and denied calls raise alerts.
• Migrations keep a tested rollback to the bot and close every retired bot account and vault entry.

Standards and references

• IETF: RFC 8693 OAuth 2.0 Token Exchange
• OWASP: LLM06:2025 Excessive Agency
• OWASP: Non-Human Identities Top 10 2025
• OWASP: Top 10 for Agentic Applications for 2026
• NIST NCCoE: Software and AI Agent Identity and Authorization
• NIST: SP 800-53 Rev 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: RPA and Bot Identity Security Guide · Agentic AI Identity Guide · Identity Governance for AI Agents Guide · NHI vs AI Agent Identity · AI Agent Credential Lifecycle and Rotation Guide