Agent Security
The agent security framework governs the identity, authentication, and authorization of AI agents within your tenant. Agent security controls how agents interact with data and perform tasks. Workday recommends abiding by the principle of least privilege for all interactions, granting agents the minimum necessary access to domains and business processes required for their specific skills.
While you manage the lifecycle and definition of your agents in the Agent System of Record (ASOR), agent security dictates their runtime behavior.
The agent security framework supports these agent execution modes:
- Delegate mode: The agent acts on behalf of a user. Example: A user asks an agent to request the day off for a specific date. The agent executes the request on behalf of the user. Workday evaluates security based on the intersection of the user's permissions and the agent's enabled skills, as the user making the requests must have security access to the underlying agent tools and tasks.
- Ambient mode: The agent acts based on an event trigger or schedule to perform background tasks. Example: An agent automatically aggregates data pools or evaluates datasets based on a schedule. The agent acts as itself, using its own security permissions without user intervention.
You can’t delegate Workday agent interactions or use a proxy.
The agent security framework also provides clear audit trails that distinguish when an agent acts autonomously and when it acts on behalf of a user.
While you manage the lifecycle and definition of your agents in the Agent System of Record (ASOR), Agent Security dictates their runtime behavior.
Agent Identity: Agent System User (ASU)
Each agent has a unique identity, or Agent System User account (ASU). ASUs provide:
- Control over what the agent can access.
- Transparency for auditing.
An agent can have up to 2 ASUs, 1 each for delegate execution and ambient execution. When an agent needs to operate in both delegate and ambient modes, you must configure credentials for each. Each ASU has a specific OAuth 2.0 client.
ASUs don't support proxy accounts.
ASU Creation and Registration
The ASU creation process occurs in tandem with the agent's configuration and skill enablement in ASOR. When an administrator enables skills for an agent, ASOR automatically creates a dedicated delegated ASU or ambient ASU for that agent in a disabled state. When you activate the agent, Workday automatically enables the associated ASUs.
An OAuth client is generated and attached to an ASU. A private key pair is created, and the public key is registered with the Workday authorization server. The ASU is then granted the ability to authenticate and perform tasks defined in its skills.
ASOR securely stores the client credentials, including the private key, in the credential store. A unique reference ID is then stored in ASOR as a pointer to these key-pair credentials, which are used to generate ASU tokens that are exchanged along with the user token for a delegated ASU, rather than for OAuth 2.0 client credentials.
Agent Interaction Policy
The agent interaction policy is a security configuration within ASOR that defines which users are authorized to converse with or invoke specific delegate agent skills. You must opt-in security groups to allow them to use these skills.
When a user attempts to interact with an agent, the Workday agent security framework performs this security evaluation:
- First, Workday checks whether the user belongs to a security group included in the agent’s interaction policy. You select these security groups on theAvailable Toprompt. If the user isn’t a member of any of these groups, Workday denies the agent interaction, even if the user has access to the necessary domain or business process security policies to perform the tasks defined in the skill’sToolssection.
- If the user passes the interaction check, Workday then verifies their standard permissions, including domain access and business process security policies, to ensure they're authorized to see the data or perform the action requested. Workday checks the domains for the tools and at the field level when using the agent’s skill.
The agent interaction policy applies only for agents and skills that operate in the delegate mode. Because ambient agents act as themselves in the background based on triggers or schedules, they don’t interact directly with a user and therefore don’t require a policy defining which user can interact with them.
You can define the agent interaction policy in the
Agent Management Hub
or during agent registration by selecting security groups on the Available To
prompt for a specific skill. Example: For a Recruiting agent with a Job Requisition Creation skill, you can select the Recruiters security group on the
Available To
prompt. Only users in the Recruiters security group can request the agent to create a requisition. A user in the Employee As Self security group can’t use this skill, even if they have domain access to create requisitions.Comparison of Security Modes
Consideration | Delegate Mode | Ambient Mode |
|---|---|---|
Primary Use Case | Interactive tasks. Example: Request time off for yourself. | Background tasks. Example: Data aggregation. |
Identity Used | Combination of user and agent ASU. | Agent ASU only. |
Authentication | The agent uses the OAuth 2.0 in the On-Behalf-Of flow. Workday-built agents: The access token is valid for up to 60 minutes when you use the Authorization Code grant. External agents: The access token is valid for 4 hours. You can’t customize access token expiry for third-party agents currently. | The agent authenticates as an ambient ASU, with no user involvement. |
Authorization Logic | Workday evaluates security based on the intersection of the user's permissions and the agent's allowed skills. | Workday evaluates security solely against the agent's permissions. |
Configuration | Agent Interaction Policy: Defines who can interact with the specific agent skills. | Domain Security Policy: Defines what the agent can access. |
Security Groups | The user must be in the allowed security groups for the skill to invoke it. | When you activate an ambient skill, a unique Ambient Agent Security Group is generated and must be assigned to the relevant domain or business process security policies. |
Audit Log | Records the transaction as performed by the agent as By User and the user as On Behalf Of User . | The audit log shows the agent ASU as the By User . |
Security
Security groups managing agents require View and Modify access to Report/Task permissions to view and execute agent tasks, and Put access to Integration permissions to transfer agent configuration data.
Domain | Considerations |
|---|---|
Agent Management Hub | Provides access to the centralized hub for viewing and managing all agents. |
Manage: Agents | Provides access to setup tasks and activities for ASOR. |
Reports: AI Agent Security | Provides access to the View AI Agent User Audit Trail report. |
Setup: Agents | Provides access to tasks for configuration, activation, and deactivation of agents. |
Reporting
We provide these reports for agent security:
Report | Description |
|---|---|
View Security for Agent Skill
| Displays the domain and business process security policy configuration for agent skills. You can access this report from the related actions menu of an agent skill. |
View AI Agent User Audit Trail
| Displays user activity, distinguishing between By User and On Behalf Of User. |