AI Agent Permissions: Workday's Control Bet

AI agent permissions become a business problem the moment an assistant can change something you cannot quietly undo. Drafting a supplier email is one task. Sending it, changing the supplier's bank details and approving the payment are separate grants of authority. A convincing demonstration can hide that distinction until someone asks who approved the transaction.

On 13 October, Workday announced an agreement to acquire C1.ai, an identity platform for people and agents. Its stated ambition is to govern access across enterprise systems, including email, finance applications and cloud infrastructure.[3] The interesting part is the purchase target: a company that controls access, rather than another model that generates answers.

The deal gives buyers a useful reason to examine their own deployments. Before putting another agent into production, make it prove that it can lose permission as reliably as it gains it.

What Workday is proposing to buy

Workday says its Agent System of Record already gives organisations a place to see and manage agents. C1.ai is intended to extend that into governing what those agents can access across Workday and other enterprise systems. The announcement describes access that an agent receives when needed and loses when its work or role ends.[3]

That is an intended combination, not a completed deployment. Workday expects the transaction to close in its fourth quarter of fiscal 2027, which ends on 31 January 2027, subject to customary closing conditions. The release also warns that unreleased capabilities may change or never arrive.[3] A signed acquisition agreement is evidence of product direction. It does not establish that the combined controls work in your environment.

The distinction matters when procurement teams read an acquisition announcement as a delivery commitment. You can evaluate a proposed architecture now. You should contract against the capabilities available to test, with separate acceptance criteria for anything promised later.

Workday's announcement also draws a useful line between agents acting for an employee and agents operating independently. It says the former should only reach part of what that employee can access, while the latter may need broader access under close oversight.[3] Treat those as different operating arrangements. An employee's account is a poor substitute for an explicit decision about what a particular agent needs to do.

An agent registry cannot enforce authority

Consider a hypothetical accounts-payable agent. Its job is to match invoices against purchase orders, flag discrepancies and prepare a payment batch. That brief does not automatically justify changing supplier records or releasing money. Each action needs its own permission, even if the same application exposes all of them.

A registry can tell you the agent exists and name its owner. Enforcement has to happen where the action reaches the system. If the finance application accepts the request because a connector carries an administrator's credentials, a narrow instruction in the agent's prompt provides little assurance. The application is still accepting administrator authority.

The buyer's job is to trace that authority through the actual route: the agent requests an action, a connector presents an identity, and the receiving system decides whether to allow it. Check each step. A policy document saying the agent cannot release payments is weak evidence if nobody has attempted the prohibited action against the configured integration.

Approval needs the same precision. Approving an invoice match should not silently approve a later change to the payment destination. A useful approval record identifies the action and the data the reviewer saw. If either changes materially before execution, require another decision. Otherwise the human has approved one transaction while the software performs another.

This is where an impressive completion rate can mislead. An agent may execute every requested step successfully while exceeding the authority its owner intended to grant. Testing whether the task finished and testing whether the agent stayed within its permissions are separate jobs.

Revocation is the deployment test

In a procurement demonstration, ask the supplier to remove an agent's permission while a job is running. Then ask the agent to attempt the next restricted action. Inspect the receiving application's response, rather than accepting a dashboard badge marked disabled.

The test should cover the routes the integration actually uses. Depending on the design, that may mean checking an existing session, a queued task or a delegated credential. These are questions for the supplier to answer about its implementation, not claims that every platform has the same weakness. Record which actions stopped, which continued and why.

Before expanding a pilot, run this sequence:

• Give a test agent permission to read selected invoices and prepare a draft batch.
• Attempt a supplier bank-account change and payment release. Both should fail under that brief.
• Withdraw the read permission during a running task, then attempt another read through the same connection.
• Compare the agent's account of events with the receiving system's records, including the denied requests.

Passing that exercise establishes only the behaviour tested. It does not certify the entire platform. Repeat it when the integration gains a new action or changes how it authenticates. A connector update that broadens access deserves more attention than a model update that improves the prose.

There is a related infrastructure problem in dynamic energy control: software that coordinates a physical system needs a defined operating boundary. The same design question applies inside a finance system. Specify what the controller may change before giving it the connection that lets it change things.

Buy measurable control, then expand autonomy

There is a cost to making every action wait for human approval. If someone has to review each routine lookup, the automation has delivered another inbox. Excessive approvals can also make the important decisions harder to notice. Design the boundary around consequences and reversibility, rather than treating every tool call as equally dangerous.

An agent that prepares a draft inside a restricted workspace can have room to retry. An agent that changes production infrastructure or releases a payment needs tighter limits. Decide those limits before measuring productivity. Otherwise the fastest pilot may simply be the one operating with permissions the business would never knowingly approve.

Ask suppliers for evidence at that boundary: the identity the receiving system sees, the actions it permits and the record left when it refuses a request. Assign an accountable owner who can withdraw access without depending on the agent's cooperation. Include that owner in the pilot, rather than discovering after deployment that only the departed project lead knows how the credentials work.

Workday's proposed C1.ai acquisition makes access governance worth watching. It remains a proposal with integration work ahead, not proof that enterprise autonomy is solved.[3] The practical response is to make AI agent permissions part of the acceptance test now. Expand the agent's scope only after you have observed both a useful action succeeding and an unauthorised action failing.