Reviewing Workday Illuminate agents — what the Agent System of Record actually governs

The Agent System of Record is Workday's registry and governance layer for every agent operating in its ecosystem, first-party or third-party. It tracks what an agent is, what data it can reach, what privileges it holds, and — the part worth taking seriously — it applies that governance uniformly, so a third-party agent from the Agent Partner ecosystem is subject to the same registration and privilege model as a Workday-built one rather than getting a side door.

That is a genuinely stronger starting position than most enterprise platforms bolting agents onto an existing permission model after the fact. It doesn't make the governance question closed — it makes it answerable, which is different.

HR and Finance agents doing real work — approving expense reports, drafting compensation changes, initiating a termination workflow, running payroll adjustments — are exactly the class of action where the consequence of a mistake isn't a bad answer, it's a wrong paycheck or an unauthorized record change with legal weight (SOX controls on financial processes, employment-law exposure on HR actions). Central registration answers who the agent is and what it's scoped to; it doesn't by itself answer whether a specific action should require a human sign-off before it executes.

Workday's own admin documentation names the specific mechanism behind “registered agents”: every agent gets an Agent System User (ASU) — a first-class identity equivalent to a human worker account, authenticated via OAuth 2.0, scoped to specific tools and domains, with every action logged to an audit trail. Two distinct execution modes sit on top of that identity: Delegate mode, where an agent acts on behalf of a specific user and is evaluated against that user's own security profile, and Ambient mode, where an agent acts as itself and is evaluated against its own security group. Workday's own guidance recommends separate ASUs per mode specifically to avoid authorization and audit confusion — a real, checkable configuration detail, not an abstract governance principle.

A platform-level registry is necessary and not sufficient. Three questions sit outside what the System of Record certifies by design, and a review has to answer them per-deployment:

A registry that knows what an agent is and what it's scoped to doesn't automatically know whether a given customer configured that scope too broadly, or whether a specific high-consequence action — initiating a termination, adjusting a pay run — has a mandatory approval gate in front of it.

First, per-tenant scoping: a governance system that supports fine-grained privilege assignment doesn't guarantee any given customer configured it tightly — an agent granted broader read access than its actual task needs is a configuration failure the platform can't catch for you. Second, action-level approval: which specific agent actions (payroll changes, termination initiation, comp adjustments) require human sign-off before executing, versus which are allowed to complete autonomously, is a policy decision each deployment makes — verify it was made deliberately, not left at a permissive default. Third, third-party agent provenance: an Agent Partner-ecosystem agent is registered the same way a first-party one is, but registration isn't the same as vetting — confirm what security review a specific third-party agent underwent before it touches HR or Finance data.

Workday's answer to “what security review did a third-party agent undergo” launched June 2, 2026 as Agent Passport: independent testing and continuous monitoring of every agent — Workday- built or third-party — before and after it reaches production. The testing itself is performed by named external security partners, not Workday's own team (Cisco, using Cisco AI Defense, is the first attestation partner), and attestations are tied to public standards — OWASP LLM Top 10, NIST AI RMF, MITRE ATLAS — producing a signed, auditable record of what was tested and by whom. The disclosed test scope explicitly covers prompt injection, jailbreak and goal-hijacking attempts, system-prompt extraction, employee-data leaks, and unsafe outputs.

For any team enabling Workday Illuminate agents, a design-time review should be able to answer:

• Is each deployed agent's data scope reviewed against its actual task, or left at the platform's default privilege grant?
• Which specific agent actions (payroll, termination, compensation, benefits changes) require mandatory human approval before executing, documented explicitly?
• For third-party Agent Partner-ecosystem agents, what security review did the specific agent undergo before being granted access to HR or Finance data — is there a current Agent Passport attestation on file?
• Is there an audit trail that ties every agent-initiated change back to the specific agent, its privilege grant, and — where applicable — the human who approved it?
• Does each agent use a separate Agent System User for Delegate mode versus Ambient mode, per Workday's own guidance, or is one ASU shared across both?

See agentic AI audit trail for the general pattern this checklist item depends on.