OPINION
A security analyst at a large enterprise recently found sensitive HR documents being copied into a Microsoft Teams channel that hundreds of employees could access. It was not caused by a malicious insider, a compromised admin account, or a sophisticated attacker. It was caused by a Power Automate workflow.
The workflow had been created by a developer who wanted to automate document approvals between SharePoint and Teams. To move faster, the developer used an AI assistant to generate the automation logic. Functionally, the workflow worked. Documents moved from one location to another. Notifications were sent. The approval process became faster.
The problem was that nobody had reviewed the permissions, data flow, or security impact behind the automation. This is the risk many enterprises are walking into.
AI coding assistants are now being used to generate scripts, workflows, queries, and integrations at speed. At the same time, Microsoft 365 sits at the center of most enterprise environments. It holds emails, documents, Teams conversations, SharePoint sites, OneDrive files, identity data, compliance records, and business processes.
On their own, AI coding tools and Microsoft 365 automation platforms offer real productivity value. Together, they create a quiet but serious security problem: automation that works, but nobody fully understands.
Why AI-Generated Workflows Are a Different Risk
Most organizations already have some level of control around traditional software development. Code usually goes through peer review, testing, deployment pipelines, and security checks. Microsoft 365 automation often does not.
Power Automate flows, Graph API scripts, SharePoint automations, eDiscovery queries, Teams integrations, and PowerShell scripts are frequently built by admins, business analysts, developers, and power users. Their main goal is usually simple: make a process faster.
When AI is added, the barrier to creating automation drops even further. A user no longer needs deep knowledge of Microsoft Graph permissions, connector behavior, SharePoint inheritance, DLP policies, or audit logging. They can describe what they want in plain English and receive a working script or workflow within minutes. That sounds efficient. It is also dangerous.
The issue is not that AI intentionally creates malicious automation. The issue is that AI often produces code that appears correct because it works. But working is not the same as secure. Many users test whether the automation completes the task. Far fewer test whether it respects least privilege, data classification, access boundaries, retention rules, or audit requirements.
That creates shadow automation inside Microsoft 365: workflows and scripts running quietly with access to sensitive enterprise data.
Where Things Go Wrong
1. Excessive permissions become normal
AI-generated Microsoft Graph scripts often lean toward broad permissions because broad access makes the code more likely to work.
A developer may ask for a script that reads files from SharePoint and posts updates to Teams. The generated code may request wide tenant-level permissions instead of narrow access to a specific site, library, or channel.
The business sees a successful automation. Security inherits a new privileged pathway.
If the service account, app registration, or automation identity is later compromised, attackers may gain far more access than the original use case required.
2. Workflows become silent data leakage channels
Power Automate makes it easy to move information between SharePoint, Teams, Outlook, OneDrive, Excel, third-party software-as-a-service (SaaS) tools, and external recipients.
That convenience is exactly what makes it risky.
A flow designed to distribute monthly reports could accidentally send payroll data, customer records, legal documents, or confidential business files to the wrong Teams channel or external mailbox. Because these workflows run automatically, the exposure may continue for weeks or months before anyone notices.
This is not a dramatic breach scenario. It is worse in some ways, because it looks like normal business activity.
3. Compliance automation can create legal exposure
Security and compliance teams are also using AI to generate eDiscovery searches, audit queries, insider risk scripts, and retention-related workflows.
A poorly written eDiscovery query can collect too much data, miss critical evidence, expose privileged communications, or mishandle preservation requirements.
In regulated industries, this can become more than a technical mistake. It can create audit findings, legal disputes, privacy issues, and regulatory exposure.
The speed has changed. In the past, building enterprise automation required time and specialized knowledge. Today, a user can generate a PowerShell script, Graph API integration, or Power Automate workflow in minutes. That means security teams are no longer reviewing automation at the same pace it is being created.
The old assumption that only experienced developers are building production workflows is no longer valid. AI has made many more employees capable of creating powerful automation, including people who do not understand the security model behind what they are deploying.
This is where many organizations are blind. They govern applications, cloud infrastructure, endpoints, and identities, but they often have weak visibility into the automation layer connecting all of them.
Banning AI assistants is not a realistic answer. Blocking automation is not realistic either. Both are now part of how modern businesses operate.
The better answer is control.
Security teams should treat AI-generated automation like code. Power Automate flows, Graph scripts, app registrations, service accounts, eDiscovery queries, and PowerShell automations should be reviewed before production use.
They should also enforce least privilege across Microsoft 365 automation. Broad Graph permissions, standing admin access, over-permissive connectors, and shared service accounts should be treated as high-risk findings.
Organizations need an inventory of workflows and scripts running across Microsoft 365. If security teams do not know a workflow exists, they cannot assess its risk.
Monitoring also matters. New flows, connector changes, permission grants, external sharing activity, unusual file movement, and app consent events should be reviewed continuously.
Finally, developers and citizen developers need clear guidance: AI-generated code is not approved code. It is a draft that still requires human review.
The next major enterprise security blind spot may not be AI-generated malware.
It may be AI-generated business automation that looks harmless, passes functional testing, and quietly introduces excessive permissions, data exposure, and compliance failures into Microsoft 365. The workflow will not look suspicious. It will not trigger alarms. It will simply do what it was asked to do. And that is exactly why it is dangerous.
Don’t miss the latest Dark Reading Confidential podcast, Do CISOs Need a Code of Ethics? Kickbacks, no-show jobs, “dirty” VCs, and shelfware — industry expert Robert “RSnake” Hansen explains why he thinks its time for a CISO code of ethics. It could ensure cybersecurity bosses aren’t engaged in self-dealing that could risk enterprise, and even national, security. Listen now!
No responses yet