Defender for Cloud Apps session policy

Most MSPs treat Conditional Access as a light switch. Allow or block. Compliant device or not.

That works right up until a director needs OneDrive from a hotel laptop. Or a contractor needs SharePoint from a personal Mac. So you carve an exception, and the exception slowly becomes the policy.

There’s a third option sitting between allow and block. Almost no one in the SMB world turns it on.

It’s called a session policy, and it lives inside Defender for Cloud Apps. If your client is on E5 or Microsoft 365 E5 Security, they’re already paying for it.

What is a session policy, really?

A session policy is a real-time guardrail that fires after the user signs in. It rides along inside the browser tab.

It can block a download. It can block an upload. It can block copy-paste. It can force a sensitivity label on a file before it leaves OneDrive. It can make a user re-prove MFA before doing something sensitive — all without touching the device.

That’s not access control. That’s session control. Think of it as a referee inside the meeting, not a bouncer at the door.

It needs two pieces to fire. A Conditional Access policy in Entra ID that routes the session through Defender for Cloud Apps using Conditional Access App Control. And a matching session policy in the Defender portal that decides what to do once the session is in flight. Microsoft’s own Conditional Access app control overview is worth a read because it shows the reverse-proxy path the session actually takes.

One licensing note. Defender for Cloud Apps is not in Business Premium. You need E5, M365 E5 Security, or the standalone MDCA add-on. Plenty of SMBs already have it bundled and never realise.

Step-by-Step: blocking download to unmanaged devices

The killer scenario. Someone signs in to OneDrive from a personal laptop. They can read. They can edit in the browser. They cannot save a single file locally. No agent, no Intune enrolment, no work touching their device.

Build the Conditional Access policy

In the Microsoft Entra admin centre, go to Protection > Conditional Access > Policies and start a new policy. Scope it to your pilot group. For the cloud app, choose Office 365. Leave Grant on Grant access with no requirements — the heavy lifting happens elsewhere.

Turn on App Control

In the Session block, tick Use Conditional Access App Control and pick Use custom policy from the dropdown. That single tick is what tells Entra to hand the session to Defender. The full guidance lives in the Microsoft Learn how-to.

Move to the Defender portal

Now jump to security.microsoft.com. Under Cloud apps > Policies > Policy management, create a new Session policy. Start from the Block download based on real-time content inspection template — it saves a lot of clicks.

Filter to OneDrive and unmanaged devices

Set Activity source to Office 365 > OneDrive for Business. Add a filter: Device tag = Unmanaged. The action becomes Block file download.

Write a real block message

Don’t ship the Microsoft default. Tell the user why the file won’t download and what to do next. A blank “blocked by policy” page makes users fight the system and ring the helpdesk.

Run it in monitor-only first

Set the policy to Monitor only for a week. Watch the activity log. Confirm you’re catching the right sessions, on the right apps, against the right users. Then flip to Block. Microsoft’s create-a-session-policy walkthrough covers the screens for both modes.

Why this actually changes behaviour

Here’s the real win. Your director still gets OneDrive on the hotel laptop. The board paper opens in the browser. They can read it, comment on it, work through it.

They cannot drop it into the hotel laptop’s downloads folder.

That’s not a compromise. That’s the policy doing what you actually wanted the whole time.

“But why can’t I just block unmanaged devices outright?”

You can. You’ll also block every legitimate contractor, every guest reviewer, every consultant on a personal machine. Block is a single-use tool. Session policy is a scalpel.

Notice what’s missing? No agent on the device. No MDM. No certificate enrolment. The browser gets reverse-proxied through an *.mcas.ms URL and the session is policed in flight. Edge users get it in-browser with no URL change.

A copy-paste summary of what you’ve actually built looks like this:

Session policy: OneDrive – Block download from unmanaged
  Activity source : Office 365 → OneDrive for Business
  Device filter   : Device tag = Unmanaged
  Action          : Block file download
  Block message   : Custom — explain WHY + WHAT TO DO
  Content scan    : All files
  Phase           : Monitor → Block after 7 days

