Some of the most dangerous technology decisions I have seen start with what looks like a perfectly reasonable shortcut.
I recently needed a way for an application to send an email, update a calendar entry, or file a document. On paper, the official integration route into Microsoft 365 was the right one, but it also came with real effort: identity configuration, delegated permissions, API calls, token handling, and a proper security review. Then the obvious temptation appeared — a desktop AI agent that seemed able to “just use the computer” the way a person would. It could click buttons, type into Apple Mail, and potentially take care of the repetitive weekly tasks nobody really wants to do.
I understand why that is appealing. But I also think it is the wrong architectural instinct for enterprise systems.
My view is simple: AI agents can be useful assistants, but they should not be allowed to bypass the security architecture of Microsoft 365. If a business application needs to send email, manage calendar events, or interact with enterprise data, it should do that through approved, authenticated channels — not by handing an AI agent a virtual mouse and keyboard.
The Appeal of the Desktop Agent
Tools such as OpenAI Codex sit within a broader shift toward agentic software: systems that can take an instruction, reason through a task, and carry out steps on a user’s behalf. OpenAI describes Codex as “a coding agent that helps you build and ship with AI”, aimed at practical engineering work such as features, refactoring, migrations, documentation, and code review.
As a “rookie” developer, I think that is genuinely interesting. A Codex type agent can help me easily explore unfamiliar APIs, generate scaffolding, or speed up routine development work. Might my apLabs toolkit under development be a lot simpler if I coupled it with Codex and let the agents loose on my computer for me?
Could I use it to open Mail? Draft an email? Press send? Could I avoid some of the complexity of Microsoft Graph, Entra ID, OAuth2, and enterprise permissions? I simply don’t have the mental bandwidth for all that right now.
Technically, maybe. Architecturally, I do not think so.
Why “Computer Use” Is a Poor Fit for Enterprise M365 Workflows
A desktop AI agent that operates the user interface behaves more like a person at a keyboard than a properly integrated application. To me, that distinction matters a great deal.
Microsoft 365 environments are usually protected by identity controls, conditional access policies, multi-factor authentication, permission scopes, audit trails, and administrative governance. Those controls exist for a reason. Email, calendars, files, and collaboration tools all carry sensitive business context.
Once an AI agent starts driving the interface directly, the problems show up quickly.
First, the automation becomes harder to govern. A UI-driven action can look like a user action rather than an application action operating within a defined permission boundary.
Second, it is brittle. User interfaces change. Dialogues appear unexpectedly. Focus shifts. Something that worked yesterday can fail quietly today.
Third, the AI layer introduces judgement risk. Large language models, or LLMs, are AI systems that generate text and instructions based on patterns in data. They can be remarkably useful, but they can also misunderstand context, overgeneralise, or respond badly to malicious instructions embedded in content — a risk usually described as prompt injection.
In email workflows, that is not an abstract concern. One wrong recipient, one overbroad distribution list, or one sensitive attachment sent at the wrong time can become a real incident very quickly.
The Better Pattern: Use Approved Integration Paths
I do not think the answer is to reject AI agents outright. I think the balanced approach is to place AI in the right part of the architecture.
An AI assistant can help interpret intent, draft content, summarise context, or suggest the next step. But when it comes to executing enterprise actions, I want that execution to happen through authenticated workflows. I don’t want to risk a rogue e-mail sent to the wrong people.
Two patterns stand out to me.
Option 1: Power Automate as a Controlled Bridge
For many internal tools, I see Power Automate as a practical middle ground. A web application can send a structured JSON payload to an HTTP-triggered flow, and that flow can then use the standard Office 365 Outlook connector to send the email.
That keeps the custom application relatively simple. It also places the Microsoft 365 action inside a platform that many IT departments already know how to govern. Microsoft’s documentation also notes that HTTP request triggers can be restricted so that only authenticated users in the tenant, or even specific users, can trigger a workflow.
That is a far better security posture than saying, in effect, “any process with access to my desktop can click Send”.
Option 2: Microsoft Graph and Entra ID
The more “pro” developer-centric route is to register the application in Microsoft Entra ID and call Microsoft Graph directly. For sending email, Microsoft Graph exposes a sendMail action using permissions such as Mail.Send.
Yes, it is more work. But in my view, it is also the cleanest enterprise architecture. The application has an identity. Permissions are explicit. Tokens are issued through recognised authentication flows. Auditability and governance are much stronger than anything based on UI automation. If you plead hard, you could even get IT to help you implement it.
In a Semantic Kernel Agent application, the AI can still be useful. A C# native plugin can expose a controlled function such as “prepare email” or “send approved email”. The AI can orchestrate intent, but the plugin should enforce the rules.
Keep a Human in the Loop Where Needed
There is also a sensible fallback that I often think is underrated: let the AI draft the email, but let a human send it. There is merit in good old fashioned “copy and paste”. You become the firewall.
A Blazor application can generate the text and open a local email draft using a mailto: link or an Outlook deep link. That preserves the productivity benefit while keeping human review at the most important point.
For many workflows, especially early prototypes, I do not see that as a compromise. I see it as good engineering judgement.
Practical Guidance for Technical Leaders
Before I would allow an AI agent anywhere near Microsoft 365 workflows, I would ask a few practical questions:
- Is this action being performed through an approved identity and permission model?
- Can IT audit what happened, when it happened, and under whose authority?
- What is the worst plausible outcome if the AI misunderstands the instruction?
- Is the AI deciding, drafting, or executing?
- Should a human approve the final action?
My own rule of thumb is straightforward: use desktop agents for local, low-risk assistance; use APIs and governed workflow tools for enterprise communication and data movement.
Conclusion
I have no doubt that AI agents will become part of the developer and knowledge worker toolkit. That seems inevitable. But convenience should not become architecture.
For Microsoft 365 integrations — especially in business or industrial environments — I still believe the right pattern is the disciplined and familiar one: authenticated APIs, approved workflow platforms, explicit permissions, and human review where the risk justifies it.
That may sound less exciting than watching an agent click around a desktop. But it is also how systems survive contact with corporate IT, operational risk, and real business consequences.
Call to Action
If you are exploring AI-assisted workflows in Microsoft 365, I would start by separating assistance from execution. Let AI help with reasoning and drafting, but use approved APIs, Power Automate, or human approval for actions that affect real business systems.
References
- OpenAI. “Codex | AI Coding Partner from OpenAI.” OpenAI, accessed 2026. https://openai.com/codex/
- Microsoft. “user: sendMail – Microsoft Graph v1.0.” Microsoft Learn, accessed 2026. https://learn.microsoft.com/en-us/graph/api/user-sendmail
- Microsoft. “Add OAuth authentication for HTTP request triggers – Power Automate.” Microsoft Learn, last updated 29 April 2026. https://learn.microsoft.com/en-us/power-automate/oauth-authentication
