Automation Anywhere Security: Hardening Control Room, Credential Vault and Bot Runners

An Automation Anywhere Control Room holds the keys to every system its bots touch, so a weak role model or a loosely shared locker turns one compromised account into access to finance, HR and customer applications at once. This guide covers the identity and access controls of Automation 360: Control Room roles, the Credential Vault and its lockers, the run-as accounts used by Bot Runners, API keys and external key vault integration, plus the audit events worth watching. Every product fact comes from Automation Anywhere's own documentation, checked on 8 November 2026. It is written for RPA platform owners, identity teams and security engineers who need to harden an existing Control Room, on premises or in Automation 360 Cloud. For the wider case that bots are identities, see the Service Account Security Guide.

This is an independent guide from NHI Mgmt Group, based on Automation Anywhere's public documentation as of November 2026. It is not sponsored or reviewed by Automation Anywhere. Product features change, so confirm settings against Automation Anywhere's current documentation.

Key takeaways

• AAE_Admin is the crown jewel. It is the only system role that can reach Control Room settings, which include authentication, auto-login and vault configuration, so treat its holders as privileged administrators with their own review cycle.
• Lockers are the real access boundary for secrets. A credential is usable by a bot only once it sits in a locker, so locker design and locker membership decide who and what can use each password.
• Bots should only ever hold references. Automation Anywhere designs bots to carry credential references rather than values; keep it that way by banning hard-coded secrets in task logic and reviewing for them.
• Move runtime secrets to an external vault where you can. Auto-login and automation credentials pulled from a supported external vault are not cached, so rotation in the vault takes effect on the next run.
• The audit log already records the events that matter. Credential reads without permission, locker changes, role edits, API key generation and device credential changes are all logged; forward them and alert on them.

How identity and access work in Automation Anywhere

Automation 360 has three identity layers, and each needs its own control. The Control Room user is the account that signs in to the web console or API. The device licence attached to that user decides what it can do on a machine. The run-as device credentials are the Windows account the Bot Agent uses to sign in to a device before it runs an automation. On top of these sit the credentials in the Credential Vault that bots use to sign in to target applications at runtime.

The documented licence types matter for access design. An Unattended Bot Runner supports Control Room deployment, centralised scheduling and API-based deployment, while an Attended Bot Runner runs bots on its own device, can use event triggers tied to its user or role, and cannot schedule bots. A Citizen Developer licence has the Bypass legal disclaimer option enabled automatically so bots can run without manual acknowledgement. Administrators cannot assign a device licence to themselves, which is a useful built-in separation between people who administer the Control Room and accounts that run bots.

For authentication, Automation 360 Cloud documents database authentication as the default and SAML-based single sign-on through an identity provider as the alternative, with a supported switch from database to SAML. Moving people to SAML puts sign-in policy, MFA and joiner, mover and leaver processes in your identity provider. See the Identity Provider and SSO Security Guide.

Admin roles and privileged access

Automation Anywhere ships system-created roles that can be modified and extended, and you can create your own. The roles that carry privilege are listed below, with the documented scope of each.

• Do not edit AAE_Admin into a general role: because system roles can be modified, a quick fix that adds permissions to a system role silently changes every holder. Create custom roles instead and keep system roles close to their documented scope.
• Watch the hidden credential readers: AAE_Bot Migration Admin can view and edit every credential attribute value. It is easy to forget once a migration finishes, so time-box it.
• Multi-login service users: only a Control Room administrator can mark a user as a multi-login service user, which allows several sessions. Keep a list of these accounts and confirm each still needs it.
• Attestation is a trust decision: users with the Attest device credentials permission can skip credential validation when deploying bots, which applies only with the auto-login setting "Reuse an existing session". Grant it narrowly.
• Break-glass: keep one database-authenticated AAE_Admin for identity provider outages, stored in your PAM tool and monitored. See the Break-Glass Account Guide.

Credential Vault and lockers

The Credential Vault is the central store for passwords, account numbers and other sensitive values used in automations. A credential holds attributes, for example a host name, username and password. Standard values are the same for every user (such as a host name), while user-provided values are entered by each user and appear in the CREDENTIAL REQUESTS tab. Credential and attribute names are not case-sensitive and are stored in lower case. Automation Anywhere describes the vault as provisioning credentials to bots on demand, with bots containing only credential references, so a bot moves between environments without changes. The Control Room also stores its own configuration secrets in the vault by default.

A credential must be assigned to a locker before a bot can use it. Lockers say which users can view, modify or use the credentials inside, and Automation Anywhere recommends organising them by business purpose or application class and by confidentiality level, with fewer consumers for more sensitive credentials. Users with AAE_Locker Admin, or a custom role with Manage my credentials and lockers, configure lockers and grant access.

1. One password per credential: follow the documented best practice of one password per credential for one system, so rotation and revocation affect one target only.
2. Locker per application and sensitivity: for example "SAP finance production" separate from "SAP finance test". Never mix test and production secrets in one locker.
3. Consumers are roles, not people: grant locker use to the role used by the Bot Runners for that process, and keep human developers out of production lockers.
4. Prefer standard values for unattended bots: user-provided values tie the secret to a person's entry, which breaks when that person leaves.
5. Review owners: AAE_Locker Admin can transfer ownership, so run a locker owner review alongside your access reviews. See the Access Reviews Guide.