Notice what’s not in there. No list of apps. No list of file types. The whole policy keys off the device tag, because that’s the bit you can trust — Entra knows whether a device is compliant or unmanaged; the user can’t lie about it.

Where MSPs trip up

Three things bite people on the first rollout.

The Conditional Access policy must include the session control. If App Control isn’t ticked in CA, nothing routes to Defender. Many MSPs build the two policies as separate stories. They’re one story.
Native clients bypass MDCA. Outlook desktop, OneDrive sync, Teams desktop — none of them route through the reverse proxy. If you genuinely need to force browser, use the Entra session control Use app enforced restrictions on top, and read the Conditional Access session controls page before you go further.
Certificate chains matter. If the SaaS app has a partial chain, the proxy goes sideways. Test before you scope wide.

My recommendation

If you’ve got a client on E5 or M365 E5 Security and you’re not running at least one session policy, you’re leaving the most valuable thing in their stack switched off. Walk in next Monday with exactly one policy — block download from unmanaged for OneDrive. Monitor for a week. Flip to block. Show them the activity log.

Session policies aren’t there to keep users out. They’re there to let them in without the data following them out.

Formal education will make you a living; self-education will make you a fortune

Jim Rohn said it years ago: formal education will make you a living, self-education will make you a fortune. I’ve been turning that one over in my head again lately, and not for sentimental reasons. The gap between what you learned at school or university and what you actually need to know next Tuesday has never felt wider. And the people I see pulling ahead — in their careers, in their businesses, in their thinking — are almost always the ones who took their own learning seriously after the formal part stopped.

The bit that strikes me now is how much easier self-education has become, and how few people are actually doing it.

The classroom you carry around

The tools sitting on most people’s laptops right now would have looked like science fiction to a teacher twenty years ago. I open Copilot in Edge while I’m reading a long article and ask it to explain the part I didn’t quite get, in the context of my industry. I drop a dense PDF into Copilot Chat and ask what I should pay attention to before a meeting. I’m in Word writing something, and I ask Copilot to challenge my argument the way a sceptical colleague would. None of that is a course. It’s a habit. And the habit is what compounds.

What I notice is that people still treat learning as a thing they do somewhere else — a course, a webinar, a conference once a year. The interesting shift is that learning has quietly moved into the flow of work. The hour you used to spend hunting for an answer is the hour where the real growth happens, if you let the tools help you instead of just hand you a result.

Curiosity is the edge now

Here’s the part I think people underestimate. Copilot won’t make you smarter on its own. It rewards the people who already ask better questions. If you go in with “summarise this”, you get a summary. If you go in with “what’s the second-order effect of this on a small business with thin margins”, you get a conversation. The technology has lifted the floor and raised the ceiling at the same time, and the gap between the two is mostly down to how curious you are.

I see this in Teams meetings as well. The people who stay sharp open Copilot afterwards and ask it what they missed, what was implied, what didn’t get said. They use the recap as a starting point, not an ending. Same meeting, same transcript — completely different outcome depending on the questions you bring.

The fortune bit

Rohn’s line isn’t really about money. The fortune he’s pointing at is the compounding effect of being someone who keeps learning when nobody is making them. A CV gets you in the door. Self-education is what decides whether you’re still useful to your business, your clients, and yourself five years from now.

The honest truth is that the formal qualifications I picked up early in my career are a smaller part of what I do today than the stuff I’ve taught myself since. And the rate at which I can teach myself something now — with Copilot in Outlook explaining a thread, in Excel walking me through a model I didn’t write, in SharePoint pointing me at the document I’d forgotten existed — is something I genuinely couldn’t have imagined a few years ago.

The classroom never closed. We just stopped recognising it for what it is — and the people who keep showing up to it are quietly building the fortune Rohn was talking about.

Most SMB tenants have a guest graveyard

Most SMB tenants I look at have a “Guest Users” list that’s basically a graveyard. People invited for a project that finished in 2022. A contractor whose engagement ended last March. Somebody’s external accountant who hasn’t signed in since the BAS that prompted the invite.

Nobody removes them. Nobody can remember why they were added. Nobody’s even sure who should remember.

That’s not a guest problem. That’s a governance problem.

