Do Entra Agent ID agent identities support Exchange Online mailbox access via Graph? Empty-body 401 despite valid app-only token and InScope Exchange RBAC

Is Exchange Online mailbox data-plane access via Microsoft Graph actually supported today for Microsoft Entra Agent ID agent identities (servicePrincipalType: ServiceIdentity)? Microsoft's documentation says yes; after a 35-day support case, Microsoft Support says it appears not to be. I would like a definitive answer, and ideally a known-issue reference, because the documentation and the support conclusion cannot both be right.

Scenario

We operate a multi-tenant SaaS platform that provisions Entra Agent ID agent identities from a central agent identity blueprint. After admin consent in the customer tenant, each agent identity acquires an app-only Microsoft Graph token via the supported two-leg federated identity credential client-credentials flow (no client secret), and is authorized to specific mailboxes via Exchange RBAC for Applications.

What fails

Every mailbox data-plane call, for example:

GET https://graph.microsoft.com/v1.0/users/{mailbox}/messages?$top=1

returns:

• HTTP 401 Unauthorized
• Response body: empty (Content-Length 0)
• WWW-Authenticate header: absent entirely, no claims challenge
• Only an x-ms-ags-diagnostic ServerInfo header present

Identical results on /messages, /calendar/events, and /contacts, for every mailbox in the tenant, on every attempt over five-plus weeks. It has never succeeded once.

What is verified (this has been triple verified at this time)

• Token is correct: aud = https://graph.microsoft.com, idtyp = app, roles = Mail.ReadWrite, Mail.Send, Calendars.ReadWrite, Contacts.ReadWrite; appid = oid (agent identity service principal, servicePrincipalType: ServiceIdentity, enabled).
• Exchange RBAC for Applications is configured and effective: Test-ServicePrincipalAuthorization -Identity <agent-oid> -Resource <mailbox> returns InScope = True for the target mailboxes, showing Application Mail Full Access plus Calendars and Contacts roles scoped to those mailboxes.
• The ServiceId/AppId registration trap is ruled out: the agent's objectId equals its appId, and New-ServicePrincipal was registered with AppId = ObjectId, so the Exchange-registered ServiceId matches the token's oid exactly.
• Not cache propagation: the 401 has persisted for five weeks against a documented 30-minute-to-2-hour app permission cache window.
• Control variable: the same Exchange RBAC configuration works with a conventional app registration's service principal. The only variable is the agent identity as token subject.

The documentation says this is supported

1. Grant agents access to Microsoft 365 resources (updated June 15, 2026): prerequisites are an agent identity blueprint and an agent identity, and the Exchange RBAC section states agents "can get granular authorization, such as autonomous access to one mailbox or a few mailboxes."
2. Agent 365 Identity (updated July 8, 2026) lists, as a use case of the agent identity authentication flow: "Sending emails or creating meetings from the agent's mailbox." That is exactly the call that fails.
3. Role Based Access Control for Applications in Exchange Online: the Limitations section contains no exclusion of any service principal type.
4. The Entra Agent ID FAQ / known issues (updated June 26, 2026) documents many preview gaps; an inability of agent identities to reach the Exchange mailbox data plane is not among them.

The support case history (SR 2606150010000578)

I want to document this factually because it is part of why I am asking here:

