Custom agents in Workday Extend AI are generally available as of Workday Rising, October 13, 2026. Workday's description of their security is short: custom agents inherit user permissions, keep audit trails and pause for human approvals when needed. Workday security permissions apply on every call an Agent-Ready Tool makes, and each action traces back to the person who started it.

That design is reassuring, and it shifts responsibility to the configuration you already have. If a security group is wider than it should be, the agent inherits that too. This guide covers how to check the boundary, where to put approvals and what to audit.

Principle: the agent is never more powerful than the person

Because a custom agent acts with the permissions of the user it serves, two things follow:

  1. The agent cannot escalate. A manager's agent cannot read another team's compensation, because the manager cannot.
  2. Existing over-permissioning becomes visible faster. A person may never have noticed they can see a field they should not. An agent asked a broad question may surface it in seconds.

So securing agents starts with reviewing the human security the agent will inherit, not with new agent-specific controls.

Step 1: Review the security groups behind each persona

For each kind of user who will use the agent, such as employee, manager or HR partner, list the security groups that grant them access to the data and tasks the agent uses. Pay particular attention to:

  • Constrained vs. unconstrained groups. An unconstrained group grants access to every instance in a domain, not just the person's own organisation. See constrained vs. unconstrained security groups.
  • Inherited role assignments. Roles assigned at a high level in the supervisory hierarchy may give access across many organisations.
  • Domains with "Get" and "Put" access. An agent that can read a domain can summarise it. An agent that can modify a domain can act on it.

Fix anything that is wider than the job requires before the agent goes live, not after.

Step 2: Limit the agent's tools to its job

Inherited permissions limit whose data the agent can touch. The tools you give it limit what it can do. Workday's Agent-Ready Tools library has more than 400 tools; a first agent needs a handful.

Keep two lists:

  • Read tools the agent needs to answer questions.
  • Action tools that change data. Each should be justified by the agent's job, and each should be behind an approval in the first release.

An agent built to prepare approvals for review does not need a tool that submits them.

Step 3: Put approvals where they matter

Workday's custom agents can pause for a person's approval. Use that before any action that:

  • changes a worker's record, pay, job or organisation;
  • creates a financial transaction;
  • affects more than one person;
  • cannot be easily reversed.

The approval should show, in plain language, what will happen and to whom. An approval that says "Proceed?" is not a control; one that says "Submit a 3-day time-off request for 4–6 November for Jordan Lee" is.

Remember that the agent's actions still go through your Workday business processes. If a business process requires a manager's approval, the agent's submission waits for it like anyone else's.

Step 4: Test security as different people

Before release, run the same requests as at least three users: the intended user, a user with less access and a user from a different part of the organisation. The agent must give each of them only what they are allowed to see.

Workday's proxy feature in non-production tenants is the standard way to do this. The guide on multi-persona testing in Workday walks through it. Record the results; they are your evidence for the security review.

Step 5: Know where agents are recorded and audited

Custom agents are registered automatically in Workday's Agent System of Record, which is where agents are managed through their lifecycle. Workday says every agent built with Developer Agent has "full auditability from day one," and that agent actions trace back to the person who started them.

Agree before go-live:

  • who owns each agent in the Agent System of Record;
  • who reviews its activity in the first weeks, and how often;
  • what triggers switching it off, such as an unexpected action type or a spike in consumption.

Step 6: Mind the data that leaves Workday

Custom agents can be surfaced outside Workday, for example in Gemini Enterprise or Claude. Before you enable that, confirm with the customer's security team which assistants are approved and what their data handling terms are. Workday states that Developer Agent keeps developer data out of model training and runs inference within the customer's Extend region; confirm the equivalent for any third-party assistant where the agent will appear.

Where kiweely fits

kiweely is a desktop co-pilot that connects to a client's Workday tenants with consent and asks before every change. For agent security work it can read a tenant's security configuration, explain in plain language who can see what, propose narrower security group changes for your approval and test the result in the browser as different users in non-production. Each client's tenants are kept in a separate connection, so one client's security details never inform work for another.

Sources checked