AI agent delegated access: govern every API hop

An AI agent acting for an employee needs authority tied to both the application's granted permissions and the employee's rights to the requested resource. In Microsoft Entra's On-Behalf-Of flow, each API also needs a token intended for that API. Review all three conditions before describing the workflow as user-delegated.

This guide uses Microsoft's OBO documentation to define governance questions and controlled acceptance tests. It makes no claim that every AI client uses this flow or that a particular tenant has passed these checks.

Identify whose authority the task uses

Microsoft distinguishes delegated access, involving a signed-in user, from application-only access used by services operating under their own permissions. OBO supports user principals and delegated scopes. An application-only token cannot be converted through this flow into the user's delegated authority.

The delegated-access primer explains that a granted scope alone is insufficient: the application needs the right scope and the user needs rights to the requested resource. This gives the policy reviewer two separate questions to answer.

Record which tasks use delegated access and which use application permissions. A background agent's friendly name or reference to an employee in its prompt establishes neither identity model. Read the connector configuration and receiving API's documented permission model.

The general action boundary provides a useful review structure:

Check the audience at each API hop

In Microsoft's example, a client calls a middle-tier API with a token addressed to that API. The middle tier then obtains a token intended for the downstream API. Each receiving service validates the authority presented to it.

The OBO documentation says an incoming assertion must have the middle-tier application's audience. A token intended for Microsoft Graph cannot be redeemed by an unrelated middle tier; that API should reject it. Microsoft also warns against forwarding tokens to destinations outside their intended audience.

For an AI integration, document the client, middle tier and downstream resource explicitly. Confirm how the implementation selects an approved destination. Keep bearer tokens out of prompts, model context, review screenshots and ordinary logs. An agent's proposed URL is untrusted input to this selection process.

Review consent before the chain runs

The middle tier cannot display its own user-consent interaction during OBO. Microsoft describes consent gathered upfront, preauthorised applications and tenant-admin consent as supported arrangements.

That means an employee may see no new permission prompt when a downstream call happens. Review the granted scopes, who approved them, which client can use them and the intended business task. A configuration that receives permission without a fresh prompt still requires an accountable permission owner.

Keep consent and action approval distinct in the record. Consent permits a class of access. A policy may separately require a person to approve a particular consequential action. Our agent security guide covers that action-level review.

Keep the resource's checks in the decision

Microsoft's protected-API guidance states that token validation alone is insufficient. An API also verifies the scopes or application roles required for the operation. Its resource-level rules must still decide whether this identity may read or change the particular object.

Consider a fictional document assistant with permission to read documents through an approved API. The employee can access the Cedar folder but has no access to the Quartz folder. The acceptance test should allow Cedar and reject Quartz while keeping the application scope unchanged. This isolates the user's resource rights from the application's broad operation type.

Use only authorised test identities and fictional documents. Verify the response and any resulting change at the resource. An interface that hides a document can leave the underlying API question unanswered.

Return challenges through the supported client

OBO can encounter a downstream Conditional Access requirement, such as multifactor authentication. Microsoft's documentation directs the middle tier to return the challenge to the client so it can obtain the required user interaction.

Record that behaviour as part of the useful-task test. Preserve the pending work while the employee completes the supported interaction. A background task that cannot satisfy the requirement needs an explicit outcome and owner. Substituting broader application permissions changes the authority model and requires a separate review.

Avoid assuming that a generic token-exchange diagram describes every implementation. Microsoft's documented OBO parameters and its receiving-resource rules are the authority for this specific flow. Check audit attribution per resource as well; carrying a user identity does not establish that every log clearly identifies the agent.

Test the limits as well as successful access

Prepare controlled cases for a permitted user and object, an object outside the user's rights, a missing required scope, an incorrect audience and an application-only assertion presented to a delegated flow. Add a Conditional Access challenge and verify the client can resume the legitimate task.

Retain case identifiers, expected results, versions and bounded resource outcomes without token values or document contents. The AI policy exception guide can help document a separately approved variation. Bring the authority map to a Promptective demo when planning a workflow-specific policy evaluation.