Now do the same exercise with Global Administrator. Or Privileged Role Administrator. Or that mystery security group somebody pinned to a SharePoint site three years ago and called “Finance – All”. Same pattern. Stale access. No owner. No expiry.

This is exactly what Access Reviews in Entra ID Governance is built to fix — and most MSPs I talk to either don’t know they’re licensed for it or have never actually run one.

Time to fix that.

What is Access Reviews, really?

Access Reviews is a recurring “are you sure?” loop. You point it at a group, an application, a privileged role, or every guest in your tenant. On a schedule you pick, it emails a reviewer — you, the group owner, or the user themselves — and asks them to confirm whether each person still needs the access they’ve got.

If the reviewer says no, or doesn’t reply and you’ve configured “no response = deny”, the access gets removed automatically when the review ends. No tickets. No spreadsheet. No “I’ll get to it next quarter”.

It’s the same job your auditor wants you to do at a desktop level. Just done in the portal, on a timer, with an audit trail attached.

What you need to run one

Licensing trips most people up here. Access Reviews is an Entra ID P2 or Entra ID Governance feature, and licensing is per user, not per tenant. Every user whose access you’re reviewing needs to be covered. Guest accounts don’t need a license to be reviewed, which is the one bit of good news.

Business Premium customers don’t have P2 in the box. If they want this, they need Microsoft 365 E5 or the Entra ID Governance add-on. Tell the client up front — don’t promise the feature and discover the gap at invoice time.

You’ll want Identity Governance Administrator or Global Administrator to set the first review up. Group owners can run reviews on their own groups once an admin enables the toggle in the Access Reviews settings.

Step-by-Step: a recurring guest review

Start here on every tenant. It’s the easiest win.

Open the portal

Sign in to entra.microsoft.com as Identity Governance Administrator. Go to ID Governance > Access Reviews > New access review.

Pick what to review

In Select what to review, choose Teams + Groups, then All Microsoft 365 groups with guest users. This is the magic option. It creates one recurring review that sweeps every M365 group containing guests, across the whole tenant, automatically, forever.

Set Scope to Guest users only.

Pick your reviewers

Pick Group owners with a fallback. Group owners actually know whether Alice from the partner agency still needs Teams access. You don’t. You also don’t want to be reviewer-of-last-resort for fifty groups.

Set the schedule

Recurrence: Quarterly. Duration: 5 days. Long enough that nobody can claim they were on leave. Short enough that the next quarter doesn’t lap it.

Set the settings that actually matter

This is where most people skim and lose the whole value of the feature. Slow down.

Auto-apply results to resource: On. Without this, denied users stay in the group until somebody manually clicks apply. They never do.
If reviewers don’t respond: Remove access. Yes, really. If the owner can’t spend two minutes confirming a guest, the guest goes.
Justification required: On. Forces reviewers to type a reason for “keep”. Stops the rubber-stamp click-through.
Mail notifications + reminders: On.

Name it Quarterly Guest Review - All M365 Groups, hit Create, done.

Step-by-Step: privileged groups and admin roles

Same engine, different doorway. PIM for Entra roles and PIM for Groups each have their own access review entry point — not the one above.

For Entra admin roles

Open PIM > Microsoft Entra roles > Access reviews > New. Review every role with active or eligible assignments. Reviewer = the user themselves, because self-attestation forces them to type a justification. Add a second-stage approver if you want belt-and-braces. Recurrence: every 90 days for admin roles. No exceptions.

For privileged groups

If you’re using PIM for Groups to gate access to sensitive things, you can review the eligible members on the same cadence. Same wizard, hosted under PIM. Same settings. Same auto-apply.

Notice what’s missing? PowerShell. None of this needs it. Portal only.

One artefact you can paste into every client runbook

Guest access:     quarterly, 5-day window, owner-reviewed,
                  no response = remove, auto-apply on.
Admin roles:      every 90 days, self-attest + 2nd stage,
                  no response = remove, auto-apply on.
PIM for Groups:   every 90 days, owner-reviewed,
                  no response = remove, auto-apply on.

Notice what’s not in there? Anything called “annual”. Annual reviews don’t do anything except let stale access fester for eleven and a half months. If the cadence isn’t quarterly or better, you don’t have a control — you have a calendar reminder.

