SSOGEN / Learn / RPA Service Account EBS Audit: Why Bots With Human Passwords Are a Finding

Learn

RPA Service Account EBS Audit: Why Bots With Human Passwords Are a Finding

In an RPA service account EBS audit, a bot that signs in to Oracle E-Business Suite with a person's user name or a shared account is a finding, because nobody can prove who acted, who owns the bot, or when its password last changed.

Updated

The short answer. An RPA service account EBS audit flags a bot that uses a person’s or a shared Oracle EBS account. The log names the person, the password rarely changes, and nobody owns the bot.

The fix. Give each robot its own account, a named human owner, only the access its task needs, a credential that expires, and an off switch.

Why do auditors flag bots that sign in as a person?

Auditors flag them because NIST SP 800-53 control IA-2 requires each user to be uniquely identified, and a bot on a borrowed account is not. Robotic process automation (RPA) bots that key invoices into Oracle E-Business Suite (EBS) often sign in as their builder or as a shared account. Each row below is a finding with the control it tests.

Finding, and why it is flagged NIST SP 800-53 Rev. 5 What closes it
Bot uses a person’s account. Every action reads as that person’s work. IA-2, AU-3 One account per bot, never a person’s
Bots and people share one account. No action traces to one subject. AC-2(9), IA-2(5) Separate accounts; no interactive use of the bot’s account
No accountable owner. Nobody approves, reviews or retires the account. AC-2 b, e, j A named person as owner, plus a review date
Password never rotated. A static secret outlives staff changes. IA-5 f, i A credential that expires, rotated on owner change
Bot holds conflicting duties. One account can create and approve a transaction. AC-5, AC-6 Access for one task; conflicting duties on separate accounts
Bot exempt from MFA and lockout. The account skips the controls that protect people. IA-2(1), IA-2(2), AC-2(3) A documented exception, an expiry and regular review

What Oracle EBS records when a bot uses a person’s account

EBS records the application user, not the program behind it (Oracle E-Business Suite Security Guide, Release 12.2).

  • Who columns. CREATED_BY and LAST_UPDATED_BY hold the user ID from FND_USER. A bot signed in as Maria Lopez writes rows that say Maria Lopez created them.
  • Sign-On Audit. At the Form level, EBS logs every sign-on, responsibility and form to FND_LOGINS and related tables. Those records also name the borrowed account.
  • Password expiration. The Users window sets expiry by days or by number of sign-ons, then shows a pop-up asking the user for a new password. A bot cannot answer a pop-up, so its account breaks or never expires.
  • Security user type. Since Release 12.2.13, the profile option FND: Security User Type marks an account NAMED, SYSTEM or PUBLIC. SYSTEM and PUBLIC accounts are exempt from the inactive-user locking policy.
  • Proxy users. For people, Oracle offers the proxy user feature, which it describes as limited, auditable delegation. It is the alternative to sharing a password.

For people, Oracle EBS SSO removes local EBS passwords altogether.

How RPA tools sign in, and which account the auditor means

An unattended bot usually signs in twice: once to the machine it runs on, and once to EBS.

  • UiPath. Orchestrator offers robot accounts for back-office unattended processes and calls them its equivalent of service accounts.
  • Microsoft Power Automate. An unattended desktop flow signs in to the machine with the Windows user stored in its desktop flow connection. That user needs rights to open a remote desktop session.
  • The EBS account. The user name the bot types into EBS is a separate credential. It is the one in the Who columns and the one the auditor tests.

A dedicated robot account in the RPA tool does not fix a borrowed EBS account. Review both layers.

Worked example: the Acme Corp invoice bot

Acme Corp runs a bot that keys supplier invoices into EBS at ebs.acme.example. James Carter built it two years ago.

Item Before After
EBS account JCARTER, James Carter’s own user AP-INVOICE-BOT, used by nothing else
Owner Nobody recorded Maria Lopez (AP manager), with a review date
Access All of James Carter’s responsibilities Invoice entry only; approval stays with people
Credential Password set once, never changed A credential that expires, rotated on owner change
Audit record Every invoice “created by James Carter” Every invoice “created by AP-INVOICE-BOT”; the owner is on record
Stopping it Change James Carter’s password and break his day Disable the bot’s account; people keep working

The fix: one identity per robot

Six properties close every finding in the table above.

  1. Its own identity. One identity per bot, never shared with a person or another bot (IA-2, IA-4).
  2. A named human owner. A person who answers for it, reviews it and retires it (AC-2).
  3. Its own scopes. Only the access its task needs, with duties split across identities (AC-5, AC-6).
  4. A credential that expires. Rotated on a schedule and whenever the owner changes (IA-5).
  5. An attributable log. Every action is recorded under the bot’s own account, and its owner is on record (AU-3).
  6. An off switch. Suspend one bot, or all bots of one kind, in a single action (AC-2 f).

The AI agent governance checklist applies the same properties to AI agents.

How SSOGEN gives each AI agent and automation its own identity

SSOGEN registers AI agents, MCP clients, automations and services as non-human identities, each with its own owner, scopes, key and off switch.

  • Owners. One to five owners, always people, never groups. When its owner leaves, the identity is suspended until a new owner is added.
  • No password. The identity proves itself with a key; you register only the public key, and SSOGEN refuses a private key.
  • Scopes. Access is granted per application and scope. A sensitive scope needs a person’s approval at every use.
  • Short tokens. Tokens expire within minutes, and an Expires on or Review by date of at most 365 days is required.
  • Off switch. Owners can suspend their own identity. A super administrator can stop every identity of one type with its kill switch.
  • Audit. Every registration, grant and decision is recorded in the audit log.

For EBS, the MCP Gateway checks each tool call an agent makes against its granted scopes. See AI agent identity, the registration guide and the EBS MCP guide.

Questions people ask

What is an RPA process?

An RPA process is a rule-based task that software performs through an application’s screens or interfaces, the way a person would. Typical examples are keying invoices, copying data between systems and running scheduled reports. Each RPA process signs in somewhere, so each one needs its own account, an owner and access limited to that task.

What is RPA in accounts payable?

RPA in accounts payable uses bots to read supplier invoices, key them into the ERP and match them to purchase orders. In Oracle EBS, the bot should enter invoices under its own account, with no right to approve them. Approval stays with a person, which keeps separation of duties intact.

Can an RPA bot share an account with a person in Oracle EBS?

It can technically, but it is an audit finding. EBS writes the account’s user ID into the Who columns, so the bot’s work is recorded as the person’s. NIST SP 800-53 AC-2(9) permits shared accounts only under conditions an organization sets and documents.

Where to go next

Sources, all read 2026-11-13:

  • NIST SP 800-53 Rev. 5, controls AC-2, AC-2(3), AC-2(9), AC-5, AC-6, AU-3, IA-2, IA-2(1), IA-2(2), IA-2(5), IA-4 and IA-5 (NIST OSCAL catalog, release 5.2.0).
  • Oracle E-Business Suite Security Guide, Release 12.2: auditing and logging features and user management; the proxy user feature chapter (Oracle).
  • Account types, UiPath Orchestrator documentation, Automation Suite 2.2510 (UiPath).
  • Run unattended desktop flows, Power Automate documentation (Microsoft Learn, updated 2026-08-31).