Entra Identity for AI Agents: Who Is Allowed to Do What?

Prerequisites

Before changing identity configuration, map one real agent workflow from the person’s request to the resource that changes or returns data. The goal is to identify which principal each system should see—not to assign every agent the same permissions or to give an agent a person’s credentials.

Have the following available:

• A workflow and resource inventory. Record the user-facing entry point, agent runtime, tools or APIs, data stores, and any system that can cause an external effect. Include read-only and write actions separately.
• An identity inventory. Identify how the human user is authenticated, what identity the agent runtime uses to call downstream services, and what principal each resource recognizes. If these are currently unknown, discovery is the first task; do not infer identity from a successful response.
• A permission owner for each resource. The team responsible for a target API or data system should confirm which actions its boundary authorizes. Authorization decisions belong at the resource boundary, where the requested operation and principal can be evaluated.
• A defined task boundary. Describe what the agent may do, what it must not do, and which actions require a separate human decision. “Help with customer records” is too broad to become a useful permission request.
• A non-production validation path. Plan how to verify both permitted and denied actions without relying on live business changes. A successful sign-in alone does not demonstrate that the right principal or scope was used.

This guide focuses on the distinction between human identity and workload identity, and on limiting permissions to the task. It does not prescribe a particular agent deployment model, network topology, or shared tool layer. For platform selection, first consider the broader enterprise agent platform decision; deployment and connectivity choices have their own design consequences.

Step 1: Write down who is asking and what is acting

Start with two explicit roles. The human identity represents the person who initiated or is participating in a request. The workload identity represents the running software that connects to another system. The agent may reason about the request, but that does not make it the human, and a human’s successful sign-in does not establish that every action taken by the agent is authorized.

Draw the workflow in verbs and principals. For example: “Jordan asks the support assistant to find an order; the assistant retrieves order details; Jordan requests a refund; a service submits the refund request.” At each verb, ask which principal the destination sees. The answer can change between stages: a conversational interface may authenticate a person, while a downstream call may be made by a workload identity.

A useful first-pass record has one row per call, rather than one row per application. Include the caller, destination, operation, identity presented, data or effect involved, and expected authorization decision. Separate a read from a write even if both target the same API. Separate looking up a refund limit from actually submitting a refund; those are different actions with different consequences.

Call in the workflow	Principal to identify	Permission question	Evidence to retain
Person starts a session	Human user	Who may access this entry point?	Authenticated user identifier and session context
Agent runtime calls a resource as software	Workload identity	What narrow set of operations does this runtime need?	Workload principal, target resource, and operation
Agent carries a user’s delegated request	User context plus calling application	Is the resource authorizing the user’s delegated action?	User context, calling application, requested resource and decision
A consequential action is submitted	Principal authorized for that exact action	Is this operation permitted now, with this payload?	Principal, action, payload reference, decision, and outcome

This inventory prevents a common design error: documenting the user who opened the chat while leaving the identity used by the resource call unspecified. It also exposes the opposite mistake—using a broad application identity for actions that should be limited by the individual user’s permissions.

Step 2: Choose whether the resource should act for the user or for the workload

Make this decision per downstream operation. Do not select one identity mode for the entire agent simply because the conversation has a signed-in user. Ask what business authority the operation represents and whose rights should govern it.

Use a user-delegated path when the operation is meant to happen under the requesting person’s authority. For example, a user asks an assistant to retrieve records that the user is allowed to view. The resource should be able to make its authorization decision in the context of that user, rather than treating the agent’s service identity as a substitute for the person.

Use a workload-identity path when the software is performing an operation under the application’s own, deliberately limited authority. A scheduled synchronization or a narrowly scoped service action may have no contemporaneous user whose permissions should be applied. The fact that a workload identity is appropriate does not mean it should have broad standing access; its permission should still match the exact resources and actions needed for that workflow.

The key question is not “Does the user trust the assistant?” It is “Which principal is the destination authorizing for this particular operation?” The OAuth on-behalf-of flow distinguishes user delegation from application identity; authorization remains the responsibility of the resource boundary. See Microsoft’s overview of the OAuth on-behalf-of flow for that distinction.

Decision signal	Prefer user delegation when…	Prefer workload identity when…
Authority	The user’s own access should determine the result.	The operation belongs to a defined service function.
Accountability	The system needs to preserve whose delegated request is being carried.	The system needs to identify the responsible software principal.
Scope	Different users should receive different access outcomes.	The same narrow service permission is appropriate for the workflow.
Failure condition	The user lacks permission or the delegated context is unavailable.	The workload lacks its assigned permission or the target rejects the operation.

