Agent Identity Authentication Fails After Creating Agent Instance from Blueprint (AADSTS50034 / invalid_grant)

Question

Agent Identity Authentication Fails After Creating Agent Instance from Blueprint (AADSTS50034 / invalid_grant)

Akshay Babar 65

We are developing an AI teammate agent using the Microsoft Agent 365 SDK.

Our setup process is as follows:

We cloned the code from the Agent 365 samples repository.

We used the Agent 365 CLI commands to configure and set up the agent.

We ran a365 setup all --m365, which successfully created the Azure resources, including the blueprint and Azure App Registration.

We are using Dev Tunnel for local testing.

But, after uploading the agent ZIP and creating an agent instance from the blueprint, we are getting the following authentication error:

Unhandled rejection Error: Token request failed with status 400: {"error":"invalid_grant","error_description":"AADSTS50034: The user account {EUII Hidden} does not exist in the <tenant id> directory. To sign into this application, the account must be added to the directory. Trace ID: 5405ebba-13ff-4740-9919-e39443a56200 Correlation ID: e948f327-da45-45ef-b834-cf653f524923 Timestamp: 2026-06-30 17:17:03Z","error_codes":[50034],"timestamp":"2026-06-30 17:17:03Z","trace_id":"5405ebba-13ff-4740-9919-e39443a56200","correlation_id":"e948f327-da45-45ef-b834-cf653f524923","error_uri":"https://login.microsoftonline.com/error?code=50034"}
    at C:\project\ifs-loops-agent\node_modules\@microsoft\agents-hosting\src\auth\msalTokenProvider.ts:331:23
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async MsalTokenProvider.acquireTokenForAgenticScenarios (C:\project\ifs-loops-agent\node_modules\@microsoft\agents-hosting\src\auth\msalTokenProvider.ts:318:19)
    at async C:\project\ifs-loops-agent\node_modules\@microsoft\agents-hosting\src\auth\msalTokenProvider.ts:359:21
    at async C:\project\ifs-loops-agent\node_modules\@microsoft\agents-hosting\src\cloudAdapter.ts:387:25
    at async C:\project\ifs-loops-agent\node_modules\@microsoft\agents-hosting\src\cloudAdapter.ts:640:33 {
  toJSON: [Function (anonymous)]

User's image

We have already verified the following:

The signed-in user belongs to the same Microsoft Entra tenant.

The user is a Member and has the Global Administrator role.

The Azure App Registration is associated with the same tenant ID.

Despite these checks, the error still occurs.

Could you please help us identify what we might be missing in the Agent identity authentication flow? Are there any additional configurations or prerequisites that we should verify?

Sayali-MSFT 6,476 Reputation points Microsoft External Staff Moderator

2026-07-02T10:17:11.7066667+00:00

Hello Akshay Babar ,
The AADSTS50034 (invalid_grant) error indicates that the Microsoft 365 Agent SDK is attempting to acquire a token for a user account that is not recognized in the configured Microsoft Entra tenant. Although the signed-in user, App Registration, and tenant appear correct, the most likely cause is a tenant/account mismatch between the Agent 365 CLI cached credentials, MSAL authentication context, and the tenant ID configured in the agent blueprint or environment settings.
Verify the CLI login context (a365 auth status), Azure account (az account show), tenant IDs in environment variables and blueprint files, App Registration sign-in audience, Enterprise Application provisioning, user assignment settings, and Dev Tunnel redirect URIs. Enabling verbose MSAL logging can help identify the exact user account and tenant being used during token acquisition and pinpoint the configuration mismatch.
Akshay Babar 65 Reputation points

2026-07-03T13:01:08.1166667+00:00
I tried the same process with an agent that's already available in the Agents Store.

I tested with Sales Development (Frontier). I activated the agent, selected "Available to: Me", and completed the activation successfully. But, when I attempted to create an instance using the blueprint, I encountered the same error, even though I have the Global Administrator role and type as a Member.

Since we are developing our own Team Mate AI agent, could you please guide us on the required roles, permissions, or any other prerequisites needed to add the agent and create an instance using the blueprint? If there are any additional setup steps or tenant configurations required, please let us know.

Also, for your information, below are the policy template settings and licenses we currently have:

1. In the policy template that we select while creating an agent instance, the following settings are configured, and these are the licenses we have:

Microsoft 365 Frontier license for AI Teammates is available, and all 25 of 25 seats are currently available for the above template.

Logged user has Microsoft 365 Copilot licence & Microsoft 365 E5 licence assigned.
Akshay Babar 65 Reputation points

2026-07-04T04:27:08.2633333+00:00
Could you please provide an update as soon as possible? This is very urgent for us.

and also please confirm for below

We would like to confirm which agent type is the correct fit for our scenario. As per the Microsoft Agent 365 documentation, there are two agent types:

Agent (Standard Agent)

AI Teammate Our requirement is to build an agent that:

Can be added to Microsoft Teams and interact in group chats, channels.

Can respond to users' queries in those conversations.

Can also send proactive messages when required.

Uses the Blueprint feature so that users can create an Agent Instance and use the agent. Based on these requirements, should we be implementing an AI Teammate instead of a Standard Agent? Our understanding is that a Standard Agent is primarily intended for 1:1 personal interactions, where each signed-in user creates their own agent instance, and the agent operates on behalf of that individual user (or using its configured permissions) to access that user's data and provide a personalized experience. Could you please confirm whether our understanding is correct and advise which agent type is recommended for our use case?
Akshay Babar 65 Reputation points

2026-07-06T03:40:00.07+00:00

Hi Team, Could you please provide the update ?
Sayali-MSFT 6,476 Reputation points Microsoft External Staff Moderator

2026-07-15T09:37:24.66+00:00

Hello Akshay Babar,
Based on the Agent 365 documentation, your scenario appears to be a better fit for a Standard Agent (Agent) rather than an AI Teammate. Standard Agents can participate in conversational experiences, run tasks, send proactive messages, and operate using delegated or application permissions. They can also be built using an Agent Identity Blueprint, which is the recommended approach for new agents.

AI Teammates are intended for scenarios where the agent requires its own Microsoft 365 identity (mailbox, Teams presence, and directory account). Microsoft also notes that AI Teammates are currently available only to tenants participating in the Frontier preview program.

So, unless your agent specifically needs to exist as an independent Microsoft 365 user with its own identity, mailbox, and Teams presence, a Standard Agent with an Agent Identity Blueprint would typically be the recommended choice for Teams chats, channel interactions, proactive messaging, and agent-instance creation.
Reference Document-
https://learn.microsoft.com/en-us/microsoft-agent-365/developer/get-started

Your answer

Sayali-MSFT 6,476 Reputation points Microsoft External Staff Moderator

2026-07-02T10:17:11.7066667+00:00

Hello Akshay Babar ,
The AADSTS50034 (invalid_grant) error indicates that the Microsoft 365 Agent SDK is attempting to acquire a token for a user account that is not recognized in the configured Microsoft Entra tenant. Although the signed-in user, App Registration, and tenant appear correct, the most likely cause is a tenant/account mismatch between the Agent 365 CLI cached credentials, MSAL authentication context, and the tenant ID configured in the agent blueprint or environment settings.
Verify the CLI login context (a365 auth status), Azure account (az account show), tenant IDs in environment variables and blueprint files, App Registration sign-in audience, Enterprise Application provisioning, user assignment settings, and Dev Tunnel redirect URIs. Enabling verbose MSAL logging can help identify the exact user account and tenant being used during token acquisition and pinpoint the configuration mismatch.
Akshay Babar 65 Reputation points

2026-07-03T13:01:08.1166667+00:00

I tried the same process with an agent that's already available in the Agents Store.

I tested with Sales Development (Frontier). I activated the agent, selected "Available to: Me", and completed the activation successfully. But, when I attempted to create an instance using the blueprint, I encountered the same error, even though I have the Global Administrator role and type as a Member.

Since we are developing our own Team Mate AI agent, could you please guide us on the required roles, permissions, or any other prerequisites needed to add the agent and create an instance using the blueprint? If there are any additional setup steps or tenant configurations required, please let us know.

Also, for your information, below are the policy template settings and licenses we currently have:

1. In the policy template that we select while creating an agent instance, the following settings are configured, and these are the licenses we have:

Microsoft 365 Frontier license for AI Teammates is available, and all 25 of 25 seats are currently available for the above template.

Logged user has Microsoft 365 Copilot licence & Microsoft 365 E5 licence assigned.
Akshay Babar 65 Reputation points

2026-07-04T04:27:08.2633333+00:00

Could you please provide an update as soon as possible? This is very urgent for us.

and also please confirm for below

We would like to confirm which agent type is the correct fit for our scenario. As per the Microsoft Agent 365 documentation, there are two agent types:

Agent (Standard Agent)

AI Teammate Our requirement is to build an agent that:

Can be added to Microsoft Teams and interact in group chats, channels.

Can respond to users' queries in those conversations.

Can also send proactive messages when required.

Uses the Blueprint feature so that users can create an Agent Instance and use the agent. Based on these requirements, should we be implementing an AI Teammate instead of a Standard Agent? Our understanding is that a Standard Agent is primarily intended for 1:1 personal interactions, where each signed-in user creates their own agent instance, and the agent operates on behalf of that individual user (or using its configured permissions) to access that user's data and provide a personalized experience. Could you please confirm whether our understanding is correct and advise which agent type is recommended for our use case?
Akshay Babar 65 Reputation points

2026-07-06T03:40:00.07+00:00

Hi Team, Could you please provide the update ?
Sayali-MSFT 6,476 Reputation points Microsoft External Staff Moderator

2026-07-15T09:37:24.66+00:00

Hello Akshay Babar,
Based on the Agent 365 documentation, your scenario appears to be a better fit for a Standard Agent (Agent) rather than an AI Teammate. Standard Agents can participate in conversational experiences, run tasks, send proactive messages, and operate using delegated or application permissions. They can also be built using an Agent Identity Blueprint, which is the recommended approach for new agents.

AI Teammates are intended for scenarios where the agent requires its own Microsoft 365 identity (mailbox, Teams presence, and directory account). Microsoft also notes that AI Teammates are currently available only to tenants participating in the Frontier preview program.

So, unless your agent specifically needs to exist as an independent Microsoft 365 user with its own identity, mailbox, and Teams presence, a Standard Agent with an Agent Identity Blueprint would typically be the recommended choice for Teams chats, channel interactions, proactive messaging, and agent-instance creation.
Reference Document-
https://learn.microsoft.com/en-us/microsoft-agent-365/developer/get-started