Why this actually changes behaviour

Before: “I’ll clean up guests when I get a chance.” After: “The system already did it last Tuesday.”

That’s the shift. Access Reviews moves access cleanup from a thing humans intend to do into a thing that happens whether they intend to or not.

For an MSP the win is bigger. Every client tenant you manage produces a quarterly evidence trail — who reviewed what, what got removed, who signed off. Exactly the evidence the cyber insurer asks for at renewal. Exactly the evidence an SMB1001 or Essential Eight auditor wants on the table. According to the Access Reviews FAQ, reviewers and decisions are captured against each instance, so the audit trail is already there — you just have to turn the reviews on.

You’re not selling “we’ll clean up your guests” anymore. You’re selling governance with a paper trail.

Access Reviews isn’t there to help you remember to remove stale access. It’s there to remove it whether you remember or not.

If you’re not turning this on for your clients, you’re leaving the easiest governance win in Microsoft 365 on the table.

The First Client Problem Isn’t What You Think It Is

I’ve watched a lot of people sit on the edge of starting something — a side practice, a Copilot consultancy, a niche advisory offer — and almost none of them are stuck for the reasons they tell themselves. They’ll say they need another certification, one more course, a tighter offer, a better website. What they actually need is to be seen doing the work before the work feels finished.

This is the quieter truth about building anything online, and I think it’s worth saying out loud. The distance between where you are right now and your first paying client is almost never a knowledge gap. Most people reading this already know enough to genuinely help someone tomorrow morning. What’s missing is the willingness to stand up in public as someone building a thing before they feel they’ve earned the right to be seen that way.

The Permission You’re Waiting For Isn’t Coming

Nobody hands out the badge. There is no moment where the industry quietly agrees you’re now ready to charge for advice. I waited a long time for that feeling early on, and I can tell you it doesn’t arrive — you just start, and the evidence catches up.

The strange part is that the evidence is usually already there. If you’ve spent the last few years inside Microsoft 365 — wrangling Conditional Access, untangling SharePoint permissions, helping a team actually adopt Copilot in Outlook instead of just licensing it — you already know more than the SMB owner who is googling at 9pm trying to work out why their Teams meetings won’t record. You don’t need another module. You need to write the post, record the short video, send the email to the contact who half-asked about it last month.

Make Yourself Findable Before You Feel Ready

The practical move is to put something out into the world that someone could trip over. A LinkedIn post about a real Copilot rollout you ran last week. A short Loop page you can share with prospects that walks through how you set up Copilot governance for an SMB. A simple SharePoint site with three case write-ups on it. None of this needs to be polished. It needs to exist.

I use Copilot in Word to take rough voice-memo thoughts and shape them into a draft I can edit down — not to write the post for me, but to break the inertia of the blank page. Then I’ll ask Copilot in Outlook to help me re-thread an email to a warm contact I’ve been meaning to nudge for a fortnight. The tool isn’t doing the courage part. It’s removing the friction so the courage has somewhere to go.

Your First Client Is Watching, They Just Haven’t Said Anything Yet

Here’s what I’ve noticed across years of MSP work: the person who eventually becomes your first paying client is almost always already in your network. They’ve seen a comment of yours, half-read a post, remembered something you said at an event. They are waiting for a small signal that you are open for business. That signal is you — visible, building in public, named as the person who does this thing.

You don’t have to declare yourself an expert. You only have to be specific about what you’re working on right now and who it’s for. The credibility compounds from there.

If you’re sitting on enough knowledge to help someone, the next step isn’t more learning. It’s letting yourself be seen mid-build. The evidence really does catch up. You just have to take the step before it does.

What is Microsoft Agent 365, really?

Most folks I talk to think agents are just Copilot with extra steps. They’re not.

A Copilot prompt is a single user, asking a single question, in a single session. An agent keeps running. It has tools, it has access, it makes decisions, and it does all of that whether you’re watching or not.

Agents don’t sleep. They also don’t ask permission.

That’s the part nobody seems ready for. Last year your tenant had users. This year it has users and agents. Some you bought, some your developers built, some your staff spun up in Copilot Studio over the weekend and forgot about.