These are decision signals, not a shortcut around resource authorization. A delegated token does not mean “allow anything the user asked for,” and an application identity does not mean “allow anything the agent can formulate.” The receiving resource still needs to decide whether the presented principal may perform the specific operation.

Pro tip: Record the identity decision beside each call in the workflow inventory. A single statement such as “the agent uses Entra” is not specific enough to review. State whether a call is delegated or workload-authorized, name the intended principal category, and describe what the destination should allow.

Step 3: Draw the identity boundary before granting permissions

Use a short flow to test the design. The diagram deliberately stops at the resource’s authorization decision; it does not imply that successful authentication grants access.

flowchart TD
  accDescr: Workflow stages and decisions: Human request, Choose authority, Delegated user call, Workload call, Resource checks principal, Allow or deny action. The adjacent text explains the conditions and exceptions.
  accTitle: Entra Identity for AI Agents — Who Is Allowed to Do What? workflow
    A["Human request"] --> B["Choose authority"]
    B --> C["Delegated user call"]
    B --> D["Workload call"]
    C --> E["Resource checks principal"]
    D --> E
    E --> F["Allow or deny action"]

“Choose authority” is a design decision for the operation, not an instruction for the model to improvise. If the same workflow contains both user-directed reads and application-owned processing, represent them as separate calls. “Resource checks principal” means the destination evaluates the identity and requested operation against its authorization rules. An allow on one call does not automatically authorize a different action or resource.

A denial is a valid and important path. It may mean the user lacks access, the workload has not been granted the needed narrow permission, the request is outside the supported task, or the destination cannot establish the intended context. Treat those cases as distinct operational outcomes even if the user-facing message is similar. Avoid resolving a denial by silently retrying with a more privileged identity: that changes who is exercising authority and can turn a correctly blocked request into an unauthorized success.

Keep the agent’s reasoning separate from the authorization decision. The model may identify a proposed record or action, but the system and destination should determine whether the identified principal may perform it. Where the operation can affect business data, capture enough information to connect the original request, chosen identity path, exact action, and resource decision.

Step 4: Reduce each permission to a specific task

Translate the workflow into permission requests that a resource owner can evaluate. A useful request names the target, operation, principal, and reason. “The agent needs access to the CRM” hides whether it must read a customer’s own case, search all accounts, update a status, or submit a financial adjustment. Those should not be treated as equivalent.

Start with the narrowest useful operation. If a task needs to read one class of records, do not begin by requesting broad write access and promise to constrain it in prompts. If the task needs to create a draft but a person submits it, distinguish draft creation from submission. If the task needs a service to perform a batch operation, identify the business boundary of that batch and how the destination will reject requests outside it.

For every proposed permission, complete this sentence: “This principal may perform [operation] on [defined target] for [business purpose], and the resource will reject [out-of-scope action].” If the team cannot fill in the target or rejection condition, the permission is not ready to grant.

Least privilege is not just a small list of permissions. It is a match between identity, operation, target, and time. A narrowly named permission can still be too broad if it covers the wrong records or a high-impact action. Conversely, a valid service workflow may need a workload-level permission, provided the resource constrains what that workload can do and the operational controls make the use reviewable.

Consider where the boundary is enforced. A prompt that says “only show records belonging to the user” is not itself a resource authorization rule. If the destination sees a broadly privileged workload, the prompt alone cannot ensure that a crafted or mistaken request stays within the user’s access. Put the authorization check at the resource boundary and treat agent instructions as behavioral guidance, not as a replacement for permissions.

Warning: Do not grant a workload broad access as a temporary fix for a delegated-flow problem and then leave it in place. A fallback identity can conceal a broken user context and make the effective authority of the agent difficult to understand. Record an explicit failure and fix the intended path instead.

Step 5: Work through a hypothetical support-refund design

The following is a hypothetical example, not a PADISO implementation or a claim about a specific customer system. Assume a support assistant can find an order, summarize its status, and help initiate a refund request. The business has decided that a support representative may view only the cases assigned to them, while a refund submission must be checked against the order’s status and a stated limit.

First, break the request into operations. The representative signs in and asks for an order. The assistant retrieves a relevant order record. It then prepares a refund proposal. A separate action submits that proposal to the business system. The design should not collapse all four operations into “the assistant handles refunds,” because each has a different authority and consequence.

For the order lookup, use a delegated path if the intended rule is that each representative’s own record access controls what the assistant can retrieve. The resource must evaluate the user’s authority for the requested record. If the assistant instead queries using a broad service identity and filters results afterward, the filter is not a substitute for the resource’s user-specific authorization decision.

For a background process that reconciles completed refund requests, a workload identity may be the appropriate principal if the process is acting for a defined service function rather than a currently signed-in representative. Its authority should be limited to the reconciliation task, not expanded to general order administration merely because both operations involve the same system.

