Microsoft Agent 365 for SharePoint: A 30-Day Rollout Plan

Microsoft Agent 365 reached general availability on May 1, 2026 and picked up Entra Agent Identity, cross-agent policy packs, and the audit surface most tenants were missing at Build 2026 (May 20-22). If you have five or more custom agents already touching your SharePoint sites — Copilot Studio agents, Power Automate agent flows, external ISV agents, home-grown MCP servers — you have already crossed the operational threshold where Agent 365 stops being optional. This is the observe / govern / secure / audit control plane for the agent population inside your tenant, and SharePoint is where most of them read from.

Our team has been running Agent 365 pilots inside customer tenants since the November 2025 private preview. This is the 30-day rollout we now use as the default engagement shape.

The trigger: when Agent 365 stops being optional

We used to tell customers Agent 365 was a "when you are ready" purchase. That guidance is dead. Once you have more than four or five custom agents actively reading from SharePoint — and almost every enterprise tenant is already past that number, whether IT knows it or not — you have crossed three thresholds at once:

• Identity sprawl. Each agent is running under a service principal, a managed identity, an app registration, or (worst case) a shared user account. You cannot report on "who did the agent do that as."
• Permission opacity. Agents inherit the permissions of the identity they run under. Nobody has mapped which agent can read which SharePoint site.
• Audit gap. Standard Microsoft Purview audit logs record the identity that took the action, not the agent that decided to take it. A prompt injection that causes Agent A to trigger a Graph call looks identical, in the audit log, to a legitimate user action.

Agent 365 closes all three. It gives every agent a first-class Entra Agent Identity (distinct from user and service principal), enforces policy at the identity, and writes an agent-aware audit stream. If your tenant is above the five-agent threshold and you are still relying on Purview + app registration reporting, you have a governance gap that a determined red team can walk through.

Related reading on operational SharePoint governance: our SharePoint consulting practice and the document management guides go deeper on the underlying permission surface.

The four-pillar model

Agent 365 organizes its capabilities under four pillars. Understanding them up front matters because it maps directly to the rollout weeks.

| Pillar | What it does | SharePoint impact |

|--------|--------------|-------------------|

| Observe | Inventory of every agent touching the tenant, with per-agent telemetry (prompts, tool calls, latency, cost). | You can finally see which agent is the top consumer of a given site collection. |

| Govern | Policy packs applied to agent identities — data boundaries, allowed tools, allowed connectors, sensitivity-label constraints. | Enforce that Agent X can only read from sites labeled General or Confidential-Internal, and never anything at Highly Confidential. |

| Secure | Runtime protections — prompt injection detection, jailbreak monitoring, tool-call anomaly detection, kill switches. | If an agent starts hitting SharePoint Search 40x its baseline rate, Agent 365 flags and can auto-quarantine. |

| Audit | Agent-aware audit logs, retention policies, and Purview integration that records the agent identity plus the underlying user context. | Investigations no longer have to reverse-engineer "which agent did this on behalf of which user." |

Official architecture reference: Microsoft Agent 365 overview and the product page.

Custom agent types and how Agent 365 handles each

Not every agent type gets the same treatment on day one. This table is the one we walk customers through in kickoff:

| Agent type | Agent 365 handling in June 2026 | Notes |

|------------|-------------------------------|-------|

| Copilot Studio agents (declarative) | Native — inventoried automatically, policy pack applies. | Zero-touch for tenants where Copilot Studio governance is already on. |

| Copilot Studio agents (custom engine) | Native, but you must register the endpoint. | Roughly 15-minute registration per agent. |

| Power Automate agent flows | Native (Build 2026 announcement). | Requires Power Platform environment on 2026 wave 1. |

| SharePoint embedded agents | Native. | Sensitivity-label gating available out of the box. |

| Home-grown MCP server agents | Registration required — you provide the endpoint and identity. | Policy pack applies once registered. |

| Third-party ISV agents from AppSource | Native if the ISV opted in; manual registration otherwise. | Check the AppSource listing for the "Agent 365 ready" badge. |

