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_BYandLAST_UPDATED_BYhold the user ID fromFND_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_LOGINSand 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.
- Its own identity. One identity per bot, never shared with a person or another bot (IA-2, IA-4).
- A named human owner. A person who answers for it, reviews it and retires it (AC-2).
- Its own scopes. Only the access its task needs, with duties split across identities (AC-5, AC-6).
- A credential that expires. Rotated on a schedule and whenever the owner changes (IA-5).
- An attributable log. Every action is recorded under the bot’s own account, and its owner is on record (AU-3).
- 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
- All software identities. Non-human identity compares service accounts, keys, workloads and agents.
- People in EBS. Oracle EBS SSO removes local passwords for staff.
- EBS sign-in dates. Oracle Access Manager 12c end of support gives the dates and the options.
- EBS cut-over. Replace Oracle Access Manager for EBS sets out the cut-over plan.
- More explainers. The Learn hub lists related pages.
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).