So here’s the question I keep asking MSPs: do you actually know how many agents are running in your client’s tenant right now? If the answer is “probably some”, that’s not governance. That’s hope.

Microsoft Agent 365 is the control plane for agents. That’s it. It’s not a new agent. It’s not a new Copilot. It’s the place you go to see every agent in the tenant, decide what each one is allowed to do, and shut down the ones that shouldn’t be there.

Think of it like the Microsoft 365 admin centre, but for non-human accounts. The agents your team built. The agents your vendors sold you. The agent embedded inside that SaaS app marketing signed up for last quarter. All of them, in one registry, with one set of policies.

It went generally available on 1 May 2026 at USD$15 per user per month, and it pulls Microsoft Entra Agent ID(opens in new window), Microsoft Purview, and Microsoft Defender into a single agent lifecycle story. The official overview lives on Microsoft Learn(opens in new window).

Notice what’s missing? You. The user. Agent 365 isn’t an end-user tool. It’s for admins, MSPs, and security folks. It’s the dashboard your clients don’t see — and the one that keeps them out of trouble.

Step-by-Step: Finding the agents already in your tenant

The first thing I’d do in any tenant is just look. You’ll be surprised.

Sign in to the Microsoft 365 admin centre

Go to admin.microsoft.com as a Global Admin or AI Administrator.

Open the Agents workload

In the left navigation, expand Agents and select Overview. That’s the Agent 365 dashboard. If the tenant has a qualifying licence, you’ll see Agent 365 branding. If it doesn’t, you still get the baseline agent management view.

Review the registry

Select All agents. This lists every agent the tenant knows about — Copilot Studio agents, declarative agents, SharePoint agents, third-party agents, and anything registered via the new Agent 365 API. Each one shows its owner, source, and current status. The admin centre docs(opens in new window) walk through the columns.

Hunt for ownerless agents

Filter by owner. Anything marked ownerless is a red flag — that’s an agent doing things in the tenant with no human accountable for it. Assign an owner or block it. Don’t leave it.

Apply a policy

From an agent card, set access policies — who can run it, what data it can touch, whether it needs review before it publishes. Use the policy templates rather than rolling your own.

Before Agent 365, the question was “what agents are we using?” After Agent 365, the question is “what agents are we allowing?” Different question, different answer.

Why this actually changes the game

Here’s the real win. Agents inherit risk in a way users don’t. A user clicks a phishing link and one mailbox is compromised. An agent with delegated access and a bad prompt can touch SharePoint, send mail, and rewrite records — at machine speed, across hundreds of users — before anyone notices.

That’s why Agent 365 leans on Entra Agent ID to give every agent a first-class identity. No more agents hiding behind a generic service account. Each one shows up in sign-in logs, audit logs, Conditional Access, and Defender. You can revoke an agent the same way you’d revoke a user.

That’s not a feature. That’s a fundamental shift in how you secure a tenant.

My recommendation?

If you’re an MSP, start the conversation with your clients this quarter. Open the admin centre. Show them the agent list. Most of them have no idea what’s in there, and the longer they don’t know, the bigger the eventual cleanup.

If you’re not showing your clients this, somebody else will — and they’ll be the ones writing the agent governance policy on your client’s tenant.

Agent 365 isn’t there to add another dashboard to your day. It’s there to stop the shadow AI mess before it starts.

Intune compliance policies + Conditional Access integration

Most people I speak to think the work of locking down devices in Microsoft 365 is creating the Intune compliance policy. They tick the boxes — BitLocker on, minimum OS, no jailbreaks — hit Save, and walk away feeling secure.

They aren’t.

A compliance policy on its own does precisely nothing to a sign-in. It’s a label. Intune looks at a device, decides “compliant” or “not compliant”, and writes that state back to Entra ID. That’s it. Nothing is blocked. Nothing is challenged. The policy is information, not enforcement.

The enforcement lives somewhere else entirely. It lives in Conditional Access.

If you’re not wiring those two things together, you’ve done half a job. And the half you skipped is the half that actually protects the tenant.

