# AI agents in Microsoft 365: the new attack surface to audit > Copilot agents, shadow AI and OAuth grants are multiplying inside Microsoft 365 tenants. Here is what agent sprawl looks like, why every agent is a non-human identity, and the audit checklist to run. Source: https://olyteck.com/blog/ai-agents-microsoft-365-security Published: 2026-07-28 | Updated: 2026-07-28 Author: Oleg Garasym, Olyteck (France, EU-hosted) Product: Olyteck Cyber Topics: ai agents, agentic ai, non-human identity, copilot agents, shadow ai, oauth, microsoft 365, governance, agent sprawl License: free to quote with attribution to Olyteck and a link to the source URL. --- Two years ago the question was "should we enable Copilot". In 2026 the question has changed shape: your users are building and installing AI *agents* - in Copilot Studio, in Teams, from SaaS vendors, and increasingly on their own machines. Microsoft's answer to the resulting chaos even has a product name now (Agent 365, a registry and control plane for agents), which tells you how real the problem has become. The industry word for it is agent sprawl. An agent is not a chat window. It is software that acts: reads mailboxes, writes files, calls APIs, triggers workflows. Every agent is therefore an identity with permissions - a *non-human user* in your tenant - and most organisations have no inventory of them. ## Why agents are a permissions problem, not an AI problem Everything we already knew about Copilot applies, amplified. Copilot surfaces what a user can already access; an agent *acts* on what it can access, around the clock, without the human pause that sometimes catches mistakes. Three patterns do most of the damage: - **Over-consented OAuth apps.** An AI meeting-notes tool that asked for `Mail.Read` and full file access, approved in one click by a user in 2025, is still there, still reading. Agent platforms multiply these grants. - **Shadow agents.** Users connect personal AI tools to work accounts because it makes them faster. Each connection is an unaudited data path out of your tenant, invisible in your license list. - **Orphaned agents.** The employee who built the workflow agent leaves; the agent keeps running under credentials nobody remembers granting. It is the service-account problem again, at ten times the creation rate. The deeper shift is from controlling access to controlling actions. Traditional permissions answer who can open a file. An agent forces a second question its consent screen never asked: what is it allowed to *do* once inside, and does that action make sense in context? Model safeguards alone will not answer that. The control has to sit with your data, on your side, where you can actually see what each non-human identity is reaching for. ## The audit checklist You cannot govern agents you cannot see, so the work starts with inventory, not policy. 1. **List every OAuth application with consented permissions in the tenant.** Sort by scope breadth (mail, files, directory) and by who consented. Flag anything AI-related that a user self-approved. 2. **Find the high-privilege grants.** `Mail.ReadWrite`, `Files.ReadWrite.All`, `Directory.Read.All` held by third-party apps deserve a named owner and a written justification each. 3. **Inventory Copilot Studio and Teams agents.** Who built each one, what does it connect to, who can invoke it, and is the builder still an employee? 4. **Check what agents can reach.** An agent grounded on "all of SharePoint" inherits every oversharing mistake you have. The Copilot readiness work (broad-access sites, anonymous links, stale guests) is also agent readiness. 5. **Look for stale and orphaned credentials.** Agents authenticate with app secrets and certificates that expire, get copied, and outlive their owners. 6. **Decide an approval path.** One page: who may create agents, what scopes need review, and how often the inventory is re-checked. Without a path, users route around you. > An AI agent is a new employee who works at machine speed, never sleeps, and was hired by whoever > clicked "consent". The audit question is the oldest one in security: who can access what, and who > decided? ## Getting the inventory without a scripting project Microsoft Graph exposes OAuth grants, service principals and app permissions, and you can enumerate them with PowerShell if you are willing to maintain the scripts and re-run them monthly - sprawl grows back the moment you stop looking. The faster route is a read-only scan: Olyteck Cyber walks the tenant through Graph and reports OAuth applications and their permission scopes alongside the sharing and identity findings, without exporting file contents. It counts findings, never files. Either way, treat July's inventory as a baseline, not a fix. The organisations that stay in control of agents in 2026 are not the ones that banned them - bans just create better-hidden shadow agents. They are the ones that can answer, at any moment, the simple question: what is running in our tenant, and on whose authority? ## FAQ ### What counts as an AI agent in Microsoft 365? An agent is software that acts rather than software that answers. It reads mailboxes, writes files, calls APIs and triggers workflows, which is what separates it from a chat window. That includes agents built in Copilot Studio, agents installed in Teams, agents shipped by SaaS vendors, and AI tools users connect to their work account from their own machines. In each case the agent holds permissions in your tenant, so it is a non-human identity. ### How do we find out which AI agents are already running in our tenant? Start with the OAuth applications that have consented permissions and sort them by scope breadth and by who granted the consent. Then inventory the agents built in Copilot Studio and Teams, recording who built each one, what it connects to, who can invoke it and whether the builder is still an employee. Microsoft Graph exposes OAuth grants, service principals and app permissions, so the data is available to you either through your own enumeration or through a read-only scan. ### Should we just block AI agents instead of auditing them? Bans do not produce control. The organisations that stay in control of agents are not the ones that banned them, because users connect personal AI tools to work accounts when it makes them faster and a ban mostly pushes that behaviour out of sight. A blocked environment tends to end up with better-hidden shadow agents and no inventory at all, which is worse than a governed one. ### Do we need PowerShell scripts to audit OAuth grants and agents? You can enumerate OAuth grants, service principals and app permissions with PowerShell if you are prepared to maintain the scripts and re-run them monthly, since sprawl grows back as soon as you stop looking. The alternative is a read-only scan such as Olyteck Cyber, which walks the tenant through Graph and reports OAuth applications and their permission scopes alongside sharing and identity findings, without exporting file contents. Either way the output is a baseline to re-check on a schedule, not a one-off fix.