For submission, decide who is allowed to exercise the business authority. If the representative must authorize the specific refund, the action needs a human decision associated with the exact proposal before execution. If the business assigns submission to a service, define the workload’s permitted cases and ensure the destination evaluates the submitted action under that service principal. Do not imply that model-generated confidence or a user’s initial request is itself authorization to execute.

An illustrative permission record might read: “The support lookup path may retrieve an order only when the resource authorizes the presented representative for that order. The submission path may submit only the approved refund proposal for the identified order. Any change to amount, order, or recipient requires a new decision.” The precise resource controls depend on the systems involved; the important design feature is that the permission applies to a defined operation and target, rather than to an open-ended agent role.

Now test the counterexample. A representative asks for an order they are not authorized to view, and the agent has a workload identity that can read every order. A prompt instructs the agent to respect representative access. The answer may appear correct in routine conversation, but the resource has not enforced the representative’s boundary if it only sees the broad workload principal. A modified request, retrieval mistake, or future change to the agent’s instructions could expose data the user could not access directly. The remedy is to align the downstream identity path with the business rule and have the resource make the relevant authorization decision.

Test a different failure: the representative is authorized to view the order but asks the agent to submit a refund with a changed amount after an earlier approval. A valid decision for the first proposal should not silently authorize the altered action. The operational design should bind the decision to the precise order and amount, expire it after a defined interval, and require a fresh decision after any material change. The executing component should verify the approved payload before submission. This is a design recommendation, not a claim that a particular platform provides that control automatically.

Step 6: Validate both identity paths and their failure behavior

Validation should demonstrate which identity the resource sees and what it permits. Do not stop at confirming that a sign-in succeeded or that a token was obtained. For each call, test an allowed case and a denied case using a non-production route or a safe test resource where available.

For a delegated operation, verify that the intended user context reaches the resource and that a user who should not access a target is denied. Test more than one user when their permissions differ. If every test uses an administrator, the results do not establish that ordinary user boundaries work. Also test what happens when the user context is absent or cannot be carried: the system should fail closed for an operation that requires user delegation rather than quietly switching to a more privileged workload identity.

For a workload operation, verify that the resource recognizes the intended software principal and that the operation works only within the assigned task. Attempt an adjacent action that the workload should not perform. A denied adjacent action is meaningful evidence that the permission boundary is narrower than the application’s general purpose. If it succeeds, stop and investigate before expanding rollout.

Trace the same request across the agent and resource boundary. A useful record includes a correlation reference, the user context where applicable, workload principal where applicable, target, operation, decision, and final outcome. Avoid recording secrets or unnecessary personal data. The purpose is to reconstruct who or what acted and why, not to collect every conversation detail.

Keep authentication failures distinct from authorization failures. Authentication asks whether the presented principal can be established; authorization asks whether that principal may perform the requested action on the target. A configuration issue that prevents the resource from identifying a principal needs a different response from a valid principal being denied a permission. Blurring the two leads teams to “fix” access by granting more rights when the actual problem is an identity-path defect.

Test	Expected result	If it fails, investigate
Authorized user performs delegated read	Resource permits the specific read	Whether the intended user context reached the destination and whether the resource rule matches the record
Unauthorized user attempts the same read	Resource denies the read	Whether a broad workload path bypassed the user boundary
Workload performs its defined service task	Resource permits only the intended operation	Whether the workload principal and target permission match the recorded design
Workload attempts an adjacent prohibited action	Resource denies it	Whether its access is broader than the task requires
Required user context is unavailable	User-dependent action does not fall back to broader authority	Whether an automatic retry changes the principal or hides the original failure

Step 7: Handle failure without escalating authority

Identity failures often become incidents because an agent appears to be “almost working.” A person can start a session, the agent can produce a plausible answer, and one downstream call can still fail or use the wrong principal. Diagnose the point of failure before changing permissions.

A missing user context should block a user-delegated operation. Return a clear message that the action could not be performed under the requester’s authority, and provide a safe next step such as restarting the authenticated flow or handing the task to an authorized person. Do not retry the same action using a broader service identity unless that alternate path is an explicitly designed and separately authorized operation.

A workload denied by the resource should lead to a review of the intended task, target, and principal. Confirm that the software is calling the expected resource and that the permission request matches the actual operation. If a new permission is genuinely needed, add only the required action and test that nearby prohibited operations remain denied. Avoid changing the workload to a general-purpose administrator as a diagnostic shortcut.

A resource allows an action that should have been denied is more serious than a routine failure. Stop the affected path, preserve relevant diagnostic records, and identify which principal the resource evaluated. Check whether a broad application identity was used where delegated authority was required, or whether the resource’s own rule is too permissive. Restore the intended boundary before resuming the action.