Integrations, API tokens and service accounts

External key vaults

Automation Anywhere documents integration with CyberArk Password Vault, AWS Secrets Manager, Azure Key Vault, BeyondTrust Password Safe, ARCON Key Vault, HashiCorp Vault and Delinea Secret Server. The documentation splits the integration into four use cases with different caching and deployment support.

In Automation 360 Cloud the key vault stays inside your network and the connection is configured in the user interface, which needs network perimeter configuration on your side. Because auto-login and automation values are not cached, the vault can rotate them on its own schedule without breaking the next run. Agree credential naming conventions with your vault team at the start, as the documentation advises. See the Secrets Management Guide.

API keys

The Control Room API supports an apiKey for use with the Authentication API. Generating one needs the generateapikey permission; without it, users authenticate to the API with their account credentials. The audit log records each Generate API-Key attempt with a Successful or Unsuccessful status, and changes to API key duration. Grant generateapikey only to integration accounts, set the shortest key duration your integrations tolerate, store keys in your secrets manager rather than in scripts, and give each integration its own Control Room user so you can disable one without breaking the rest. See the API Key Management Guide.

Run-as accounts on Bot Runners

Auto-login uses the run-as user's device credentials. The Control Room offers three auto-login modes: Always create a new session (recommended for desktop deployments), Reuse an existing session (for event triggers and devices where new sessions cannot be created) and Reuse an existing session, if available. After a run the session can be logged off, left unlocked or locked, and per-device overrides are disallowed by default. From a security view, prefer a new session that is logged off at the end; a session left unlocked on a shared device is an open door. Each unattended run-as account should be a dedicated, non-human Windows account with only the logon rights the device needs.

Logging and detection

The Control Room audit log covers the identity events below. On premises, Syslog servers can be configured (host, port, TCP or UDP, secure connection), and changes to that configuration are themselves logged. Forward the log to your SIEM and build alerts on the events that indicate misuse. See the SIEM Guide.

Metrics that show the controls work:

• Number of AAE_Admin holders, and the share reviewed in the last 90 days.
• Percentage of unattended run-as and automation credentials sourced from an external vault.
• Count of active API keys and their maximum age.
• Number of Read credential or Read locker events per month (target: zero unexplained).
• Lockers with more than an agreed number of consumers, and lockers without a named owner.

Hardening baseline

Rollout order:

1. Export users, roles and lockers; map every unattended Bot Runner to a business owner and a technical owner. See the NHI Ownership Guide.
2. Build custom roles and move people off over-broad assignments in a test Control Room first.
3. Switch people to SAML, keeping the break-glass account, and confirm admins can still sign in before disabling local passwords for them.
4. Restructure lockers, then move one process at a time to external vault credentials; keep the old vault credential for one release so you can roll back by pointing the bot back to it.
5. Set auto-login to a new session with log off, test on a pilot device pool, then apply fleet-wide.
6. Turn on SIEM forwarding and alerts, and run the first quarterly review.

Common misconfigurations

• Developers in production lockers: a Bot Creator who can use a production credential can run it from their own device, outside change control.
• One credential, many systems: reusing a single password across applications defeats the documented one-password-per-credential practice and makes rotation risky, so teams stop rotating.
• Sessions left unlocked: choosing to leave the session unlocked after a run on shared Bot Runner hosts lets anyone with console or RDP access act as the bot account.
• Forgotten migration admins: AAE_Bot Migration Admin left assigned after an upgrade quietly keeps read and edit rights to every credential value.
• API keys on personal accounts: integrations built on an employee's apiKey break or, worse, keep working after that person leaves. See the Employee Offboarding Security Guide.
• No alerting on Syslog changes: an attacker with AAE_Admin can change logging destinations; the change is audited, but only useful if someone watches it.

Practitioner checklist

• List every AAE_Admin, AAE_Locker Admin and AAE_Bot Migration Admin holder and remove any without a current need.
• Enable SAML for people and keep one monitored break-glass database account in your PAM tool.
• Restructure lockers by application and sensitivity, with role-based consumers and named owners.
• Move unattended auto-login and automation credentials to a supported external key vault and rotate them there.
• Give each unattended Bot Runner a dedicated run-as account, new session per run and log off at the end.
• Restrict generateapikey to integration users and set a short API key duration.
• Forward the audit log to your SIEM and alert on Read credential, role changes, API key generation and Syslog changes.
• Scan bot logic for hard-coded secrets before each release to production.

Standards and references

• Automation Anywhere: Credentials and lockers in the Credential Vault
• Automation Anywhere: System roles
• Automation Anywhere: Integrating external key vault with Control Room
• Automation Anywhere: Audit events list
• Automation Anywhere: API permissions
• Automation Anywhere: Auto-login settings
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• MITRE ATT&CK: T1555 Credentials from Password Stores

Related NHI Mgmt Group resources: Service Account Security Guide · Secrets Management Guide · NHI Ownership Guide · Privileged Access Management Guide