Seller verification Rejected at Employment step — no email received, no appeal (ID 94611890)
Our Partner (MAICPP) verification completed successfully on 31 Aug 2026 — contact, identity (Verified ID) and business all Verified (Partner ID 7113511, DIGITAL QAZAQSTAN LTD, UK company no. 17178943). The Developer/seller verification for the same legal entity (Seller ID 94611890) is closed as "Rejected — no appeals available", stuck at "Employment Verification — Pending Partner Action" with an estimated date of 06.09.2026 still showing. No verification email or action request was ever received at the primary contact (monitored, junk folder included), and the closed page shows no Fix now / appeal / upload control. Root cause we identified: the seller profile contained an outdated registered address. It has been corrected and now matches Companies House exactly (Office 393, Unit 5, 399-405 Oxford Street, Mayfair, London W1C 2BU). Business verification documents show "Provided". A fully prepared transactable professional service offer is blocked from publication only by this verification. Could a Community Manager please escalate this to the Partner Vetting team to reopen or reinitiate the seller verification?Security baseline for Microsoft Edge version 151
We are pleased to announce the enterprise-ready release of the security baseline for Microsoft Edge version 151! We have reviewed the settings in Microsoft Edge version 151 and updated our guidance with six new recommendations. We have also identified one additional setting that organizations should consider evaluating in their environments. A new Microsoft Edge security baseline package was just released to the Download Center. You can download the new package from the Security Compliance Toolkit. Enable Process Isolation (added) We are enforcing ‘Enable Process Isolation’ to help protect Microsoft Edge from unauthorized access, modification, and tampering by other applications running on the device. This setting strengthens browser process integrity and helps safeguard sensitive data used by Microsoft Edge. Organizations that encounter compatibility issues with software that depends on browser process injection should treat such configurations as exceptions requiring explicit risk acceptance and compatibility validation. Enable renderer in app container (added) We are enforcing the default and enabling ‘Enable renderer in app container’ to strengthen Microsoft Edge’s browser isolation protections by ensuring renderer processes run within the additional restrictions provided by AppContainer. This helps reduce the impact of browser-based attacks and limits the ability of exploited renderer processes to interact with system resources. Organizations that require this setting to be disabled due to incompatible software should treat such configurations as exceptions that require explicit risk acceptance. Enable the network service sandbox (added) We are enforcing the default and enabling ‘Enable the network service sandbox’ to ensure Microsoft Edge network-facing processes operate within sandbox isolation boundaries that help reduce the impact of exploitation and limit access to system resources. Because disabling the network service sandbox weakens a core browser security protection, organizations should treat any requirement to disable this setting as an exception scenario requiring explicit risk acceptance and compatibility validation. Configure browser process code integrity guard (added) We are enabling ‘Configure browser process code integrity guard setting’ with a value of ‘Enable code integrity guard enforcement in the browser process’. The setting strengthens protections against unauthorized code injection into Microsoft Edge browser processes. Some enterprise applications, extensions, accessibility tools, or security products may still rely on legacy injection techniques and require compatibility validation. We encourage organizations to fully test this setting in their environments and work with vendors to identify or remediate incompatible software. Enable Application Bound Encryption (added) We are enabling ‘Enable Application Bound Encryption’ to strengthen protections for browser-stored credentials, authentication tokens, and other sensitive data by binding encryption more closely to the browser process. This helps reduce the risk of unauthorized access to protected browser data by malware or other untrusted software. Because disabling this setting weakens an important protection boundary, organizations should treat any requirement to disable the feature as an exception requiring explicit risk review. Enhance the security state in Microsoft Edge (added) We are enabling ‘Enhance the security state in Microsoft Edge’ and configuring the setting to Balanced to provide additional protection against modern web-based attacks while maintaining compatibility for most enterprise users. In Balanced mode, Microsoft Edge applies additional mitigations such as disabling just-in-time (JIT) JavaScript compilation and enabling added operating system protections on processes used to load sites that users do not frequently visit, helping reduce the risk of memory-related vulnerabilities. Because these protections can introduce compatibility issues for some applications or workflows, organizations should validate critical business sites and applications during their normal testing process prior to broad deployment and configure exceptions as needed. Additional details can be found here. Configure Automatic HTTPS (worth considering) We previously released a blog discussing a new feature called Automatic HTTPS. This setting can automatically switch your connections to websites from HTTP to HTTPS on sites that are highly likely to support the more secure protocol. This option helps ensure that users' network traffic is more secure and less susceptible to SSL stripping attacks. The best part, the end user doesn’t get prompted, it just works! This new feature has two configuration options: Navigations delivered over HTTP are switched to HTTPS’ (UpgradeCapableDomains) and ‘All navigation delivered over HTTP are switched to HTTPS’ (AlwaysUpgrade). There are trade-offs for each configuration: the UpgradeCapableDomains option only upgrades to HTTPS if Microsoft believes the site is likely to work over HTTPS, and this setting is unavailable if you’ve disabled the ComponentUpdatesEnabled policy. The more secure AlwaysUpgrade option unconditionally updates all HTTP requests to HTTPS, which will result in a user-visible error page if the target site does not support HTTPS. We encourage organizations to consider implementing and testing Automatic HTTPS within their environment. Collectively, these changes continue our focus on strengthening browser isolation, sandboxing, process integrity, and protection of sensitive browser data while balancing enterprise compatibility requirements. Microsoft Edge version 151 introduced 4 new computer and user settings. We have included a spreadsheet listing the new settings in the release to make it easier for you to find them. As a friendly reminder, all available settings for Microsoft Edge are documented here, and all available settings for Microsoft Edge Update are documented here. Please continue to give us feedback through the Security Baseline Community or in comments on this post.Security Review for Microsoft Edge version 152
We have reviewed the new settings in Microsoft Edge version 152 and determined that there are no additional security settings that require enforcement. The Microsoft Edge version 151 security baseline continues to be our recommended configuration which can be downloaded from the Microsoft Security Compliance Toolkit. Microsoft Edge version 152 introduced 4 new Computer and User settings; we have included a spreadsheet listing the new settings to make it easier for you to find. Starting with version 152 Microsoft Edge is moving to a more frequent release cycle. To better align with the needs of the enterprise customers, the Microsoft Edge security baseline is expected to align with the Extended Stable Channel, which provides major feature updates on an eight-week cadence while continuing to receive security and quality updates between releases. This approach provides organizations with additional time to evaluate and deploy feature changes while ensuring security protections remain current. Why the change? Security baselines are intended to provide guidance for managing security relevant configuration settings, not to track every feature introduced in a browser release. With the move to a two-week release cadence, publishing baseline updates for every release would increase operational overhead while providing limited security benefit. The Extended Stable cadence offers a more practical balance for enterprise customers by allowing additional time for testing and evaluation, while continuing to receive security and critical fixes between major feature releases. By aligning with Extended Stable, we can update the baselines less frequently and focus on publishing them earlier in the release cycle, giving IT administrators more time to review and plan for upcoming changes. Our goal is to make security baseline adoption more predictable and easier to manage while continuing to provide timely security guidance. As a friendly reminder, all available settings for Microsoft Edge are documented here, and all available settings for Microsoft Edge Update are documented here. Please continue to give us feedback through the Security Baselines Discussion site or this post.
Enrollment blocked by trust evaluation (Ref 715-123160) — cannot open a support ticket, no workspace
I am trying to enroll in the Microsoft 365 and Copilot program to publish a Word add-in on AppSource. The enrollment is blocked with the "Microsoft runs on trust" message. It happened twice, on 7 August and 18 August 2026, with the same reference number — so the first block was apparently never cleared. Reference number: 715-123160 Transaction ID (18 Aug): 05e34bf1-3406-4d55-abce-260567e369af Transaction ID (7 Aug): b809228d-bdec-436d-a205-de4914cef0e0 Correlation ID: c0187e32-891c-4c53-9964-cc5c9c6a1a17 I cannot open a support ticket: the Partner Center form requires selecting a Workspace, and my account has none because no enrollment ever completed. The public support form sends me back to Service health. Could this be escalated to the Vetting / Trust & Safety team for a manual review? My company registration number and official registration extract are ready — I will provide them privately on request. Thank you.
How much of your Microsoft 365 environment can you actually see at once?
Not how many users you have. Not how many sites, teams, apps or flows you have. How much of it can you actually see connected together? I've been working across Microsoft 365 environments for a while, and I kept running into the same thing. There is no shortage of information. If anything, there is probably too much of it. Users, groups, permissions, SharePoint, Teams, Power Apps, Power Automate, Power BI, Dataverse, OneDrive, Exchange, Intune, licensing, configuration... It's all there. But when you're actually trying to understand how everything fits together, it can be a different story. You open one blade. Find something. Open another. Cross-check it. Go back. Open something else. Before long, you're jumping between different parts of the tenant trying to build the bigger picture in your head. And if you're working with larger environments, that gets difficult pretty quickly. The information isn't necessarily missing. The relationships between the information are what can be difficult to see. That got me thinking about a slightly different question: Instead of "where do I find this information?" "Show me what's connected to this." That's where VisibleState started. Start anywhere. Follow the connections. Imagine starting with a single user. Instead of seeing that user simply as a record with a list of properties, imagine being able to explore the relationships around them: User → Groups → SharePoint → Teams → Power Apps → Power Automate → Power BI → Dataverse → OneDrive → Exchange → Intune Then the questions become different: What does this user have access to? Is that access direct or coming through a group? What resources are connected to them? What depends on something they're associated with? Which licenses are involved? Are there relationships that look unusual? If something changes, what else might be affected? Those questions aren't necessarily about finding another piece of information. They're about putting information that already exists into context. A report can tell you that something exists. A connected view helps you understand what it is connected to. Illustrative example below — not a real customer environment. I'm not suggesting Microsoft 365 doesn't already give us this information Quite the opposite. Microsoft 365 already gives administrators an incredible amount of information and tooling. The thing I've been thinking about is what happens when you want to look across those boundaries. Sometimes I don't want another export. I don't want another list. I don't necessarily want another dashboard. I want to start with something I'm looking at and ask: "What's connected to this?" And then keep following the trail. That's the idea I'm exploring with VisibleState. The interesting part is what happens when you change the viewpoint The same relationships can be useful for completely different reasons. For example: Administrators may want to understand access, permissions and dependencies. Security and governance teams may want to find unusual relationships or exceptions. Compliance teams may need to understand who can access something and why. People managing multiple environments may want a consistent way to understand what's there without rebuilding the picture manually every time. Leadership may not need to see the graph at all. They may simply want to know what's important, what's exposed and what could be affected. It's still the same underlying environment. You're just looking at it from a different angle. And that's where I think things get interesting. Where I'm at with it VisibleState started as something I was building to make my own work easier. I was spending a lot of time investigating environments, tracing access and putting information together for reports. The individual tasks weren't necessarily difficult. It was the jumping between different places and reconstructing the bigger picture that took the time. So I started building something that would let me approach the environment through the relationships instead. It's grown quite a bit from where it started, and I'm continuing to build it. I'm not posting this as a product launch, and I'm not looking for people to sign up. I'm genuinely interested in whether the problem I'm seeing is familiar to other people working with Microsoft 365. So I'm curious... If you could start with any object in your Microsoft 365 environment and immediately see what it's connected to, where would you start? Would it be: Users and access Groups and permissions SharePoint and Teams Power Apps, Power Automate, Power BI and Dataverse Licensing and resources Governance and unusual relationships Something completely different Maybe you've already got a good way of doing this. Maybe you still find yourself jumping between different services and piecing things together manually. Or maybe I'm looking at the problem from the wrong direction. What's the one relationship in your Microsoft 365 environment that you wish you could see instantly?
How to properly redact a PDF?
I need to share a PDF that contains names, email addresses, and other confidential details that must be removed first. Simply placing black boxes over the text does not seem secure, since the original content may still be searchable, selectable, or recoverable, so I need a way to permanently redact a PDF. Because the document contains sensitive information, I would prefer not to upload it to an online tool. I’m looking for either a built-in option or professional third-party desktop software that can permanently redact both text and images while processing the file locally. It would also be useful to remove hidden information from a PDF before sharing, including comments, document metadata, and any other embedded details. What is the safest way to handle this, and how can I verify that a PDF is properly redacted before I send it?
URGENT: Blocked from Partner Center Enrollment ("Runs on trust") - Support portals inaccessible
Hello Microsoft Partner Community Team, I am urgently seeking assistance with an automated enrollment block. We are trying to register our business, Connect In Cloud Ltd (UK Companies House: 09550508), for the Microsoft AI Cloud Partner Program, but we have triggered the "Microsoft runs on trust" security block. I am completely unable to raise a standard support ticket because my Partner Center dashboard shows no active workspaces, meaning the support form will not allow me to submit a request. Furthermore, the standard business phone support lines drop the call after instructing me to use the broken portal. I need a moderator to please escalate this directly to the Vetting and Enrollment team so I can provide my business documentation, verify my identity, and have this block cleared. Here are my exact error details from the blocked screen: Error: Microsoft runs on trust... your request was blocked. Reference Number: 715-123160 Transaction ID: 4b89b272-50fe-4f37-8f5f-15f539cbaed0 Correlation ID: f13ebdd3-5d9d-4b45-a31d-0049e3489a11 Thank you in advance for your help in getting an internal support ticket opened for usDoes your Transport think it is Squeaky Lobster Day in your CountryOrRegion?
Today is the magical day when parents tell their tucked-in children the story of the Squeaky Lobster. So here's a Squeaky Lobster-ish post to celebrate the day. In Exchange 2007, we introduced transport rules – a powerful feature that allows you to inspect different parts of a message such as sender, recipient, subject and headers and take actions like rejecting a message, deleting it, redirecting it to another recipient, adding a message header or a disclaimer. In previous versions of Exchange, you would need to write a transport event sink to accomplish similar things. With an easy-to-use interface in the EMC , transport rules make such tasks as easy as creating Inbox rules (created by users using Outlook/ OWA ). Command-line jockeys can create and manage transport rules using *-TransportRule cmdlets from the Shell. More about transport rules in Understanding Transport Rules. In Exchange 2010, we added a number of new predicates (which are used to create conditions and exceptions), including the ability to inspect attachment content and predicates to evaluate Active Directory attributes of the sender or recipients. A complete list of predicates can be found in Transport Rule Predicates. Ability to inspect Active Directory attributes of the sender or recipients dramatically increases the number of things you can check and the type of rules you can create. For example, you can check if the sender or recipients are in the same department, report to the same manager, check if the sender is the recipients’ manager (or the other way round), check the sender's title, city, state or country, amongst other things. The list of supported attributes is included in the Predicate Properties table in Transport Rule Predicates, or you can also see them in the New Transport Rule and Edit Transport Rule wizards in the EMC . Evaluate the sender's country or region You can use the predicate to evaluate the sender's country. This can be useful in many scenarios - for example, applying a disclaimer to messages based on the sender's country. Important: When using Active Directory attributes to meet business requirements, you must have appropriate processes in place to ensure the necessary attributes are populated and up-to-date. You can add the country/region property to a user or contact using ADUC , the EMC , the Shell or by using LDAP utilities. If you use ADUC or EMC, you’re greeted with a nice little drop-down list to pick a country/region from. If you use the Shell, you must use the corresponding cmdlet to populate the CountryOrRegion property – Set-User for user accounts, Set-Contact for contacts. Fig 1: You can select a recipient’s country or region from recipient’s properties in EMC You need to create a rule to check if message sender is from a specified country – let’s continue with Germany as the example, to apply a disclaimer. You can use the when the sender’s properties contain specific words predicate from the New Transport Rule wizard in EMC to check the CountryOrRegion property. The predicate allows you to pick a supported property and you can type in a string to match. For example, if you’re trying to match senders from Germany, you instinctively type in Germany. Fig 2: Checking a sender CountryOrRegion property using a transport rule But the transport rule doesn’t fire on any messages sent by recipients from Germany! You check the rule in EMC – it says Germany. It’s spelt correctly, no typos. You use the Shell to retrieve the properties: (Get-TransportRule MyRule).Conditions | fl * The value correctly displays as Germany: Words : {countryorregion:Germany} Name : SenderAttributeContains Rank : 36 LinkedDisplayText : when the sender's properties contain specific words IsValid : True You check the recipient’s country property using the Shell. Get-User bsuneja | select cou* Squeaky Lobster! The value is Germany! Why wouldn't the rule fire? The CountryOrRegion Property Although the CountryOrRegion property displays the country’s name (think of it as a display name), what’s stored in the Country-Name attribute (ldapDisplayName: c) in the recipient object in Active Directory is the 2-letter ISO 3166-1 country/region identifier for the country. For Germany, it’s DE. The full list of ISO codes can be found in the ISO 3166-1 decoding table . (Update: A better-formatted list can be found in ISO 3166-1 on Wikipedia). Note: Active Directory objects also have two more attributes to identify country or region: 1) Country-Code (ldapDispla yName: countryCode), which corresponds to the ISO 3166-1 numeric code 2) Text-Country (ldapDisplayName: co), which is the country name. However, only the Country-Name attribute is replicated to the Global Catalog. Update the rule Armed with this information, you can fix the rule in EMC. Figure 3: Use the Edit Transport Rule wizard to update values for the CountryOrRegion property Or use this command from the Shell to update the SenderADAttributeContains predicate. Set-TransportRule MyRule –SenderADAttributeContains “CountryOrRegion:DE” Happy Squeaky Lobster Day! Bharat SunejaIn-Place eDiscovery and In-Place Hold in the New Exchange; Part II
In Part I of this post, we covered what’s new in In-Place eDiscovery in the new Exchange. In this post, let’s take a look at how the new Exchange retains data immutably. One of the first steps you must take when reasonable expectation of litigation exists or when served an eDiscovery request is to preserve messaging records so they can be produced when required. Before Exchange 2010, this was generally achieved using different methods, including archiving data to an external system, suspending automated deletion mechanism (such as Exchange’s Messaging Records Management), or in some cases - by instructing users to not delete records. Failure to preserve records required for litigation may expose your organization to legal and financial risk. In Exchange 2010 and Office 365, we introduced Litigation Hold to enable you to preserve messaging records. Litigation Hold is a mailbox property – placing a mailbox on litigation hold places all items in a mailbox on hold indefinitely (or until hold is removed), resulting in accumulation of a large volume of data – all of which may not be required to be preserved. In the new Exchange, you can use In-Place Hold to retain items immutably. In-Place Hold is integrated with In-Place eDiscovery, allowing you to perform both search and hold using the same interface and the same query parameters. You can use In-Place Hold in the following scenarios. Indefinite Hold: You can create an In-Place Hold without any query parameters and without a hold duration to hold all items in a mailbox indefinitely or until the hold is removed. This emulates the behavior of litigation hold. Query-Based Hold: Using In-Place Hold, you can create a search query and specify the source mailboxes and parameters such as keywords, senders and recipients, as well as start and end dates. You can also specify the type of items to search – email messages, calendar items such as meetings and appointments, tasks, notes, or Lync content archived in Exchange mailboxes. Time-Based Hold: Whereas Litigation Hold placed all mailbox contents on hold indefinitely or until you remove the hold, In-Place Hold allows you to specify a duration of time for which to hold items. The time is calculated based on the received date or the date the item was created in the mailbox (for items such as appointments, tasks and notes that are not sent/received). One of the more common feature requests in Exchange 2010 was to be able to specify a definite time period for which an item is retained. Whereas retention policies allow you to specify the email lifecycle and automatically delete items when the specified period is reached, they don’t guarantee retention for that period. In other words, you could specify items will be kept for a maximum of 7 years, but you couldn’t guarantee items won’t be deleted before that period by a user or a process. The commonly recommended workaround to meet this requirement was to use configure the Deleted Item Recovery period to the minimum period you want an item to be retained for. In this example, setting the deleted item retention period to 7 years means if a user deletes an item before 7 years, it is retained in the Recoverable Items folder for 7 years. However, the period for Deleted Item Retention is calculated from the date of deletion. If a user deletes an item after 6 years, it is retained for an additional 7 years in the Recoverable Items folder, resulting in a total retention period of 13 years. In others words, you can guarantee an item will be retained for a minimum of 7 years, but not the maximum retention period. In the new Exchange, when you create a time-based In-Place Hold, because the hold period is calculated from the item received/creation date, you can guarantee the item won’t be held beyond that period. You can combine a time-based In-Place Hold with a Retention Policy (that has a single default policy tag) to ensure items in the mailbox are deleted by the Managed Folder Assistant (MFA) after 7 years, and items deleted by a user or a process before that period are retained for at least the specified duration. You can also combine a query-based In-Place Hold with a time-based hold to preserved items matching query parameters for the specified period. You can also place a user on multiple holds - for example, when a mailbox may contain records pertaining to multiple cases or investigations. In-Place Hold & Permissions Like In-Place eDiscovery, In-Place Hold can be used by authorized users with delegated Discovery Management permission. However, there’s a slight twist. The Discovery Management role group is assigned the Mailbox Search and Litigation Hold management roles. The former allows an authorized user to create a mailbox search for In-Place eDiscovery and Hold. The latter actually allows you to place mailbox content on hold. If a user is only assigned the Litigation Hold role, for example by creating a custom role-based access control (RBAC) role group or via membership of a role group such as Organization Management that has the Litigation Hold role assigned, the user is able to use In-Place Hold - but only to place all mailbox content on hold. The user can’t specify query parameters. In other words, the user can’t create a query-based In-Place Hold. Creating an In-Place Hold Let’s go back to the query Robin created in Part I of this post. When creating the In-Place Hold, on the Mailboxes page Robin must select Specify mailboxes to search and select the mailboxes or distribution groups. If she selects Search all mailboxes, the option to place content on hold will not be available. You must specify mailboxes or distribution groups to place on hold. If you select Search all mailboxes, the option to place content on hold will not be available. Figure 1: To create an In-Place Hold, you must select Specify mailboxes to search Note: If you select a distribution group, the hold applies to mailbox users that are members of the group when the hold is created. On the Search query page, Robin can use the same query she used for the In-Place eDiscovery. Figure 2: Messages matching query parameters are preserved She can also select the message types to place on hold. Figure 3: You can specify the message types to hold or hold all message types Placing archived Lync content on hold If the new Lync is enabled to archive Instant Messaging and meeting content into the new Exchange, Lync content is archived in the user’s mailbox and automatically placed on hold. You need to configure OAuth authentication between Lync and Exchange to enable this. Additionally, the mailbox must be located on a Mailbox server in the new Exchange. On the In-Place Hold settings page, Robin selects the option to Place content matching the search query in selected mailboxes on hold. She can then select Hold indefinitely to hold content indefinitely (or until the In-Place Hold is removed or a mailbox is removed from the search). To hold items for a specific period, she can select Specify number of days to hold items relative to their received date and specify the number of days. Figure 4: You can specify a hold duration or hold items indefinitely It’s important to reiterate here that for the time-based hold, the duration is calculated from the date a message is received/created. How In-Place Hold Works Let’s take a look at what happens under the hood. When a user deletes a message, it goes to the Deleted Items folder. When the Deleted Items folder is emptied or messages are deleted from it, or the user uses Shift-Delete to delete a message, it is moved to the Recoverable Items\Deletes folder. Contents of this folder are exposed when the user uses Recover Deleted Items in Outlook or Outlook Web App. If the user doesn’t do anything, messages from the Deletes folder are purged when the Deleted Items Retention period configured for the mailbox database or the user expires. If the user deletes a message from this view, few things can happen: If Single Item Recovery is enabled for the mailbox, the item is moved to the Recoverable Items\Purges folder and retained until the deleted item retention period expires. This provides the administrator the capability to recover items without having to recover from backups. If the mailbox is placed on Litigation Hold, the items is moved to the Recoverable Items\Purges folder and retained until the hold is removed. If the mailbox is placed on an In-Place Hold, the item is moved to the Recoverable Items\DiscoveryHolds folder. Figure 5: Deleted items and original copies of modified items are preserved in the Recoverable Items folder of each mailbox When the MFA , a mailbox assistant that processes mailboxes and expires content, processes the mailbox, it checks if messages meet the query parameters of any In-Place Holds the user is placed on. This evaluation is done for up to 5 queries, beyond which all items are retained – emulating the same behavior as litigation hold. If the number of holds is brought below 5, the MFA again reverts to the query-based In-Place Hold behavior. When the In-Place Hold is removed, messages placed on hold are removed if they no longer match query parameters of any other In-Place Hold that the user may have been placed on. In-Place Hold and Immutability When talking about preservation, the concept of immutability invariably comes up. Immutability means messages placed on hold must be preserved without alteration. Not only should we prevent them from deletion (even if the user placed on hold thinks they’ve successfully purged the message), but the messages should also be prevented from tampering or alteration. Immutability is not a product feature but a combination of feature and the hold processes your organization implements. In-Place Hold also helps you preserve content from intentional tampering or modification. This is achieved by performing a copy-on-write (COW) – when the user or any process attempts to modify a message, before the modified message is saved a copy of the original message is made and saved in the Recoverable Items\Versions folder. Items captured in the Versions folder are also indexed and returned in an In-Place eDiscovery search. When the hold is removed, the copies made in the Versions folder are also removed by the Managed Folder Assistant. Together, In-Place Hold and In-Place eDiscovery provide an easy-to-use mechanism for authorized legal, human resources or other non-technical personnel to easily search and immutably preserve messaging records. Bharat Suneja and Julian Zbogar-SmithAuthorization 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.