A retry changes the effective principal deserves special attention. Retry logic may be useful for transient technical errors, but it should not quietly transform a user-authorized request into a workload-authorized one. Log the original failure category and the principal on each attempt. If a distinct service action is necessary, make the transition explicit and subject it to its own task and permission definition.

A misleading success message can also obscure a denial. The agent may say that it “submitted” an action after drafting a proposal, or infer success from a tool response that does not establish the business result. Distinguish request accepted, action executed, and business outcome verified. For consequential actions, a system-of-record confirmation—not a model’s description—should determine whether the result occurred.

These failures are operational design cases, not just setup exceptions. Assign an owner to each denial path, specify the user-facing behavior, and decide what evidence operators need to diagnose it. A sensible response can be restrictive without being opaque: explain that the action was not completed, avoid revealing records the user cannot access, and direct the request to the appropriate authorized process.

Step 8: Put the design into operation and review it as tasks change

Treat identity mapping as part of the agent’s maintained interface with the business systems it uses. When a workflow adds a new action, changes from read to write, or begins serving a different user population, revisit the principal and permission decision for that call. A task description that changes from “summarize a record” to “update a record” is an identity-design change even if the agent’s user interface barely changes.

Keep a compact decision record with the workflow name, resource, operation, human or workload principal, reason for that choice, allowed target, denial behavior, owner, and last review date. Make it possible for an engineer who did not implement the original flow to answer: “Who does the resource see, what can that principal do, and what happens if the intended authority is unavailable?” If the answer depends on undocumented assumptions in a prompt or a developer’s memory, the design needs clarification.

Review permissions when a workload is retired, an operation is removed, or the user groups and business rules change. Removing obsolete authority is as important as adding a permission for a new task. Keep the review tied to actual operations rather than relying on a broad label such as “AI assistant,” which says little about the resources and actions that remain necessary.

The identity choice also interacts with the way an agent is deployed, but deployment architecture is not a substitute for this per-operation decision. For a focused discussion of runtime-model tradeoffs, see how prompt agents and hosted agents differ as deployment choices. For tool sharing and its separate ownership and access questions, see the design of a shared MCP tool layer. Network reachability is a different boundary again; the inbound and outbound networking design should not be mistaken for authorization to use a resource.

If the organization needs help turning this map into maintainable platform standards, enterprise platform engineering is the relevant next step. Bring a concrete workflow and its call inventory; the useful discussion is about principals, resource decisions, and failure paths, not a generic declaration that an agent needs access.

Printable identity decision worksheet

Use this worksheet for each distinct downstream operation. Copy it into the team’s design record and complete it before granting access. One row per resource call is more useful than one row per agent.

Field	Decision to record
Workflow and operation	What exact read, write, submission, or service task occurs?
Target	Which resource and defined set of records or objects are involved?
Human role	Who initiated the request, and does that person’s authority govern this action?
Principal presented	Is the call delegated for the user or made under a workload identity? State what the destination should see.
Authorization owner	Which resource owner confirms the rule for this operation?
Allowed action	What may this principal do, on which target, for what business purpose?
Denied action	Name a nearby action or target that must remain blocked.
Missing-context behavior	What happens if required user context or workload authority is unavailable?
Retry behavior	Can a retry change the principal? If not, how is that enforced and observed?
Validation evidence	Which allowed and denied cases demonstrate the boundary?
Operational owner	Who investigates denials, unexpected allows, and changes to the task?
Review trigger	What change requires the identity decision to be revisited?

Printable summary

• Every downstream call has a named principal and destination.
• User-delegated operations preserve the user’s authority at the resource boundary.
• Workload operations are limited to a defined service task and target.
• Prompts are not being used as a substitute for resource authorization.
• A missing or denied identity path does not silently escalate to broader authority.
• Tests cover both an allowed action and a nearby denied action for each path.
• Operators can distinguish authentication failure, authorization denial, and completed business outcome.
• Permission changes and task changes have named owners and review triggers.

Summary: make the principal visible at every resource

The practical rule is simple: decide who should exercise authority for each operation, then make that principal visible to the resource that authorizes it. Use user delegation when the person’s rights should control the action. Use a workload identity when a defined software task should act under the workload’s own limited authority. Neither choice removes the need for the destination to evaluate the requested operation.

A well-designed agent does not recover from a missing identity context by reaching for broader permissions. It fails safely, explains what could not be completed, and leaves operators enough evidence to fix the intended path. Start with one workflow, record each call, test both allow and deny outcomes, and revisit the map when the agent’s responsibilities change.