• June 15: Case filed with full diagnostics: decoded token claims, Test-ServicePrincipalAuthorization output, request-ids (e.g. 4a7743e9-1970-4ec6-be26-bb4f1c655332, 2026-06-15 16:43:04 UTC).
• June 16: The support engineer issued a root-cause finding: "The Agent Identity (ServiceIdentity) being used is not a supported application identity type for Exchange Online mailbox data-plane access via Microsoft Graph... the Exchange data plane does not accept this identity type, and rejects the request before RBAC evaluation."
• June 17: I asked three follow-up questions: reconcile that finding with the documentation above; if it is a real limitation, provide a known-issue tracking ID and ETA; if there is an undocumented enablement step, identify it.
• June 18: Case transferred to the "Entra ID App Integration team." Then 26 days of silence.
• July 14: I escalated in writing.
• July 15: I was told the case was being transferred to the "Microsoft Entra Agent ID team."
• July 17: Instead, the case cycled back to the original break-fix engineer, who restarted triage from zero, asking for a screen recording and screenshots of a scenario that has no portal UI, and whose own intake email states the break-fix team does not perform root cause analysis.
• July 20: Support concluded the configuration is fully validated, no customer-side steps remain, and the behavior "appears to be a product limitation or service gap related to the interaction between Microsoft Entra Agent ID identities and Exchange Online mailbox data-plane access." Still no tracking ID, no ETA, no product-group contact, and none of my three June 17 questions answered.

So after 35 days on a paid support plan I have a written concession that this looks like a product gap, and no path forward.

This may not be Exchange-specific

This Q&A thread reports the same pattern on the SharePoint data plane: an agent identity with Sites.Selected per-site grants gets 401 "Request is not allowed in this context" while a normal service principal succeeds on the identical code path. That suggests Microsoft 365 workload data planes are rejecting ServiceIdentity principals before authorization evaluation.

My questions

1. Is Exchange Online mailbox data-plane access via Microsoft Graph app-only tokens supported today for Entra Agent ID agent identities authorized through Exchange RBAC for Applications, as the documentation states? If not, is there a known-issue or roadmap reference I can track?
2. Is the intended supported path for autonomous agent mailbox access actually the agent user identity (idtyp = user, licensed mailbox) rather than the agent identity service principal? If so, is that stated anywhere, and will Exchange RBAC for Applications ever apply to agent identities as documented?
3. Is there any tenant-side enablement step for ServiceIdentity principals on the Exchange data plane that is not in the RBAC for Applications documentation?

Environment details, request-ids, and full timeline are in SR 2606150010000578 if anyone from the product group can look. I can reproduce this on demand.Is Exchange Online mailbox data-plane access via Microsoft Graph actually supported today for Microsoft Entra Agent ID agent identities (servicePrincipalType: ServiceIdentity)? Microsoft's documentation says yes; after a 35-day support case, Microsoft Support says it appears not to be. I would like a definitive answer, and ideally a known-issue reference, because the documentation and the support conclusion cannot both be right.

Scenario

We operate a multi-tenant SaaS platform that provisions Entra Agent ID agent identities from a central agent identity blueprint. After admin consent in the customer tenant, each agent identity acquires an app-only Microsoft Graph token via the supported two-leg federated identity credential client-credentials flow (no client secret), and is authorized to specific mailboxes via Exchange RBAC for Applications.

What fails

Every mailbox data-plane call, for example:

GET https://graph.microsoft.com/v1.0/users/{mailbox}/messages?$top=1

returns:

• HTTP 401 Unauthorized
• Response body: empty (Content-Length 0)
• WWW-Authenticate header: absent entirely, no claims challenge
• Only an x-ms-ags-diagnostic ServerInfo header present

Identical results on /messages, /calendar/events, and /contacts, for every mailbox in the tenant, on every attempt over five-plus weeks. It has never succeeded once.