What is an Intune compliance policy, really?

Think of a compliance policy as a health check that runs on the device and ships the verdict back to your tenant. Encrypted? Patched? Joined to your tenant? Defender running? Out comes a true/false, and Entra ID writes it onto the device record.

That verdict is now available as a signal. Anything that can read Entra signals — and Conditional Access is the big one — can use it to make access decisions.

So the compliance policy is the sensor. Conditional Access is the gate. You need both, or you have neither.

Step-by-Step: wiring compliance to Conditional Access

Portal only. No PowerShell. This is what I do on every Business Premium tenant I touch.

Fix the tenant default first

Open the Intune admin center, go to Devices > Compliance > Compliance policy settings.

Find the setting Mark devices with no compliance policy assigned as. It ships set to Compliant.

Change it to Not compliant. Save.

That one setting is the difference between “any device in my tenant counts as good” and “a device has to earn it”. You’d be amazed how many tenants I audit where this is still on the default.

Build the compliance policy

Same portal. Devices > Compliance > Policies > Create policy. Pick Windows 10 and later (start there — do iOS and Android next).

Use the settings catalog options to set sensible rules — require BitLocker, a minimum Windows build, Defender real-time protection on, Defender signatures up to date. Don’t try to be heroic on day one. Set what you can defend with a straight face. Microsoft’s own walkthrough is the canonical reference.

In Actions for noncompliance, do not leave the default of “Mark device noncompliant: 0 days”. Give yourself a grace window — 1 to 3 days — and add a Send email to end user action a day earlier. People deserve a heads-up before they’re locked out of email.

Assign to a pilot user group. Not all users. A pilot group.

Build the Conditional Access policy

Now flip over to the Entra admin center: Entra ID > Conditional Access > Policies > New policy.

Users: include your pilot group. Exclude your break-glass account. Always.

Target resources: All resources.

Grant: Require device to be marked as compliant. Save.

And here’s the critical bit — set Enable policy to Report-only. Not On. Report-only.

Users:       Pilot group
Exclude:     Break-glass account
Resources:   All resources
Grant:       Require device to be marked as compliant
Enable:      Report-only

Notice what’s missing? MFA. That belongs in a separate policy. One policy, one job. Stack them, don’t fuse them.

Watch report-only for a week

Sign-in logs > Report-only tab. You’re looking for users who would have been blocked and shouldn’t have been — usually a missing enrollment, a personal device that needs the App Protection path instead, or a service account.

When the report-only data is clean, flip the toggle to On. Microsoft’s compliant-device CA template walks the same path.

Why this actually changes behaviour

“But MFA is already on. Isn’t that enough?”

It isn’t. MFA proves the user. Compliance + CA proves the device. Token theft doesn’t care about your MFA prompt — it cares whether the device the token landed on is one you trust. This is the bit MFA-only tenants are missing.

It also collapses three messy conversations down to one. “Is this laptop ours? Is it patched? Is it encrypted?” All of it rolls into one signal — compliant, or not. Conditional Access reads that one signal and decides. No more inventory spreadsheets. No more guessing.

And if you’re an MSP, this is the most defensible artefact you can show a client during an incident. The device was non-compliant. Access was blocked. That’s a finished sentence.

A compliance policy isn’t there to make a list of bad devices. It’s there to make sure they never sign in.

Restricted SharePoint Search Is Not the Fix You Think It Is

Most people’s first reaction to Copilot and SharePoint goes something like this: “Wait — Copilot can see all of that?”

Then they panic. Then they Google. Then they find Restricted SharePoint Search and flip it on like it’s a fire extinguisher.

I get it. The instinct is right — you should care about what Copilot can reach. But RSS isn’t a security control. It’s a stalling tactic. And if you leave it on too long, it’ll cause more problems than the one you were trying to solve.

What is Restricted SharePoint Search, really?

RSS lets a SharePoint admin maintain an allowed list of up to 100 SharePoint sites. Only those sites show up in organisation-wide search results and Copilot chat responses.

That’s it. It doesn’t change a single permission on a single site. It doesn’t block anyone from accessing anything. It just hides sites from search and Copilot — unless the user has recently visited the site, or it was shared with them in Teams or Outlook. In which case, it shows up anyway.

