Workday's Agent System of Record (ASOR) is the control plane inside Workday where security and system administrators register, configure, permission, and audit AI agents through the Agent Management Hub report (secured by the Agent Management Hub domain in the Agent System of Record functional area). Unlike external integrations that share a manually created Integration System User (ISU), every agent in ASOR receives its own automatically managed Agent System User (ASU) and OAuth 2.0 client in the Workday Object Management System (OMS), and Workday enforces permissions differently depending on whether an agent skill runs in delegate mode or ambient mode.

This checklist walks Workday administrators through contractual prerequisites (UMSA vs. MSA), ASU identity mechanics, delegate versus ambient security evaluation, skill activation, Agent Passport inspection, and audit reporting.

1. Check agreement eligibility first: UMSA vs. MSA

Before an agent appears or activates in the Agent Management Hub, check your organization's Subscription Service Agreement on Workday Community (Profile → organization name → Subscription Service Agreement):

  • Universal Main Subscription Agreement (UMSA): Workday-built agents are automatically available for the SKUs your organization licenses, provided Machine Learning data contributions remain enabled.
  • Main Service Agreement (MSA): To use Workday-built agents in either non-production or production tenants, your organization must opt in to UMSA and enable the feature through Innovation Services. (Workday notes that UMSA is not required in non-production tenants for self-built custom agents.)

2. How Agent System Users (ASUs) differ from Integration System Users (ISUs)

Administrators familiar with setting up an Integration System User (ISU) and API client often ask whether AI agents use the same accounts. In ASOR, Workday separates agent identities from integration accounts:

Dimension Agent System User (ASU) Integration System User (ISU)
How it is created Automatically generated and managed by Workday in the Object Management System (OMS) when you configure and activate an agent and its skills in ASOR. Manually created by an administrator via the Create Integration System User task.
Accounts per agent Up to 2 ASUs per agent: one for delegate execution and one for ambient execution, each with its own dedicated OAuth 2.0 client. One ISU per integration (or shared across integrations by admin choice).
Token expiry customization Configurable for Workday-built agents via OAuth Client settings; not yet customizable for external agents (planned for a future release). Access token and refresh token expiry are fully configurable on the API client.
Compromised token response Workday cannot detect compromised credentials on your behalf; the customer administrator must disable the affected OAuth 2.0 client to stop replay attacks within the token's lifetime. Administrator disables the API client or rotates the ISU credentials / refresh tokens.

3. Delegate execution vs. Ambient execution: how Workday evaluates security

The most important security distinction in ASOR is whether an agent skill acts on behalf of a signed-in employee (delegate) or runs autonomously in the background (ambient):

  • Delegate agents: Workday evaluates security at runtime using both the agent's interaction policy (the security groups listed in the skill's Available To prompt) and the invoking user's own domain and business process security permissions for the underlying tools and APIs the skill calls. If you add an employee's security group to Available To on a skill, but that security group lacks View or Modify permission on the underlying domain security policy for the API tool the skill executes, the tool call will fail at runtime.
  • Ambient agents: Because no interactive user is invoking the skill, Workday evaluates security using the agent's own permissions. When you activate an ambient skill in ASOR, Workday automatically generates a unique Ambient Agent Security Group (ASG). You must explicitly add that ASG to the relevant domain or business process security policies (and run Activate Pending Security Policy Changes) before the ambient skill can read or modify secured Workday items.

4. Step-by-step admin setup in the Agent Management Hub

To register, permission, and activate an agent safely:

  1. Register the agent: Open the Agent Management Hub report, select the Unregistered Workday Agent tab, and click Register next to the agent (available for SKUs your organization holds). Workday moves the agent to the Agent Registry tab.
  2. Inspect the Agent Passport: On the Agent Registry tab, click the agent's name and open the Passport tab. The Stamps table lists the compliance and security stamps granted to the agent (Workday-built or third-party), including the stamp description, associated assessors, and grant date.
  3. Enable skills and set the interaction policy: Click Configure Agent. For each skill you want to turn on, toggle the Status slider and populate the Available To prompt with the security groups allowed to invoke that skill.
  4. Align underlying tool permissions (View Security for Agent Skill): Run the View Security for Agent Skill report for each enabled skill. From the related actions menu of each listed Security Policy, select Domain Security Policy → Edit Permissions:
    • For a Delegate Agent, grant View or Modify (and Get or Put if an integration tool requires it) to the security groups of the invoking users.
    • For an Ambient Agent, grant View or Modify (and Get or Put where required) to the generated Ambient Agent Security Group.
  5. Activate security changes and the agent: Run Activate Pending Security Policy Changes, then return to the agent configuration in the Agent Management Hub and click Activate. Activating the agent automatically activates its corresponding ASU.

5. Auditing agent actions and where consultant co-pilots fit

Once agents are active in a tenant, monitor their runtime calls using the View AI Agent Users Audit Trail report and User Activity Logging. Keep in mind that ASOR governs agents running inside Workday's runtime (which draw down Workday Flex Credits in production).

When a Workday administrator or consultant uses kiweely on their desktop to audit security policies, trace why a delegate agent skill lacks domain permissions, or configure a tenant, kiweely does not create a hidden background account: it works through the connections you explicitly sign in to for that conversation, shows its browser work live, and waits for your approval before making any change in the tenant.

Sources checked