Authorization and Governance for AI Agents: Runtime Authorization Beyond Identity at Scale
Designing Authorization‑Aware AI Agents at Scale Enforcing Runtime RBAC + ABAC with Approval Injection (JIT) Microsoft Entra Agent Identity enables organizations to govern and manage AI agent identities in Copilot Studio, improving visibility and identity-level control. However, as enterprises deploy multiple autonomous AI agents, identity and OAuth permissions alone cannot answer a more critical question: “Should this action be executed now, by this agent, for this user, under the current business and regulatory context?” This post introduces a reusable Authorization Fabric—combining a Policy Enforcement Point (PEP) and Policy Decision Point (PDP)—implemented as a Microsoft Entra‑protected endpoint using Azure Functions/App Service authentication. Every AI agent (Copilot Studio or AI Foundry/Semantic Kernel) calls this fabric before tool execution, receiving a deterministic runtime decision: ALLOW / DENY / REQUIRE_APPROVAL / MASK Who this is for Anyone building AI agents (Copilot Studio, AI Foundry/Semantic Kernel) that call tools, workflows, or APIs Organizations scaling to multiple agents and needing consistent runtime controls Teams operating in regulated or security‑sensitive environments, where decisions must be deterministic and auditable Why a V2? Identity is necessary—runtime authorization is missing Entra Agent Identity (preview) integrates Copilot Studio agents with Microsoft Entra so that newly created agents automatically get an Entra agent identity, manageable in the Entra admin center, and identity activity is logged in Entra. That solves who the agent is and improves identity governance visibility. But multi-agent deployments introduce a new risk class: Autonomous execution sprawl — many agents, operating with delegated privileges, invoking the same backends independently. OAuth and API permissions answer “can the agent call this API?” They do not answer “should the agent execute this action under business policy, compliance constraints, data boundaries, and approval thresholds?” This is where a runtime authorization decision plane becomes essential. The pattern: Microsoft Entra‑Protected Authorization Fabric (PEP + PDP) Instead of embedding RBAC logic independently inside every agent, use a shared fabric: PEP (Policy Enforcement Point): Gatekeeper invoked before any tool/action PDP (Policy Decision Point): Evaluates RBAC + ABAC + approval policies Decision output: ALLOW / DENY / REQUIRE_APPROVAL / MASK This Authorization Fabric functions as a shared enterprise control plane, decoupling authorization logic from individual agents and enforcing policies consistently across all autonomous execution paths. Architecture (POC reference architecture) Use a single runtime decision plane that sits between agents and tools. What’s important here Every agent (Copilot Studio or AI Foundry/SK) calls the Authorization Fabric API first The fabric is a protected endpoint (Microsoft Entra‑protected endpoint required) Tools (Graph/ERP/CRM/custom APIs) are invoked only after an ALLOW decision (or approval) Trust boundaries enforced by this architecture Agents never call business tools directly without a prior authorization decision The Authorization Fabric validates caller identity via Microsoft Entra Authorization decisions are centralized, consistent, and auditable Approval workflows act as a runtime “break-glass” control for high-impact actions This ensures identity, intent, and execution are independently enforced, rather than implicitly trusted. Runtime flow (Decision → Approval → Execution) Here is the runtime sequence as a simple flow (you can keep your Mermaid diagram too). ```mermaid flowchart TD START(["START"]) --> S1["[1] User Request"] S1 --> S2["[2] Agent Extracts Intent\n(action, resource, attributes)"] S2 --> S3["[3] Call /authorize\n(Entra protected)"] S3 --> S4 subgraph S4["[4] PDP Evaluation"] ABAC["ABAC: Tenant · Region · Data Sensitivity"] RBAC["RBAC: Entitlement Check"] Threshold["Approval Threshold"] ABAC --> RBAC --> Threshold end S4 --> Decision{"[5] Decision?"} Decision -->|"ALLOW"| Exec["Execute Tool / API"] Decision -->|"MASK"| Masked["Execute with Masked Data"] Decision -->|"DENY"| Block["Block Request"] Decision -->|"REQUIRE_APPROVAL"| Approve{"[6] Approval Flow"} Approve -->|"Approved"| Exec Approve -->|"Rejected"| Block Exec --> Audit["[7] Audit & Telemetry"] Masked --> Audit Block --> Audit Audit --> ENDNODE(["END"]) style START fill:#4A90D9,stroke:#333,color:#fff style ENDNODE fill:#4A90D9,stroke:#333,color:#fff style S1 fill:#5B5FC7,stroke:#333,color:#fff style S2 fill:#5B5FC7,stroke:#333,color:#fff style S3 fill:#E8A838,stroke:#333,color:#fff style S4 fill:#FFF3E0,stroke:#E8A838,stroke-width:2px style ABAC fill:#FCE4B2,stroke:#999 style RBAC fill:#FCE4B2,stroke:#999 style Threshold fill:#FCE4B2,stroke:#999 style Decision fill:#fff,stroke:#333 style Exec fill:#2ECC71,stroke:#333,color:#fff style Masked fill:#27AE60,stroke:#333,color:#fff style Block fill:#C0392B,stroke:#333,color:#fff style Approve fill:#F39C12,stroke:#333,color:#fff style Audit fill:#3498DB,stroke:#333,color:#fff ``` Design principle: No tool execution occurs until the Authorization Fabric returns ALLOW or REQUIRE_APPROVAL is satisfied via an approval workflow. Where Power Automate fits (important for readers) In most Copilot Studio implementations, Agents calls Power Automate (agent flows), is the practical integration layer that calls enterprise services and APIs. Copilot Studio supports “agent flows” as a way to extend agent capabilities with low-code workflows. For this pattern, Power Automate typically: acquires/uses the right identity context for the call (depending on your tenant setup), and calls the /authorize endpoint of the Authorization Fabric, returns the decision payload to the agent for branching. Copilot Studio also supports calling REST endpoints directly using the HTTP Request node, including passing headers such as Authorization: Bearer <token>. Protected endpoint only: Securing the Authorization Fabric with Microsoft Entra For this V2 pattern, the Authorization Fabric must be protected using Microsoft Entra‑protected endpoint on Azure Functions/App Service (built‑in auth). Microsoft Learn provides the configuration guidance for enabling Microsoft Entra as the authentication provider for Azure App Service / Azure Functions. Step 1 — Create the Authorization Fabric API (Azure Function) Expose an authorization endpoint: HTTP Step 2 — Enable Microsoft Entra‑protected endpoint on the Function App In Azure Portal: Function App → Authentication Add identity provider → Microsoft Choose Workforce configuration (enterprise tenant) Set Require authentication for all requests This ensures the Authorization Fabric is not callable without a valid Entra token. Step 3 — Optional hardening (recommended) Depending on enterprise posture, layer: IP restrictions / Private endpoints APIM in front of the Function for rate limiting, request normalization, centralized logging (For a POC, keep it minimal—add hardening incrementally.) Externalizing policy (so governance scales) To make this pattern reusable across multiple agents, policies should not be hardcoded inside each agent. Instead, store policy definitions in a central policy store such as Cosmos DB (or equivalent configuration store), and have the PDP load/evaluate policies at runtime. Why this matters: Policy changes apply across all agents instantly (no agent republish) Central governance + versioning + rollback becomes possible Audit and reporting become consistent across environments (For the POC, a single JSON document per policy pack in Cosmos DB is sufficient. For production, add versioning and staged rollout.) Store one PolicyPack JSON document per environment (dev/test/prod). Include version, effectiveFrom, priority for safe rollout/rollback. Minimal decision contract (standard request / response) To keep the fabric reusable across agents, standardize the request payload. Request payload (example) Decision response (deterministic) Example scenario (1 minute to understand) Scenario: A user asks a Finance agent to create a Purchase Order for 70,000. Even if the user has API permission and the agent can technically call the ERP API, runtime policy should return: REQUIRE_APPROVAL (threshold exceeded) trigger an approval workflow execute only after approval is granted This is the difference between API access and authorized business execution. Sample Policy Model (RBAC + ABAC + Approval) This POC policy model intentionally stays simple while demonstrating both coarse and fine-grained governance. 1) Coarse‑grained RBAC (roles → actions) FinanceAnalyst CreatePO up to 50,000 ViewVendor FinanceManager CreatePO up to 100,000 and/or approve higher spend 2) Fine‑grained ABAC (conditions at runtime) ABAC evaluates context such as region, classification, tenant boundary, and risk: 3) Approval injection (Agent‑level JIT execution) For higher-risk/high-impact actions, the fabric returns REQUIRE_APPROVAL rather than hard deny (when appropriate): How policies should be evaluated (deterministic order) To ensure predictable and auditable behavior, evaluate in a deterministic order: Tenant isolation & residency (ABAC hard deny first) Classification rules (deny or mask) RBAC entitlement validation Threshold/risk evaluation Approval injection (JIT step-up) This prevents approval workflows from bypassing foundational security boundaries such as tenant isolation or data sovereignty. Copilot Studio integration (enforcing runtime authorization) Copilot Studio can call external REST APIs using the HTTP Request node, including passing headers such as Authorization: Bearer <token> and binding response schema for branching logic. Copilot Studio also supports using flows with agents (“agent flows”) to extend capabilities and orchestrate actions. Option A (Recommended): Copilot Studio → Agent Flow (Power Automate) → Authorization Fabric Why: Flows are a practical place to handle token acquisition patterns, approval orchestration, and standardized logging. Topic flow: Extract user intent + parameters Call an agent flow that: calls /authorize returns decision payload Branch in the topic: If ALLOW → proceed to tool call If REQUIRE_APPROVAL → trigger approval flow; proceed only if approved If DENY → stop and explain policy reason Important: Tool execution must never be reachable through an alternate topic path that bypasses the authorization check. Option B: Direct HTTP Request node to Authorization Fabric Use the Send HTTP request node to call the authorization endpoint and branch using the response schema. This approach is clean, but token acquisition and secure secretless authentication are often simpler when handled via a managed integration layer (flow + connector). AI Foundry / Semantic Kernel integration (tool invocation gate) For Foundry/SK agents, the integration point is before tool execution. Semantic Kernel supports Azure AI agent patterns and tool integration, making it a natural place to enforce a pre-tool authorization check. Pseudo-pattern: Agent extracts intent + context Calls Authorization Fabric Enforces decision Executes tool only when allowed (or after approval) Telemetry & audit (what Security Architects will ask for) Even the best policy engine is incomplete without audit trails. At minimum, log: agentId, userUPN, action, resource decision + reason + policyIds approval outcome (if any) correlationId for downstream tool execution Why it matters: you now have a defensible answer to: “Why did an autonomous agent execute this action?” Security signal bonus: Denials, unusual approval rates, and repeated policy mismatches can also indicate prompt injection attempts, mis-scoped agents, or governance drift. What this enables (and why it scales) With a shared Authorization Fabric: Avoid duplicating authorization logic across agents Standardize decisions across Copilot Studio + Foundry agents Update governance once (policy change) and apply everywhere Make autonomy safer without blocking productivity Closing: Identity gets you who. Runtime authorization gets you whether/when/how. Copilot Studio can automatically create Entra agent identities (preview), improving identity governance and visibility for agents. But safe autonomy requires a runtime decision plane. Securing that plane as an Entra-protected endpoint is foundational for enterprise deployments. In enterprise environments, autonomous execution without runtime authorization is equivalent to privileged access without PIM—powerful, fast, and operationally risky.How to Configure DLP Policies for Copilot-Generated Content
Artificial Intelligence has rapidly transformed workplace productivity, and Microsoft Copilot is leading this transformation by helping users generate documents, emails, presentations, reports, code, and more within the Microsoft 365 ecosystem. While these AI-powered capabilities significantly improve efficiency, they also introduce new security and compliance challenges. https://dellenny.com/how-to-configure-dlp-policies-for-copilot-generated-content-a-practical-guide-for-secure-ai-adoption/Sensitivity Auto-labelling via Document Property
Why is this needed? Sensitivity labels are generally relevant within an organisation only. If a file is labelled within one environment and then moved to another environment, sensitivity label content markings may be visible, but by default, the applied sensitivity label will not be understood. This can lead to scenarios where information that has been generated externally is not adequately protected. My favourite analogy for these scenarios is to consider the parallels between receiving sensitive information and unpacking groceries. When unpacking groceries, you might sit your grocery bag on a counter or on the floor next to the pantry. You’ll likely then unpack each item, take a look at it and then decide where to place it. Without looking at an item to determine its correct location, you might place it in the wrong location. Porridge might be safe from the kids on the bottom shelf. If you place items that need to be protected, such as chocolate, on the bottom shelf, it’s not likely to last very long. So, I affectionately refer to information that hasn’t been evaluated as ‘porridge’, as until it has been checked, it will end up on the bottom shelf of the pantry where it is quite accessible. Label-based security controls, such as Data Loss Prevention (DLP) policies using conditions of ‘content contains sensitivity label’ will not apply to these items. To ensure the security of any contained sensitive information, we should look for potential clues to its sensitivity and then utilize these clues to ensure that the contained information is adequately protected - We take a closer look at the ‘porridge’, determine whether it’s an item that needs protection and if so, move it to a higher shelf in the pantry so that it’s out of reach for the kids. Effective use of Purview revolves around the use of ‘know your data’ strategies. We should be using as many methods as possible to try to determine the sensitivity of items. This can include the use of Sensitive Information Types (SITs) containing keyword or pattern-based classifiers, trainable classifiers, Exact Data Match, Document fingerprinting, etc. Matching items via SITs present in the items content can be problematic due to false positives. Keywords like ‘Sensitive’ or ‘Protected’ may be mentioned out of context, such as when referring to a classification or an environment. When classifications have been stamped via a property, it allows us to match via context rather than content. We don’t need to guess at an item’s sensitivity if another system has already established what the item’s classification is. These methods are much less prone to false positives. Why isn’t everyone doing this? Document properties are often not considered in Purview deployments. SharePoint metadata management seems to be a dying artform and most compliance or security resources completing Purview configurations don’t have this skill set. There’s also a lack of understanding of the relevance of checking for item properties. Microsoft haven’t helped as the documentation in this space is somewhat lacking and needs to be unpicked via some aligning DLP guidance (Create a DLP policy to protect documents with FCI or other properties). Many of these configurations will also be tied to regional requirements. Document properties being used by systems where I’m from, in Australia, will likely be very different to those used in other parts of the world. In the following sections, we’ll take a look at applicable use cases and walk through how to enable these configurations. Scenarios for use Labelling via document property isn’t for everyone. If your organisation is new to classification or you don’t have external partners that you collaborate with at higher sensitivity levels, then this likely isn’t for you. For those that collaborate heavily and have a shared classification framework, as is often seen across government, this is a must! This approach will also be highly relevant to multi-tenant organisations or conglomerates where information is regularly shared between environments. The following scenarios are examples of where this configuration will be relevant: 1. Migrating from 3 rd party classification tools If an item has been previously stamped by a 3 rd party classification tool, then evaluating its applied document properties will provide a clear picture of its security classification. These properties can then be used in service-based auto-labelling policies to effectively transition items from 3 rd party tools to Microsoft Purview sensitivity labels. As labels are applied to items, they will be brought into scope of label-based controls. 2. Detecting data spill Data spill is a term that is used to define situations where information that is of a higher than permitted security classification land in an environment. Consider a Microsoft 365 tenant that is approved for the storage of Official information but Top Secret files are uploaded to it. Document properties that align with higher than permitted classifications provide us with an almost guaranteed method of identifying spilled items. Pairing this document property with an auto-labelling policy allows for the application of encryption to lock unauthorized users out of the items. Tools like Content Explorer and eDiscovery can then be used to easily perform cleanup activities. If using document properties and auto-labelling for this purpose, keep in mind that you’ll need to create sensitivity labels for higher than permitted classifications in order to catch spilled items. These labels won’t impact usability as you won’t publish them to users. You will, however, need to publish them to a single user or break glass account so that they’re not ignored by auto-labelling. 3. Blocking access by AI tools If your organization was concerned about items with certain properties applied being accessed by generative AI tools, such as Copilot, you could use Auto-labelling to apply a sensitivity label that restricts EXTRACT permissions. You can find some information on this at Microsoft 365 Copilot data protection architecture | Microsoft Learn. This should be relevant for spilled data, but might also be useful in situations where there are certain records that have been marked via properties and which should not be Copilot accessible. 4. External Microsoft Purview Configurations Sensitivity labels are relevant internally only. A label, in its raw form, is essentially a piece of metadata with an ID (or GUID) that we stamp on pieces of information. These GUIDs are understood by your tenant only. If an item marked with a GUID shows up in another Microsoft 365 tenant, the GUID won’t correspond with any of that tenant’s labels or label-based controls. The art in Microsoft Purview lies in interpreting the sensitivity of items based on content markings and other identifiers, so that data security can be maintained. Document properties applied by Purview, such as ClassificationContentMarkingHeaderText are not relevant to a specific tenant, which makes them portable. We can use these properties to help maintain classifications as items move between environments. 5. Utilizing metadata applied by Records Management solutions Some EDRMS, Records or Content Management solutions will apply properties to items. If an item has been previously managed and then stamped with properties, potentially including a security classification, via one of these systems, we could use this information to inform sensitivity label application. 6. 3 rd party classification tools used externally Even if your organisation hasn’t been using 3rd party classification tools, you should consider that partner organisations, such as other Government departments, might be. Evaluating the properties applied by external organisations to items that you receive will allow you to extend protections to these items. If classification tools like Janus or Titus are used in your geography/industry, then you may want to consider checking for their properties. Regarding the use of auto-classification tools Some organisations, particularly those in Government, will have organisational policies that prevent the use of automatic classification capabilities. These policies are intended to ensure that each item is assessed by an actual person for risk of disclosure rather than via an automated service that could be prone to error. However, when auto-labelling is used to interpret and honour existing classifications, we are lowering rather than raising the risk profile. If the item’s existing classification (applied via property) is ignored, the item will be treated as porridge and is likely to be at risk. If auto-labelling is able to identify a high-risk item and apply the relevant label, it will then be within scope of Purview’s data security controls, including label-based DLP, groups and sites data out of place alerting, and potentially even item encryption. The outcome is that, through the use of auto-labelling, we are able to significantly reduce risk of inappropriate or unintended disclosure. Configuration Process Setting up document property-based auto-labelling is fairly straightforward. We need to setup a managed property and then utilize it an auto-labelling policy. Below, I've split this process into 6 steps: Step 1 – Prepare your files In order to make use of document properties, an item with the properties applied will first need to be indexed by SharePoint. SharePoint will record the properties as ‘crawled properties’, which we’ll then need to convert into ‘managed properties’ to make them useful. If you already have items with the relevant properties stored in SharePoint, then they are likely already indexed. If not, you’ll need to upload or create an item or items with the properties applied. For testing, you’ll want to create a file with each property/value combination so that you can confirm that your auto-labelling policies are all working correctly. This could require quite a few files depending on the number of properties you’re looking for. To kick off your crawled property generation though, you could create or upload a single file with the correct properties applied. For example: In the above, I’ve created properties for ClassificationContentMarkingHeaderText and ClassificationContentMarkingFooterText, which you’ll often see applied by Purview when an item has a sensitivity label content marking applied to it. I’ve also included properties to help identify items classified via JanusSeal, Titus and Objective. Step 2 – Index the files After creating or uploading your file, we then need SharePoint to index it. This should happen fairly quickly depending on the size of your environment. I'd expect to wait sometime between 10 minutes and 24 hrs. If you're not in a hurry, then I'd recommend just checking back the next day. You'll know when this has been completed when you head into SharePoint Admin > Search > Managed Search Schema > Crawled Properties and can find your newly indexed properties: Step 3 – Configure managed properties Next, the properties need to be configured as managed properties. To do this, go to SharePoint Admin > More features > Search > Managed Search Schema > Managed Properties. Create a new managed property and give it a name. Note that there are some character restrictions in naming, but you should be able to get it close to your document property name. Set the property’s type to text, select queryable and retrievable. Under ‘mappings to crawled properties’, choose add mapping, search for and select the property indexed from the file property. Note that the crawled property will have the same name as your document property, so there’s no need to browse through all of them: Repeat this so that you have a managed property for each document property that you want to look for. Step 4 – Configure Auto-labelling policies Next up, create some auto-labelling policies. You’ll need one for each label that you want to apply, not one per property as you can check multiple properties within the one auto-labelling policy. - From within Purview, head to Information Protection > Policies > Auto-labelling policies. - Create a new policy using the custom policy template. - Give your policy an appropriate name (e.g. Label PROTECTED via property). - Select the label that you want to apply (e.g. PROTECTED). - Select SharePoint based services (SharePoint and OneDrive). - Name your auto-labelling rules appropriately (e.g. SPO – Contains PROTECTED property) - Enter your conditions as a long string with property and value separated via a colon and multiple entries separated with a comma. For example: ClassificationContentMarkingHeaderText:PROTECTED,ClassificationContentMarkingFooterText:PROTECTED,Objective-Classification:PROTECTED,PMDisplay:PROTECTED,TitusSEC:PROTECTED Note that the properties that you are referencing are the Managed Property rather than the document property. This will be relevant if your managed property ended up having a different name due to character restrictions. After pasting in your string into the UI, the resultant rule should look something like this: When done, you can either leave your policy in simulation mode or save it and then turn it on from the auto-labelling policies screen. Just be aware of any potential impacts, such as accidently locking users out by automatically deploying a label with encryption configuration. You can reduce any potential impact by targeting your auto-labelling policy at a site or set of sites initially and then expanding its scope after testing. Step 5 - Test Testing your configuration will be as easy as uploading or creating a set of files with the relevant document properties in place. Once uploaded, you’ll need to give SharePoint some time to index the items and then the auto-labelling policy some time to apply sensitivity labels to them. To confirm label application, you can head to the document library where your test files are located and enable the sensitivity column. Files that have been auto-labelled will have their label listed: You could also check for auto-labelling activity in Purview via Activity explorer: Step 6 – Expand into DLP If you’ve spent the time setting up managed properties, then you really should consider capitalizing on them in your DLP configurations. DLP policy conditions can be configured in the same manner that we configured Auto-labelling in Step 3 above. The document property also gives us an anchor for DLP conditions that is independent of an item’s sensitivity label. You may wish to consider the following: DLP policies blocking external sharing of items with certain properties applied. This might be handy for situations where auto-labelling hasn’t yet labelled an item. DLP policies blocking the external sharing of items where the applied sensitivity label doesn’t match the applied document property. This could provide an indication of risky label downgrade. You could extend such policies into Insider Risk Management (IRM) by creating IRM policies that are aligned with the above DLP policies. This will allow for document properties to be considered in user risk calculation, which can inform controls like Adaptive Protection. Here's an example of a policy from the DLP rule summary screen that shows conditions of item contains a label or one of our configured document properties: Thanks for reading and I hope this article has been of use. If you have any questions or feedback, please feel free to reach out.Transitioning from Microsoft 365 Business Premium to Business Basic: What Nonprofits Need to Know
As Microsoft begins transitioning out the Business Premium grant for nonprofits, many organizations are reassessing their licensing needs therefore this is an opportunity to streamline operations and continue leveraging powerful tools with Microsoft 365 Business Basic. _____________________________________________________________________________________________________ What Is Microsoft 365 Business Basic? Microsoft 365 Business Basic is a cloud-first productivity suite designed for organizations that don’t need desktop Office apps but still want access to essential collaboration and communication tools. It includes: ✅Web and mobile versions of Word, Excel, PowerPoint, and Outlook ✅Microsoft Teams for meetings, chat, and collaboration ✅Exchange Online with a 50 GB mailbox per user ✅OneDrive for Business with 1 TB of cloud storage ✅SharePoint Online for document management and team sites It’s a cost-effective solution for nonprofits looking to maintain productivity while reducing licensing expenses. __________________________________________________________________________________________________ The Change Microsoft has announced the retirement of the Business Premium grant, which previously provided eligible nonprofits with free access to premium features like desktop Office apps, Intune, and advanced security tools. As a result, many organizations are now exploring Business Basic as a cost-effective alternative. Note: If your organization decides to continue using Microsoft 365 Business Premium, you may be eligible for a discount of up to 75% through Microsoft’s nonprofit pricing. This can be a great option if you still need access to advanced features. ______________________________________________________________________________________________________ How to Transition from Business Premium to Business Basic Here’s a step-by-step guide to help you make the switch smoothly: Step 1: Evaluate Your Current Usage Identify users who don’t need desktop apps or advanced security features. Use the Microsoft 365 admin center to review license assignments and usage patterns. Step 2: Purchase Business Basic Licenses Go to Microsoft 365 admin center > Billing > Purchase services. Select “Details” next to Microsoft 365 Business Basic and buy the number of licenses you need. Important: Although the process says “purchase,” eligible nonprofits receive the first 300 Business Basic licenses for free. You will not be charged for these licenses, even though they are added through the purchase flow. Step 3: Reassign Licenses Navigate to Users > Active users. For each user, go to Licenses and Apps, uncheck Business Premium, and check Business Basic. Save your changes. Step 4: Remove Unused Premium Licenses Once all users are reassigned, reduce or cancel your Business Premium licenses to avoid unnecessary charges. Go to Billing > Your Products Click on Microsoft 365 Business Premium, then click remove licenses Ensure that users have been unassigned licenses or that may cause an error Step 5: Communicate the Transition Let your team know what’s changing and what tools they’ll still have access to. Offer training or resources to help them adapt to web-based tools. ______________________________________________________________________________________________________ Business Premium vs Business Basic Comparison Feature Business Premium Business Basic Desktop versions of Office apps (Word, Excel, PowerPoint, Outlook, etc.) ✅ ❌ Advanced security features (Microsoft Defender for Business, Microsoft Purview) ✅ ❌ Device management (via Microsoft Intune) ✅ ❌ Access and Publisher (PC only) ✅ ❌ Webinar hosting and attendee tools in Teams ✅ ❌ ______________________________________________________________________________________________________ What You’ll Still Have with Business Basic Despite the changes, you’ll retain access to essential tools that support collaboration and productivity: Web and mobile versions of Office apps Microsoft Teams (chat, call, meet with up to 300 attendees) Business-class email with Exchange 1 TB of OneDrive cloud storage SharePoint Standard security and support ______________________________________________________________________________________________________ Making the Most of Microsoft 365 Business Basic Even without desktop apps, Business Basic offers a robust suite of tools to keep your team connected and productive: ✅ Web-Based Office Apps Use Word, Excel, PowerPoint, and Outlook directly in your browser. Collaborate in real-time with colleagues on shared documents. ✅ Microsoft Teams Host virtual meetings, chat, and collaborate on files. Create channels for departments or projects to streamline communication. ✅ OneDrive and SharePoint Store and share files securely in the cloud. Use version history and co-authoring to improve productivity. ✅ Email and Calendar Access professional email with a 50 GB mailbox via Outlook on the web. Manage calendars and schedule meetings with ease. ___________________________________________________________________________________________________ Final Thoughts While the retirement of the Business Premium grant may require some adjustments, Microsoft 365 Business Basic still provides essential tools to help your nonprofit thrive. With thoughtful planning and a focus on cloud-based collaboration, you can continue to operate efficiently and make a meaningful impact—without breaking your budget.Ultimate Polling and Quiz Experience with Polls app: The Replacement for Forms app in Teams meeting
Initially Forms app was launched in Teams - for different experiences based on the sync vs async user scenarios, as it points to polling experience in meetings for quick creation to launch, while it points to survey experience in the context of Teams channel.To provide an intuitive and easy-to-access experience , Polls app was launched - a dedicated app for all your polling and quiz needs in Teams meeting and chat. We are glad to see that hosting an effective and interactive meeting just got easier after the launch of Polls.
Need to Restore PST Files to Office 365 Mailboxes - What's the Best Approach
Hey everyone, I have a task coming up where I need to restore several PST files back into Office 365 mailboxes. Haven't done this before at this scale and honestly not sure where to begin. I've looked at Microsoft's native import service through Purview but I have a few concerns: Some of the PST files are quite large — not sure how well it handles that I need to restore only specific folders for some users, not the entire PST I'm worried about data consistency after the restore Would prefer something that doesn't require too many admin roles or complex setup For those who have done PST to Office 365 restores — what approach worked best for you? Any tools, tips, or things to watch out for that you wish you knew before starting?Microsoft Teams Meeting Controls: July 2026 M365 Champions Community call
Hello Champions! Here’s a recap and top Q+A from our July M365 Champions monthly call of 2026. We kicked off the call annoucing a new Champion Stories program to showcase real-world Microsoft 365 Copilot adoption success stories from the Champions community. Organizations that have successfully introduced or scaled Copilot are invited to share their journey, lessons learned, and best practices. Selected stories will be professionally filmed and published to help other Champions learn from peer experiences. Submit your story at aka.ms/ChampionStory. This month's main topic featured the redesigned Microsoft Teams meeting controls with Michelle Maislen, Principal Product Manager and Ryan Miller, UX Researcher from the Microsoft Teams product group. She explained that the redesign was driven by customer feedback around cluttered meeting controls, accidental clicks, and difficulty finding key features. The new experience introduces a cleaner, more organized toolbar with mic, camera, and share controls prioritized, separates the Share and Leave buttons to prevent accidental exits, moves advanced features into a structured “More” menu, and allows users to customize their meeting controls through drag-and-drop pinning. She acknowledged that changes such as moving Raise Hand under Reactions may be polarizing, but emphasized that users can personalize the toolbar to fit their workflow. Michelle also detailed the phased rollout plan, with users receiving opportunities to opt in before automatic migration, and shared that the redesign will extend across meetings, webinars, and town halls. Throughout the discussion and Q&A, she reinforced that the goal is to create a simpler, more intuitive, and highly customizable Teams meeting experience while preserving access to all existing meeting functionality. Click here to learn more about the Teams Meeting Controls redesign. Q+A from this month's session: 1. When will the new Teams Meeting Controls reach General Availability (GA)? Answer: Microsoft expects the redesigned meeting controls to roll out worldwide in September 2026, following preview validation and user feedback. 2. How does the 20-day rollout experience work? Answer: Users will receive several opportunities to opt in to the new experience. After approximately 20 days, they will be automatically migrated. 3. Can users switch back to the old meeting controls? Answer: Yes. A temporary toggle allows users to switch back to the old experience, although Microsoft plans to remove this option in the future. 4. Why was Raise Hand moved under Reactions? Answer: Research showed users frequently clicked the wrong button when Raise Hand and Reactions were adjacent. Moving Raise Hand under Reactions reduces accidental clicks. 5. Can users move Raise Hand back to the main toolbar? Answer: Yes. Users can drag and pin Raise Hand to the main toolbar if they prefer it there. 6. Can users customize the meeting toolbar? Answer: Yes. Most controls can be pinned, unpinned, and rearranged using drag-and-drop customization. 7. Which controls cannot be moved? Answer: Microphone, Camera, Share, and Leave remain fixed to ensure a consistent core meeting experience. 8. Will toolbar customizations persist between meetings? Answer: Yes. Customizations persist across meetings on the same device. 9. Will toolbar settings sync across multiple devices? Answer: Not initially. Microsoft indicated multi-device synchronization is planned for a future update. 10. Can users pin specific reactions (such as Thumbs Up) to the toolbar? Answer: Not in the initial release. The team acknowledged the request and is considering expanded reaction customization. 11. Will Microsoft add more meeting reactions? Answer: Yes. The Teams team confirmed they're exploring expanded reaction sets and potentially custom organizational reactions. 12. Does the redesign apply to Webinars and Town Halls? Answer: Yes. The redesigned controls will be available across Teams meetings, webinars, and town halls. 13. Is the redesign available in both Teams Desktop and Teams Web? Answer: Yes. The redesigned controls are supported in the Desktop and Web clients. 14. Will Virtual Desktop Infrastructure (VDI) environments be supported? Answer: Yes. Microsoft confirmed support for VDI deployments. 15. Why redesign the meeting controls at all? Answer: The redesign addresses common pain points including: Toolbar clutter Difficulty locating controls Accidental clicks Confusion between Reactions and Raise Hand Accidentally clicking Leave instead of Share 16. Where did features like Notes, Rooms, Apps, Facilitator, and Captions go? Answer: These capabilities were not removed. They have been reorganized under the new More menu to create a cleaner primary toolbar. 17. What adoption and readiness resources are available? Answer: Microsoft published: An IT Pro Change Management Guide An End User Visual Guide Adoption content on adoption.microsoft.com These resources are designed to help organizations prepare users for the transition. 18. Is Microsoft addressing AI-related meeting security concerns? Answer: Yes. The Teams team is actively working on better visibility and notifications for: AI note-taking bots External recording tools Third-party meeting assistants 19. Can meeting actions and decisions automatically flow into other Agents or workflows? Answer: The question was raised by attendees, and Microsoft acknowledged the scenario as valuable feedback. No roadmap or confirmed functionality was announced. 20. Will Education (EDU), GCC, and other government environments receive the redesign? Answer: GCC is expected to receive the update roughly in line with worldwide rollout. GCCH and DoD environments are expected to follow later. EDU deployment details were still being validated during the session. Join us on September 22nd for our next community call. Haven't joined the program yet? It's free! Join here: https://aka.ms/M365Champion. Bring your questions to our discussion forum: https://aka.ms/DriveAdoption.
Microsoft Defender for Office 365 Blocks Prompt Injections
Microsoft Defender for Office 365 (MDO) can detect and quarantine email containing prompt injections. Shared mailboxes might need MDO Plan 2 licenses if they receive email from external domains. This requirement existed before MDO introduced Prompt Injection Protection, but the advent of the new capability is another reason to check mailbox licensing, especially if your tenant uses Copilot. We have a script to help! https://office365itpros.com/2026/08/04/microsoft-defender-prompt-injection/
Strange redirect when signing in - phishing?
I just restarted my Business Standard 365 license today and this afternoon got an email from email address removed for privacy reasons with the following content: But when I clicked on the 'Verify payment information' button I am redirected to a page with the following URL: https://admin.cloud.microsoft/Error/UnAuth?errorCode=100014 looking like this: This looks highly suspicious (Times New Roman font, URL with no top-level extension such as .com, unusual graphics). Is this legitimate or a phishing attempt? Now, when I try to login to admin.microsoft.com to check my account the same suspicious "Sign out and login with a different account" page pops up repeatedly.