That’s not a security boundary. That’s a curtain.

Microsoft’s own documentation on RSS says it plainly: this is designed as a short-term solution while you audit permissions and apply proper governance. It’s not meant to stay on.

Step-by-step: Setting up RSS the right way

If you’re going to use RSS — and there are situations where it makes sense — do it in this order.

Audit your active sites first

Open the SharePoint admin centre > Active sites. Filter by activity in the last 30 days. Customise columns to show page views, file counts, and last activity. Export the list to CSV. This is your starting inventory — the sites people actually use.

Review permissions on each candidate site

For every site you’re considering for the allowed list, open its details and check the Permissions tab. Look for “Everyone except external users” or company-wide groups. Those are the oversharing patterns you’re really worried about.

Enable RSS and build the allowed list

RSS is managed through PowerShell — there’s no toggle in the admin centre GUI for this one.

Set-SPOTenantRestrictedSearchMode -Mode Enabled
Add-SPOTenantRestrictedSearchAllowedList -SitesList @("https://contoso.sharepoint.com/sites/intranet","https://contoso.sharepoint.com/sites/hr")

Notice what’s missing? A portal button. That’s deliberate. Microsoft wants friction here because they don’t want you to leave this on.

Plan your exit from day one

Before you enable RSS, set a calendar reminder for 30 days out. That’s your deadline to fix the permissions that made you turn it on in the first place — and then turn it off.

When RSS backfires

Here’s where most people get into trouble. They enable RSS, breathe a sigh of relief, and forget about it. Months later, three things have gone wrong:

Search breaks for everyone. RSS doesn’t just limit Copilot — it limits all organisation-wide search. Your finance team can’t find the policy site. Your HR team can’t find the onboarding hub. Nobody told them you turned this on, so they log a ticket blaming SharePoint.

Copilot gets dumber. With only 100 sites to draw from, Copilot has less information to reference. Answers get vague. Users lose trust. You’ve just paid for Copilot licences and then blindfolded the thing.

False confidence sets in. The admin thinks the problem is solved. It isn’t. RSS doesn’t stop Copilot from surfacing content a user has already accessed. If someone opened that sensitive spreadsheet last week, Copilot can still reference it — allowed list or not.

The actual fix: permissions, not curtains

RSS buys you time. Use it. But spend that time on the thing that actually matters: fixing your SharePoint permissions.

Start with Data Access Governance reports in SharePoint Advanced Management. These reports show you exactly which sites have broad sharing, “Everyone” links, or sensitivity labels missing. That’s your real oversharing map.

Then work through it site by site. Remove company-wide sharing links. Tighten group memberships. Apply sensitivity labels where they belong. This is the work that actually makes Copilot safe — not hiding sites from search and hoping for the best.

Once permissions are clean, disable RSS. Let Copilot use the full breadth of your tenant. That’s how you get value from it.

“We turned on RSS six months ago and Copilot still isn’t helpful.”

That’s not a Copilot problem. That’s an RSS problem.

My recommendation?

Use RSS if you’re deploying Copilot to a tenant you haven’t audited yet and you need breathing room. Thirty days. Not six months. Not “until we get to it.”

Set the allowed list. Fix the permissions behind the scenes. Then take the training wheels off.

If you’re an MSP and you’re not walking clients through this sequence — temporary RSS, permission remediation, RSS removal — you’re either leaving them exposed or leaving them hobbled. Neither looks good at renewal time.

RSS isn’t there to protect your tenant. It’s there to give you a window to actually protect your tenant. Don’t confuse the window with the wall.

What Copilot Chat Developer Mode Actually Shows You

I spent a solid hour last month watching a declarative agent ignore an API plugin I’d wired up. The instructions were clear, the manifest looked right, the OpenAPI spec was valid. Every prompt came back with a confident answer that had nothing to do with my data. Copilot was making things up rather than calling my endpoint, and I had no idea why.

Then I typed -developer on into Copilot Chat, and the mystery evaporated in about thirty seconds.

Seeing the Orchestrator Think

