AI agents make delegated authority an access-governance decision

An employee’s access review can be correct while an agent acting on their request can still reach too much. The gap appears when the workflow changes identity: the employee starts a task, but a tool executes it using an application account with broader permissions.

That is not a new category of credential failure. It is an existing delegation problem made more consequential when software can choose and combine actions across systems. For the identity lead, governing who may open the agent is only the first decision. The more important one is which authority each action is allowed to use.

The requester and the executor can have different reach

In a hypothetical sales workflow, a manager asks an assistant for a summary of assigned accounts. The assistant retrieves records under the manager’s access, then calls an export tool using a shared integration identity that can read every customer. Unless the export service enforces the intended account scope, the second step can exceed the boundary of the first.

A quarterly review of the manager’s role would not reveal that path on its own. A review of the integration account might approve its broad access for a legitimate batch process. The problem is the newly available connection between a narrow request and a broadly authorised operation.

Microsoft’s identity-platform documentation distinguishes delegated access, requiring both application and user authorisation, from app-only access without a signed-in user. Those are materially different authority models. Neither, by itself, describes the business purpose of this particular request or the records the task should affect.

The control therefore needs to live where the operation can still be constrained: in the target’s permission model, a narrowly scoped tool, or an execution service that validates the request. A prompt telling the agent to stay within assigned accounts cannot substitute for that boundary.

A stricter identity setting can change the operating model

Copilot Studio provides a concrete example. Microsoft’s maker-credential governance documentation warns that tools using the maker’s credentials can expose actions or data available to that maker rather than the end user. Administrators can restrict the authentication choices at environment or environment-group level.

The same documentation describes a consequence: requiring end-user credentials prevents scheduled or autonomous operation when no live user is available to authenticate. That is a product-specific limitation with a business implication. A policy change intended to improve access control can also stop a background process the organisation relies on.

For interactive work that should inherit the requester’s rights, user-delegated access may be the appropriate model. For approved background work, define a separate application authority with a narrow purpose, an accountable sponsor and limits enforced at the resource. Do not solve the absence of a user by borrowing a developer’s personal account indefinitely.

Assess those paths before changing the policy across an environment. Test representative interactive and scheduled workflows, identify which will fail, and decide whether they should be redesigned or discontinued. The identity team is making an operating decision as well as a configuration change.

Keep evidence of the task across the boundary

Even an appropriately authorised shared account can leave an investigation incomplete. The destination may record which technical principal changed a customer record without showing which user request or background task caused it. That absence is an attribution gap, not proof that the action was unauthorised.

Require a reliable connection between the initiating task, the tool request, the authority used and the target result. Limit access to these records and retain the evidence needed for investigation without indiscriminately logging sensitive prompts or tokens. Check correlation across retries and asynchronous work; a successful first demonstration does not establish that every execution path is covered.

The Model Context Protocol security guidance illustrates why simply forwarding credentials is not a satisfactory shortcut. It prohibits token passthrough and acceptance of tokens not issued for the MCP server, and identifies accountability and audit problems when identities are blurred across services. Protocol compliance is one part of the implementation; it does not settle the organisation’s business delegation policy.

The governance test is consequently broader than “does the agent have an identity?” Ask whether the business purpose remains bounded when the workflow changes principal, whether the target enforces that boundary, and whether investigators can reconstruct the result. When one of those conditions is missing, constrain the affected action path rather than making a sweeping claim that every agent is either safe or unsafe.

Use an agent identity inventory organised by action path to make those decisions visible. Access reviews can then examine the authority the agent actually exercises, including the point where a user’s request becomes an application’s power.