What is verified (please don't suggest re-checking these)

• Token is correct: aud = https://graph.microsoft.com, idtyp = app, roles = Mail.ReadWrite, Mail.Send, Calendars.ReadWrite, Contacts.ReadWrite; appid = oid (agent identity service principal, servicePrincipalType: ServiceIdentity, enabled).
• Exchange RBAC for Applications is configured and effective: Test-ServicePrincipalAuthorization -Identity <agent-oid> -Resource <mailbox> returns InScope = True for the target mailboxes, showing Application Mail Full Access plus Calendars and Contacts roles scoped to those mailboxes.
• The ServiceId/AppId registration trap is ruled out: the agent's objectId equals its appId, and New-ServicePrincipal was registered with AppId = ObjectId, so the Exchange-registered ServiceId matches the token's oid exactly.
• Not cache propagation: the 401 has persisted for five weeks against a documented 30-minute-to-2-hour app permission cache window.
• Control variable: the same Exchange RBAC configuration works with a conventional app registration's service principal. The only variable is the agent identity as token subject.

The documentation says this is supported

1. Grant agents access to Microsoft 365 resources (updated June 15, 2026): prerequisites are an agent identity blueprint and an agent identity, and the Exchange RBAC section states agents "can get granular authorization, such as autonomous access to one mailbox or a few mailboxes."
2. Agent 365 Identity (updated July 8, 2026) lists, as a use case of the agent identity authentication flow: "Sending emails or creating meetings from the agent's mailbox." That is exactly the call that fails.
3. Role Based Access Control for Applications in Exchange Online: the Limitations section contains no exclusion of any service principal type.
4. The Entra Agent ID FAQ / known issues (updated June 26, 2026) documents many preview gaps; an inability of agent identities to reach the Exchange mailbox data plane is not among them.

The support case history (SR 2606150010000578)

I want to document this factually because it is part of why I am asking here:

• June 15: Case filed with full diagnostics: decoded token claims, Test-ServicePrincipalAuthorization output, request-ids (e.g. 4a7743e9-1970-4ec6-be26-bb4f1c655332, 2026-06-15 16:43:04 UTC).
• June 16: The support engineer issued a root-cause finding: "The Agent Identity (ServiceIdentity) being used is not a supported application identity type for Exchange Online mailbox data-plane access via Microsoft Graph... the Exchange data plane does not accept this identity type, and rejects the request before RBAC evaluation."
• June 17: I asked three follow-up questions: reconcile that finding with the documentation above; if it is a real limitation, provide a known-issue tracking ID and ETA; if there is an undocumented enablement step, identify it.
• June 18: Case transferred to the "Entra ID App Integration team." Then 26 days of silence.
• July 14: I escalated in writing.
• July 15: I was told the case was being transferred to the "Microsoft Entra Agent ID team."
• July 17: Instead, the case cycled back to the original break-fix engineer, who restarted triage from zero, asking for a screen recording and screenshots of a scenario that has no portal UI, and whose own intake email states the break-fix team does not perform root cause analysis.
• July 20: Support concluded the configuration is fully validated, no customer-side steps remain, and the behavior "appears to be a product limitation or service gap related to the interaction between Microsoft Entra Agent ID identities and Exchange Online mailbox data-plane access." Still no tracking ID, no ETA, no product-group contact, and none of my three June 17 questions answered.

So after 35 days on a paid support plan I have a written concession that this looks like a product gap, and no path forward.

This may not be Exchange-specific

This Q&A thread reports the same pattern on the SharePoint data plane: an agent identity with Sites.Selected per-site grants gets 401 "Request is not allowed in this context" while a normal service principal succeeds on the identical code path. That suggests Microsoft 365 workload data planes are rejecting ServiceIdentity principals before authorization evaluation.

My questions

1. Is Exchange Online mailbox data-plane access via Microsoft Graph app-only tokens supported today for Entra Agent ID agent identities authorized through Exchange RBAC for Applications, as the documentation states? If not, is there a known-issue or roadmap reference I can track?
2. Is the intended supported path for autonomous agent mailbox access actually the agent user identity (idtyp = user, licensed mailbox) rather than the agent identity service principal? If so, is that stated anywhere, and will Exchange RBAC for Applications ever apply to agent identities as documented?
3. Is there any tenant-side enablement step for ServiceIdentity principals on the Exchange data plane that is not in the RBAC for Applications documentation?

Environment details, request-ids, and full timeline are in SR 2606150010000578 if anyone from the product group can look. I can reproduce this on demand.

UPDATE 2 August 2026 - Microsoft has now assigned an incident, and the failure still reproduces

Day 48. Still failing, every call, every time. Posting the current state because the technical picture has sharpened considerably and I still do not have an answer to the original question.

Microsoft has assigned an incident

On 28 July, support assigned IcM 838451087, owned by the Substrate Authorization RBAC team, described to me as tracking elevated HTTP 401 responses between Microsoft Graph and the Microsoft.Exchange.Rbac workload. Support agreed in writing that the failure "occurs after successful token issuance" and that the problem lies in the Exchange authorization path rather than in authentication. No ETA was given.

I am not yet convinced that incident is my bug, for two reasons. First, timeline: I was told the 401 increase was detected around 22 July, but my failures began 15 June, more than five weeks earlier. Second, scope: the incident is described in terms of the generic AAD AccountType, and nothing in the description mentions Agent ID or ServiceIdentity at all. If it turns out to be a separate general regression, resolving it will not fix this, and I will be told my case is closed while the reproduction below still fails. I have asked Microsoft to confirm one way or the other.

New evidence: a control call that isolates the failure to the mailbox data plane

This is the most useful thing I have found, and it argues the rejection happens before authorization is ever evaluated.

Using the same token, in the same second, I called a non-mailbox Graph endpoint:

GET https://graph.microsoft.com/v1.0/users/{upn}?$select=id,displayName
-> HTTP 403, well-formed JSON body, code Authorization_RequestDenied

That 403 is correct and expected, because this agent identity holds no Directory.Read permission. The point is not the 403, it is the shape of it. One token, one second, two Graph endpoints:

• Directory endpoint: processes the principal normally, evaluates authorization, and returns a structured, spec-compliant error with an error code and a correlation id in the body.
• Mailbox endpoints: return a bare 401 with a zero-length body and no WWW-Authenticate header, which is not a well-formed authorization failure at all.

If this were a token problem, both would fail identically. They do not. A properly evaluated authorization denial produces a body and an error code. The mailbox path produces neither, which means the request is being rejected before it reaches the code that formats authorization errors. That is consistent with the Exchange data plane refusing this principal type ahead of RBAC for Applications evaluation.

Credential form is ruled out, so please do not suggest certificates

SharePoint Online refuses app-only tokens minted with a client secret and requires certificate credentials, returning "Unsupported app only token". That is not what is happening here, on two independent grounds.

1. The rejected token already presents as certificate class. It carries appidacr = 2. The client secret only authenticates the blueprint on leg 1; leg 2 exchanges that for the agent token via a jwt-bearer client assertion, so no secret is present in the credential chain by the time Exchange sees the token.
2. I re-ran the whole flow with a real X.509 certificate anyway, moving leg 1 from azpacr = 1 to azpacr = 2. The result was identical: same empty-body 401, same absent WWW-Authenticate header, on all three endpoints.

Also still true

Test-ServicePrincipalAuthorization continues to return InScope = True for all three roles against the target mailbox, re-verified today, and the Exchange ServicePrincipal pointer still exists. The control-plane configuration is intact and Microsoft support validated it in writing on 20 July.

This is not Exchange-specific

@Derek Morgan II reports the same failure class on the SharePoint data plane in Q&A 5919010: an Entra Agent ID identity with Sites.Selected per-site grants receives a 401 while an identical code path using a normal service principal succeeds. Two different Microsoft 365 workloads, two customers, the same symptom, both open. That pattern points at a shared resource-side admissibility check that rejects ServiceIdentity principals before authorization is evaluated, rather than anything specific to Exchange, to SharePoint, or to either of our tenants.

The question is still open

Does the Exchange Online mailbox data plane currently admit Entra Agent ID (ServiceIdentity) principals presented with a valid app-only Graph token carrying Mail.ReadWrite and an effective Exchange RBAC for Applications assignment scoped to the target mailbox?

A plain yes or no would unblock me either way. If the answer is no, I will re-architect around it, but the three documentation pages that currently describe this scenario as supported need correcting, because I should not be finding this out through a seven-week support case.

Reference: SR 2606150010000578, IcM 838451087.