Developer mode is a built-in debugging tool in Microsoft 365 Copilot Chat. Type that command and every response from your agent comes back with a debug card — a detailed breakdown of what the orchestrator did behind the scenes to produce its answer.

The card shows three things that matter. First, agent metadata and capabilities: which knowledge sources are active, whether web search is enabled, and the identifiers you need for tracking a specific conversation. Second, function matching: did the orchestrator consider your API plugin’s functions relevant to the user’s prompt? Third, execution details: if a function was selected, what HTTP request did Copilot actually send, what response came back, and how long did it take?

That last section is where most of the debugging value lives. You can see the endpoint that was called, the request headers with auth tokens redacted, and the full response body. When something fails, you’re reading the receipt — not guessing.

The Problem It Actually Solves

Before developer mode, troubleshooting a misbehaving agent in Copilot meant staring at manifest files trying to work out what went sideways. Your agent returned a wrong answer and you couldn’t tell where the chain broke. Was the orchestrator not matching your function? Matching but failing on auth? Getting bad data back from the API? The orchestration layer was a black box.

Now you see exactly where it breaks. In my case, the debug card showed “No matched functions” — meaning the orchestrator never even considered calling my API. The problem wasn’t auth or endpoints or response formatting. It was my description_for_model field. The description said “Returns project data” but my prompt asked “What’s the status of the Henderson build?” The orchestrator couldn’t bridge that semantic gap.

I rewrote the description to cover the ways people actually ask about project status, and the next prompt hit the API cleanly.

Where It Fits in Your Workflow

Developer mode works directly in the browser. Open Copilot Chat, select your agent, type -developer on, and start testing prompts. If you’re using the Microsoft 365 Agents Toolkit in Visual Studio Code, press F5 to launch your agent and the same command activates in the chat window. The debug panel in the toolkit gives you a matching view with downloadable diagnostic logs.

A couple of patterns worth knowing: when the debug card shows “No functions selected for execution,” your function descriptions likely aren’t semantically close enough to the prompt. When it shows a function was selected but execution failed, the HTTP status code in the card usually tells you what went wrong — a 401 means your OAuth registration doesn’t match, a timeout means your API needs to respond faster.

What I’m Watching

Microsoft keeps expanding what the debug card reveals, and the Quick Copy feature now lets you export the full debugging JSON to share with a colleague or attach to a support ticket. For anyone building agents that connect to external APIs through Copilot, this is the single most useful diagnostic tool in the stack. It turns “something’s broken” into “here’s exactly what happened, and here’s why.”

If you haven’t typed -developer on yet, start there.

Microsoft Learn — Test and debug agents using Developer Mode https://learn.microsoft.com/en-us/microsoft-365/copilot/extensibility/debugging-agents-copilot-studio(opens in new window) The primary documentation page. Covers enabling/disabling developer mode, the debug info card fields, troubleshooting common failures, and how to report issues.
Microsoft Learn — Test and debug agents in Microsoft 365 Agents Toolkit using developer mode https://learn.microsoft.com/en-us/microsoft-365/copilot/extensibility/debugging-agents-vscode(opens in new window) Focuses on using developer mode alongside the Agents Toolkit in VS Code (F5 launch, debug panel, diagnostic logs).
Microsoft 365 Developer Blog — Introducing the agent debugging experience in Microsoft 365 Copilot (April 9, 2025) https://devblogs.microsoft.com/microsoft365dev/introducing-the-agent-debugging-experience-in-microsoft-365-copilot/(opens in new window) The GA announcement post by Carol Mbasinge Kigoonya. Covers new features including agent configuration insights, execution monitoring, latency tracking, and Quick Copy Debugging JSON.
Microsoft 365 Roadmap — Feature ID 474450 https://www.microsoft.com/microsoft-365/roadmap?featureid=474450(opens in new window) The original roadmap entry for Copilot Chat developer mode, listed as GA from January 2025.
Microsoft Learn — Set up your development environment for Microsoft 365 Copilot https://learn.microsoft.com/en-us/microsoft-365/copilot/extensibility/prerequisites(opens in new window) Broader context on the Copilot development environment, licensing, and extensibility options that developer mode supports.