M365Mutator is a small open-source tool I built to keep Microsoft 365 test data fresh. It is a locally hosted web app that connects to a tenant through Microsoft Graph and generates realistic activity across five workloads: it randomizes attributes on Entra ID accounts, and it creates, updates, and deletes mail, calendar, OneDrive, and SharePoint items. It helps when you demo a backup product, test a compliance workflow, or develop against Graph in a tenant whose data never changes. I described it in Make Your Test Data Less Boring with M365Mutator on the Microsoft 365 for IT Pros site, and the code is on GitHub.
Running M365Mutator as an autonomous agent
M365Mutator currently runs when I start it by hand, and it’s implemented as a web app. I want it to run in the background on a schedule, with no user signed in. In the Agent 365 and Entra Agent ID model, that makes it an autonomous agent: it has its own identity, uses application permissions, and has no user in the loop.
In Microsoft-land, that means the agent can be managed through Agent 365, so I installed the Agent 365 command-line interface and ran a365 setup all --authmode s2s. In this context, “S2S” means “service-to-service,” one of the supported Agent 365 identity modes. In this mode the agent gets its own identity and runs only in that identity context. It’s similar in that respect to a service principal used to authenticate a traditional application. Once that setup was done, I gave the agent identity the Graph application permissions it needs for mail, calendars, mailbox settings, and OneDrive and SharePoint access (through Sites.Selected).
…but then it didn’t work
I immediately found a problem: every call the agent made to Exchange Online (mail, mailbox settings, calendar) or SharePoint and OneDrive returned HTTP 401. I double-checked to verify that the token was correct: it was an app-only token, its subject was the agent identity, and its roles claim listed every permission I granted. Using the token for Graph directory operations succeeded.
Usually a missing permission produces a 403; a 401 is the workload saying “NO!” I tested this by narrowing the agent identity write access to a single OneDrive site through Sites.Selected. SharePoint accepted and recorded the grant, and calls to that site still returned 401. It appears that SharePoint rejects the agent identity’s token before it checks site permissions.
This problem wasn’t documented anywhere, so I opened a support case. (Fun challenge: try to figure out where to open an Agent 365 support case in the Microsoft 365 admin center support portal… you can’t.)
Microsoft support’s response
The first reply, which Microsoft noted was AI-generated, seemed helpful but was wrong (I know, right?!) It said the behavior is expected for Agent 365 in S2S mode. According to that reply, Agent 365’s Microsoft 365 data connectivity for mail and calendar uses a delegated model, and that connectivity is skipped when an agent runs in S2S. Instead, it suggested using an AI teammate. It closed by asking whether I call raw Graph endpoints or use the Agent 365 and Work IQ toolchain, and whether my agent is a standard S2S agent or an AI teammate.
I answered that I call raw Graph REST endpoints directly from my own Node.js app, with no Work IQ, MCP servers, or other Agent 365 tooling. That means Work IQ’s delegated-permission requirement doesn’t apply. There’s nothing special about the agent; it’s just making Graph calls. Microsoft’s documentation today doesn’t say these permissions are blocked when used with S2S. I asked Microsoft to confirm whether Exchange Online and SharePoint Online accept app-only tokens whose subject is an Agent ID identity. If they do not, I asked for the documentation that says so. If they should, I asked for an escalation to engineering.
Time passed, then I got a note saying my request had been passed to another team. It was picked up by the Identity and Access group, who escalated it to engineering. The latest update is that engineering is confirming whether the Agent ID ServiceIdentity app-only scenario is supported with Exchange Online and SharePoint Online, and investigating the 401 responses. Support confirmed other people have reported this same issue.
What this all means
I can’t tell if this is supposed to work. That’s a bad sign. Agent 365 is a halo offering from Microsoft, and they’re expecting people to pay big money for it. It doesn’t inspire confidence that neither the support team nor the documentation makes clear whether a basic scenario like this– an autonomous agent modifying SPO/ODB/ExO data– is meant to be supported. I look forward to finding out.