| Web-app agents calling Graph directly | Manual registration; treat as external client. | These are the highest-risk unregistered agents in most tenants. |

The 30-day rollout

Week 1 — Inventory

The first week is entirely discovery. You cannot govern what you have not counted.

• Day 1-2. Turn on Agent 365 in audit mode. No policy enforcement yet. Just start the telemetry stream. You will see agents you did not know existed within 24 hours.
• Day 3-4. Cross-reference the Copilot Studio catalog, the Power Platform environment agent inventory, and the Entra app registration list. Build a single spreadsheet with agent name, owner, identity, and (critically) which SharePoint sites the agent has been observed reading in the last 30 days.
• Day 5. Run the SharePoint search audit query. Look at the top 20 identities issuing search queries against your tenant. If any of them are non-human and not in your spreadsheet, they get added.

At the end of week 1 you have a defensible inventory. Almost every customer we have taken through this discovers 20-40% more agents than the CIO thought existed.

Week 2 — Identity onboarding

• Day 6-7. Assign Entra Agent Identity to every registered agent. This is the hard cutover from "agent running as a service principal" to "agent running as an agent." You can run both in parallel for the transition — Agent 365 supports dual identity for up to 30 days.
• Day 8-9. Reissue permissions against the new identities. This is where most rollouts get caught by surprise: the agent identity does NOT inherit the service principal's SharePoint permissions. You have to reissue. Plan for a lot of "why did my agent stop working" tickets on day 8.
• Day 10. Establish the naming convention. We recommend `agent---` — for example `agent-finance-po-approval-prod`. Retrofit the inventory.

Week 3 — Policy pack

• Day 11-13. Publish the baseline policy pack. Data boundary (tenant-only, no external egress), allowed tools (Graph + Search + SPO REST), disallowed connectors (any that egress to public LLM APIs unless whitelisted), sensitivity-label ceiling (start with "no Highly Confidential" and relax per-agent).
• Day 14-16. Publish per-agent overrides. The finance PO approval agent needs the Purchase Orders site. The HR onboarding agent needs the HR Confidential library. Overrides are additive — the baseline still applies.
• Day 17. Turn policy pack from audit to enforce. This is the go-live moment for policy. Have an on-call rotation for 48 hours because you will find at least one agent that has been quietly reading a site it should not have.

Week 4 — Monitoring and escalation

• Day 18-21. Wire the alerts. Anomaly detection thresholds (search calls per minute per agent), prompt injection alerts, kill switch runbooks. Publish the runbooks to your operations team.
• Day 22-25. Run the tabletop. Pick one production agent. Simulate: (a) a prompt injection that causes the agent to try to read a site it does not own; (b) a runaway loop that hits Search 100x normal rate; (c) a compromised identity. Verify Agent 365 catches all three and that your runbook actually works.
• Day 26-30. Handoff to operations. Weekly review cadence, monthly policy pack revision, quarterly identity attestation.

Three anti-patterns we see repeatedly

• Turning enforce on before inventory is complete. You will break production. Always run audit mode for at least seven days first.
• Reusing service principal identities as agent identities. Defeats the entire point. Provision fresh Entra Agent Identities.
• No sensitivity-label ceiling. Every agent inherits the baseline. If you do not set one, agents can read any site their identity can reach — including whatever gets misclassified next Tuesday.

Where SharePoint operations fits in

Our SharePoint support engagements now include an Agent 365 audit as part of the standard onboarding, and our SharePoint Copilot rollouts treat Agent 365 as a prerequisite for anything beyond a proof of concept. The tenants that have gone through the 30-day plan above have caught permission bleed within the first two weeks, every time.

Expert help from our SharePoint consultants

Agent 365 is the highest-leverage tenant governance change of 2026 and the rollout window matters — every custom agent you register after the fact is more work than one you onboard now. Our SharePoint consultants run the 30-day plan above end-to-end, including the identity cutover and the tabletop exercise most tenants skip. If your tenant is above the five-agent threshold, reach out and we will scope a fixed-fee engagement.