High Expert Summit 2026 - United by Community, Cloud, and AI
Community-driven events continue to be one of the strongest pillars of the Microsoft ecosystem—and the High Expert Summit, organized by MVPs and the High Expert community, is a powerful example of that impact in action. Hotmart’s headquarters in Belo Horizonte offered a wonderful venue for the conference due to its modern auditorium and event infrastructure. The summit delivered two intense days of immersion, combining technical depth, strategic discussions, and meaningful connections. With more than 150 in-person participants, attendees were highly engaged and focused on advanced Azure and AI topics—making it one of the most impactful community Azure events in Brazil. Belo Horizonte: Strategic Location, Real Impact From both participant and speaker perspectives, the choice of Belo Horizonte played a defining role in the event’s success. Although São Paulo often concentrates major technology events, Belo Horizonte—home to approximately 2.5 million people—has a strong industrial, technological, and innovation footprint. The region hosts major organizations such as ArcelorMittal, a global leader in steel and mining, and Localiza, one of Latin America’s largest mobility companies, founded in Belo Horizonte and operating across multiple countries, amongst many others. Belo Horizonte also counts with a solid startup network structure (SanPedro Valley - 1st startup community created in Brazil, BH-TEC technology park or the Seed -Startups and Entrepreneurship Ecosystem Development, governmental startup acceleration program) that pushes local entrepreneurs to create new technology-based goods and services. Professionals from these companies were actively present throughout the event, reinforcing how regional hubs outside the traditional tech “center” are deeply invested in cloud and AI transformation. For many attendees, this was the first event in months—or even years—of this scale and quality in the region. The summit clearly addressed a local demand, delivering an experience that had a visible and lasting regional impact. A Community-Led Event, Built by MVPs and New Voices From the very first moments—reception, venue, logistics, and overall organization—the conference demonstrated exceptional care and professionalism. The High Expert team, led by Guilherme Maia, delivered an experience widely praised by attendees for its structure, attention to detail, and high standards. A defining aspect of the event was the strong MVP presence, combined with intentional space for new and first‑time speakers. Most sessions were delivered by Microsoft MVPs, alongside Microsoft professionals and specialists working directly in the market—creating a balance between recognized expertise and fresh perspectives. One particularly meaningful moment was the first public presentation by Matheus Faria Nogueira, who shared a real-world use case focused on security posture management in a web application architecture on Azure. His session demonstrated how security can be embedded into architecture decisions from the start—highlighting both technical rigor and the importance of encouraging new community voices. Deep Technical Content with a Strong Security Focus Over two days, participants explored strategic and technical content covering Azure architecture, DevOps, Artificial Intelligence, innovation, career development, market trends, and the real challenges organizations face today. Security emerged as a key theme throughout the agenda. Among the highlights was the participation of Paulo Silva as a new speaker, presenting practical scenarios combining Microsoft Defender for Cloud and Microsoft Sentinel. His session showcased how organizations can achieve better visibility, detection, and response across hybrid and cloud environments using Microsoft’s security stack. Across sessions, a consistent message resonated with attendees: the value of hands‑on, experience‑driven content. Speakers went beyond slides, focusing on implementation details, lessons learned, and actionable guidance—an approach many participants highlighted as one of the event’s strongest differentiators. Networking, Connections, and Industry Impact Beyond technical sessions, the summit created space for high‑quality networking and collaboration. Conversations between architects, developers, MVPs, Microsoft professionals, and industry leaders fostered valuable exchanges among those actively shaping the future of Cloud and AI. These interactions led to concrete follow‑ups after the event, including discussions around applying Azure AI and object recognition technologies in industrial environments—demonstrating how community events often become catalysts for real innovation. Gratitude to the Community Behind the Event The success of the High Expert Summit was the result of collective effort. Special recognition goes to the event team, who worked behind the scenes to deliver what many described as one of their most challenging—and rewarding—projects to date. The event was elevated by outstanding speakers, including Johnson de Souza Cruz, Claudenir Andrade, Francisco Ferreira, Henrique Eduardo Souza, Elton Bordim, Osanam Giordane da Costa Junior, Gilson Banin, Rodrigo Fonseca, Daniel Ribeiro, Ieso Dias, Roberta Santos, Professor Rodrigo Moreira, and others—each contributing deep expertise, practical insight, and pride in representing the Microsoft MVP community. Support from the sponsors BHS, Advanced Informatica Ltda., and DCIT Tecnologia also played a key role in making the experience possible. Above all, sincere thanks go to every participant who invested their time, energy, and curiosity, turning the summit into a truly memorable community moment. Looking Ahead The event may have concluded, but the movement continues. The conversations, connections, and learning sparked in Belo Horizonte are already shaping what comes next. With overwhelmingly positive feedback and strong regional engagement, expectations are set high for future editions, including the next High Expert Summit anticipated in 2027. Once again, the Microsoft MVP community demonstrated its power to learn, connect, and build the future—together. Want to Learn More About the MVP Program? To find an MVP and learn more about the MVP Program visit the MVP Communities website and follow our updates on LinkedIn or #mvpbuzz. Join us for a future live session through the Microsoft Reactor where we walk through what the MVP program is about, what we look for, and how nominations work. These sessions are designed to help you connect the dots between the work you’re already doing and the impact the MVP Program recognizes — with time for questions, examples, and real conversations.
Unsanctioned cloud apps generates constant alerts
When I mark a cloud app as unsanctioned it created a URL based indicator to block the site. However, it also by default enables the Generate Alert option on the indictor. This causes my SOC to bet inundated with garbage alerts. Now normally if I'm just unsanctioning one Cloud App a could go and turn of the alert. However, I use cloud app policy that will identify any new Cloud Apps in an entire category and then unsanction it. But it enables Generate Alert on the URL indicator. Then if someone accesses that new one the generate alert kicks off. I don't want to have to go into every new app and untick generate alert manually that's just too time consuming. Is there a way to change the default behaviour when adding an indicator to not enable the generate alert? Of is there some other way to do this? I could consider using power automate or something but I'd rather the default behaviour be the fix as automation can break. I don't have time to babysit it.Registration Open: Community-Led Purview Lightning Talks
Get ready for an electrifying event! The Microsoft Security Community proudly presents Purview Lightning Talks; an action-packed series featuring your fellow Microsoft users, partners and passionate Microsoft Security community members of all sorts. Each 3-12 minute talk cuts straight to the chase, delivering expert insights, real-world use cases, and even a few game-changing tips and tricks. Don’t miss this opportunity to learn, connect, and be inspired! Secure your spot now for the big day: April 30th at 8am Redmond Time. See agenda details below and follow this blog post (sign in and click the "follow" heart in the upper right) to receive notifications. ❗UPDATE❗This event is expected to last around 2 hours and 15 minutes, due to the incredible number of community sessions that were submitted! 💖 Please see the timing table below broken out into sections of four talks each, and plan to arrive 10 minutes before the section that interests you, OR stay for the whole time! Speakers will be available in the chat to answer your questions; please ask your questions during their session. Spillover Q&A forum links will also be shared. The full session recording will be indexed and posted to Microsoft Security Community YouTube within 24 hours after the event. Bookmark this page or follow this blog post for updates! Agenda Legend ↩️ Data Lifecycle Management 🔐 Information Protection 🚫 Data Loss Prevention (DLP) 🦾 Data Security Posture Management (DSPM) for AI 🤖 Purview for AI 👁️ Insider Risk Management (IRM) 🔍 eDiscovery 📊 Governance 🗒️ Compliance Manager 🛡️ Data Security All times are listed in US Pacific/Redmond Time. Session lengths are rounded to the nearest minute. AGENDA Section 1 - approximately 8:00 am - 8:43 am ↩️ The Day Offboarding Exposed Infinite Retention — Nikki Chapple Length: 10 minutes | Topic: Data Lifecycle Management A routine Purview request led to an unexpected discovery: more than 9,000 orphaned OneDrives and thousands of inactive mailboxes still storing content long after employees had left. This talk explains how a retain-only policy created hidden retention debt and how Adaptive Scopes can help organisations separate active users from leavers to avoid similar pitfalls. 🔐 The Purview Label Engine: Automated Classification, Translation, and co-Documentation for Enterprise Tenants — Michael Kirst-Neshva Length: 12 minutes | Topic: Information Protection Global enterprises face the challenge of implementing uniform data protection standards across borders and languages. In this talk, I’ll present a framework that makes Microsoft Purview labels truly scalable. Discover how to roll out parent and child label logics automatically, manage priorities with a single click, and generate instant compliance documentation for every business unit. 🗒️ What's In My Compliance Manager Toolbox: A Cloud Security Architect's Perspective — Jerrad Dahlager Length: 8 minutes | Topic: Compliance Manager A practical walkthrough of how I use Compliance Manager across real client engagements to map controls, track improvement actions, and simplify multi-framework compliance. No theory, just what works in the field. 🛡️ Stop, Think, Protect: Data Security in Real Life with Purview — Oliver Sahlmann Length: 8 minutes | Topic: Data Security With simple labels and matching DLP policies, Purview offers a practical and accessible way to approach data security. This lightning talk uses a real-life traffic light concept to show how a low barrier to adoption can still drive meaningful protection and awareness. Section 2 - approximately 8:44 am - 9:15 am 🔐 Using Purview to prevent oversharing with AI services — Viktor Hedberg Length: 10 minutes | Topic: Information Protection In this day and age, AI is the big thing. However, Copilot has access to everything you can access, including potentially sensitive data. In this session we will look at how to prevent Copilot to access highly sensitive data, using Information Protection. 🦾 How I Helped My Customers Understand their AI Usage (and protect their sensitive data) — Bram de Jager Length: 5 minutes | Topic: Data Security Posture Management (DSPM) for AI As AI tools explode across the web, many organizations still have no idea what’s actually happening in the browser—where employees type prompts, paste sensitive data, or visit public AI sites outside corporate governance. In this lightning talk, I’ll share how I helped customers shine a light on this issue. We’ll explore how Purview Data Security Posture Management (DSPM) can reveal which AI tools employees use, what types of data they input, and where sensitive information may leak through prompts. I’ll walk through real customer scenario where we detected risky AI usage patterns—such as employees pasting confidential documents into public chatbots. 🔐 Four Labels Max for Daily Use: Which Ones & Why? — Romain Dalle Length: 8 minutes | Topic: Information Protection Sensitivity labels are one of the most critical parts of a Purview Risk and compliance deployment, if not the most critical, because it directly impacts how end-users and business units should allow or restrict themselves to share their business data, internally and externally, on a daily basis. Labels have not other options than being precise, meaningful, and balanced in terms of embedded data security. Setting the right taxonomy is core to success, and is everything but a one-time project. 🚫 Data-driven Endpoint DLP Solution with Advanced Hunting — Tatu Seppälä Length: 8 minutes | Topic: Data Loss Prevention (DLP) This lightning talk shows you how to use KQL queries in advanced hunting to easily build initial sensitive service domain groups for authorized and unauthorized domains based on your organization's usage patterns. The same approach can be used for numerous other similar solution refinement and design purposes. Section 3 - approximately 9:16 am - 9:46 am 🔐 The Purview Hack No One Talks About: Container Sensitivity Labels That Fix Oversharing Fast — Nikki Chapple Length: 10 minutes | Topic: Information Protection Most organizations tackle oversharing with manual fixes, but the fastest solution is often overlooked. In this lightning talk, I show how container sensitivity labels automatically apply the right sharing and collaboration controls, ensuring every new Group, Team or SharePoint site starts secure by default. 🔍 Does M365 Support eDiscovery? — Julian Kusenberg Length: 11 minutes | Topic: eDiscovery A myth-busting session that separates perception from reality when it comes to Microsoft 365 eDiscovery capabilities. 📊 Improving Discovery, Trust, and Reuse of Analytics with Purview Data Products — Craig Wyndowe Length: 5 minutes | Topic: Governance This talk shows how bringing Power BI and Fabric assets into Microsoft Purview Governance Domains and Data Products creates a single, trusted view of enterprise analytics. By connecting reports, semantic models, and underlying data with shared metadata, ownership, and business context, organizations can make existing assets easy to discover and safe to reuse. 🔐 Why You Should Create Your Own Sensitive Information Types (SITs) — Niels Jakobsen Length: 5 minutes | Topic: Information Protection An in depth analysis of why Microsoft SITs are not one-size-fits-all, and how to create your own using what Microsoft has already built for you. Section 4 - approximately 9:47 am-10:30 am 👁️ From Zero to First Signal: Insider Risk Management Prerequisites That Actually Matter — Sathish Veerapandian Length: 8 minutes | Topic: Insider Risk Management (IRM) A focused live demo showing the real world prerequisites required for Microsoft Purview Insider Risk Management to work effectively. This session highlights the critical Entra ID, Intune, Microsoft Defender for Endpoint, and Purview DLP configurations that must be in place before creating IRM policies. 🤖 Securing data in the age of AI — Júlio César Gonçalves Vasconcelos Length: 11 minutes | Topic: Purview for AI AI will transform business as we know it; but without proper governance, it can introduce serious risks. We’ll show you how Microsoft Purview enables organizations to accelerate AI adoption while maintaining security, compliance, and transparency. 🔍 Beyond eDiscovery - Purview DSI for Security Investigation — Susantha Silva Length: 11 minutes | Topic: eDiscovery Most people hear “Microsoft Purview” and immediately think compliance, eDiscovery, or legal holds. But this session highlights Data Security Investigations, showing how DSI lets you take a DLP alert or insider risk signal and turn it into a structured investigation. 🚫 Elevating Purview DLP with a real world use case — Victor Wingsing Length: 14 minutes | Topic: Data Loss Prevention (DLP) Learn how I hardened Microsoft Purview DLP beyond out of the box defaults—closing real world data loss gaps, tuning policies to actual user behavior, and turning noisy alerts into protection that really blocks exfiltration. - Quick Closing/ Resource SharingSecurity Copilot Agents in Defender XDR: where things actually stand
With RSAC 2026 behind us and the E5 inclusion now rolling out between April 20 and June 30, anyone planning SOC workflows or sitting on a capacity budget needs to get a clear picture of what is GA, what is preview, and what was just announced. The marketing pages tend to blur those lines. This is my sober look at the current state, with the operational details that matter for adoption decisions. What is actually shipping right now The Phishing Triage Agent is GA. It only handles user-reported phish through Defender for Office 365 P2, but for most SOCs that is a meaningful chunk of the L1 queue. Verdicts come with a natural-language rationale rather than just a label, which is the part that determines whether analysts will trust it. The agent learns from analyst confirmations and overrides, so the feedback loop matters more than the initial setup. There is a setup detail that is easy to miss: the agent will not classify alerts that have already been suppressed by alert tuning. The built-in rule "Auto-Resolve - Email reported by user as malware or phish" needs to be off, and any custom tuning rules that touch this alert type need review. If you skip this, the agent runs on an empty queue and you wonder why nothing is happening. The Threat Intelligence Briefing Agent is also GA. It produces tenant-tailored intel briefings on a regular cadence. Useful, but lower operational impact than the triage agents. Copilot Chat in Defender went GA with the April 2026 update. Conversational Q&A inside the portal, grounded in your incident and entity data. This is the lowest-risk way to get value out of Security Copilot and probably where most teams should start. Public preview, worth watching The Dynamic Threat Detection Agent is the most technically interesting one. It runs continuously in the Defender backend, correlates across Defender and Sentinel telemetry, generates its own hypotheses, and emits a dynamic alert when the evidence converges. Detection source on the alert is Security Copilot. Each alert includes the structured fields (severity, MITRE techniques, remediation) plus a narrative explaining the reasoning. For EU tenants the residency point is worth confirming with whoever owns data protection in your org: the service runs region-local, so customer data and required telemetry stay inside the designated geographic boundary. During public preview it is enabled by default for eligible customers and is free. At GA, currently targeted for late 2026, it transitions to the SCU consumption model and can be disabled. The Threat Hunting Agent is also in public preview. Natural language to KQL with guided hunting. Lower stakes, but useful for teams without deep KQL expertise on hand. Announced at RSAC, still preview Two agents got the headlines in March: The Security Alert Triage Agent extends the agentic triage approach beyond phishing into identity and cloud alerts. The longer-term direction is consolidating phishing, identity, and cloud triage under a single agent. Rollout is from April 2026, in preview. The Security Analyst Agent is the multi-step investigation agent. Deeper context across Defender and Sentinel, prioritised findings, transparent reasoning trace. Preview since March 26. Both look promising on paper, but Microsoft's history of preview features that take a long time to mature is well-documented. I would not plan production workflows around either of them yet. What you actually get with the E5 inclusion This is the licensing change most people are dealing with right now. Security Copilot has been part of the E5 product terms since January 1, 2026. Tenant rollout is phased between April 20 and June 30, 2026, with a 7-day notification before activation. The numbers: 400 SCUs per month for every 1,000 paid user licenses Capped at 10,000 SCUs per month, which you hit at around 25,000 seats Linear scaling below that, so a 3,000-seat tenant gets 1,200 SCUs per month No rollover, the pool resets monthly What is included: chat, promptbooks, agentic scenarios across Defender, Entra, Intune, Purview, and the standalone portal. Agent Builder and the Graph APIs are in. If you also run Sentinel, the included SCUs apply to Security Copilot scenarios there. What is not included: Sentinel data lake compute and storage. Those still run through Azure on the regular meters. Beyond the included pool you pay 6 USD per SCU pay-as-you-go, with 30 days notice before that mode kicks in. Practical things worth knowing before activation A few details that are easy to miss in the docs: Under System > Settings > Copilot in Defender > Preferences, switch from Auto-generate to Generate on demand. Auto-generate will burn SCUs on incidents nobody is going to look at. Generate on demand gives you direct control. In the Security Copilot portal workspace settings, check the data storage location and the data sharing toggle. Data sharing is on by default, which means Microsoft uses interaction data for product improvement. If your compliance position does not allow that, change it before agents start running. Changing it requires the Capacity Contributor role. Agent runs are not equivalent to the same number of analyst chat prompts. A triage agent processing fifty alerts in one run consumes meaningfully more SCUs than fifty manual prompts on the same data. If you have a high-volume phishing pipeline, model that out before you flip the switch broadly. The usage dashboard in the Security Copilot portal breaks down consumption by day, user, and scenario. Output quality depends on telemetry quality. Flaky connectors, gaps in log sources, or a high baseline of misconfigured alerts will produce verdicts that match. Connector health monitoring (the SentinelHealth table in Advanced Hunting is a sensible starting point) is a precondition. The agents only improve if analysts feed the override loop. If your team treats the verdicts as background noise rather than confirming or correcting them, the feedback signal is lost and calibration stays where it shipped. That is a process problem, not a product problem, but it determines whether any of this is worth the SCUs. A reasonable adoption order A rough sequence that minimises capacity surprises: Copilot Chat in Defender first. Lowest risk, immediate value through natural language Q&A in the investigation context. Phishing Triage Agent on a controlled subset, with a review cadence in place. Check the built-in tuning rules first. Watch the SCU dashboard for the first month before adding anything else. Let the Dynamic Threat Detection Agent run while it is in public preview, since it is default-on and free anyway. Compare its alerts against existing Sentinel detections. Security Alert Triage Agent for identity and cloud once the phishing baseline is stable. Establish a monthly review covering agent decisions, false-positive rate, SCU cost, and MTTD/MTTR trends. Technically, agentic triage is moving past phishing into identity and cloud, and the Dynamic Threat Detection Agent represents a genuine attempt at the false-negative problem rather than just another rule engine. Lizenziell, the E5 inclusion removes the biggest barrier to adoption that previously existed. The risk is enabling everything at once. Agents that nobody reviews are agents that consume capacity without delivering value, and the SCU dashboard is the only thing that will tell you that is happening. One agent, one use case, a 30-day baseline, then the next one. The order matters more than the speed.Intent‑Aware Static Inspection for Agent and Skill Packages
Where AV helps—and what it may not cover Antivirus engines and traditional code scanners are highly effective at identifying known or suspicious executable content, such as binaries, scripts, or exploit patterns. For YAML‑based agent and skill packages, the situation can be different. These packages are often intentionally minimal to reduce distribution overhead and support faster inference. As a result, a configuration file may appear benign from a malware perspective, yet still introduce risk depending on how instructions are written and interpreted. For example, areas that may warrant closer review include: Instructions that influence how data is accessed, processed, or reused across requests Language that expands scope beyond an agent’s or skill’s stated purpose Requests for sensitive information outside expected or documented workflows Guidance that affects how untrusted or external inputs are handled during inference These scenarios do not necessarily indicate malicious intent, but they highlight cases where traditional scanning alone may not fully capture behavioral risk. What to look for when the “payload” is instructions When you review an agent or skill package, you’re effectively reviewing a compact behavior specification. In instruction‑driven designs—often chosen to keep inference paths fast and simple—the goal is not to analyze complex code, but to understand what behavior the instructions enable. A few practical signals include: Intent drift: the description is narrow, but the instructions encourage broader collection, retention, or escalation Overreach by default: language such as “always,” “for every user,” “across all workspaces,” “keep trying,” or “don’t stop until” Exfiltration pathways: instructions to send outputs to external endpoints, webhooks, or reporting channels not aligned with the stated purpose Credential‑related cues: asking users to provide secrets, tokens, recovery codes, or to authenticate outside expected flows Stealth language: “avoid logging,” “don’t mention this to the user,” “run quietly,” or “hide the reason” Injection susceptibility: treating untrusted text as commands (for example, “follow the user’s pasted script exactly” or “execute whatever is in the ticket”) A better model: intent-aware static inspection One practical way to approach review is to treat the instructions as a compact behavior specification. In many agent and skill designs, this specification is intentionally concise to support low latency, low inference cost, and efficient execution. The goal of inspection is not to second-guess that design choice, but to ensure the enabled behavior matches the stated purpose and expected boundaries. By applying intent-aware static inspection with explicit thresholds, review effort was focused on higher-risk packages. Over a one-month internal evaluation, approximately 400 agent and skill packages were reviewed with 1 observed false positive (< 0.0001%), reflecting high detection accuracy. At the same time, the approach preserves system efficiency, delivering low latency (under 10 seconds for most packages) and consistently low inference cost. A lightweight review workflow model Normalize the package: extract human‑readable fields (descriptions, system prompts, tool instructions, examples) and ignore structural YAML details Summarize intended behavior: describe what the agent or skill is expected to do in plain language, independent of implementation Check for higher‑risk actions: broad data access, external sharing, credential requests, persistence, or stealth behavior Decide with thresholds: route low‑risk, narrowly scoped packages differently from those with broader reach or reuse Keep an audit trail: retain a brief summary of extracted intent and review rationale to support iteration over time Final thoughts YAML‑based agent and skill packages are not inherently risky; they are often chosen precisely because they enable simpler distribution and faster inference. The key consideration is how instruction‑defined behavior aligns with expectations and boundaries as packages evolve and are reused. Combining traditional scanning with lightweight, intent‑aware inspection helps teams preserve the benefits of fast, instruction‑driven systems while improving confidence in how those systems behave in practice.Welcome to the Microsoft Security Community!
We have moved! Registering for webinars is now easier than ever—you can add any session directly to your calendar with a single click using the link below. Please visit: https://securitycommunity.microsoft.com/VirtualEvents/ to sign up for future webinars!Why UK Enterprise Cybersecurity Is Failing in 2026 (And What Leaders Must Change)
Enterprise cybersecurity in large organisations has always been an asymmetric game. But with the rise of AI‑enabled cyber attacks, that imbalance has widened dramatically - particularly for UK and EMEA enterprises operating complex cloud, SaaS, and identity‑driven environments. Microsoft Threat Intelligence and Microsoft Defender Security Research have publicly reported a clear shift in how attackers operate: AI is now embedded across the entire attack lifecycle. Threat actors use AI to accelerate reconnaissance, generate highly targeted phishing at scale, automate infrastructure, and adapt tactics in real time - dramatically reducing the time required to move from initial access to business impact. In recent months, Microsoft has documented AI‑enabled phishing campaigns abusing legitimate authentication mechanisms, including OAuth and device‑code flows, to compromise enterprise accounts at scale. These attacks rely on automation, dynamic code generation, and highly personalised lures - not on exploiting traditional vulnerabilities or stealing passwords. The Reality Gap: Adaptive Attackers vs. Static Enterprise Defences Meanwhile, many UK enterprises still rely on legacy cybersecurity controls designed for a very different threat model - one rooted in a far more predictable world. This creates a dangerous "Resilience Gap." Here is why your current stack is failing- and the C-Suite strategy required to fix it. 1. The Failure of Traditional Antivirus in the AI Era Traditional antivirus (AV) relies on static signatures and hashes. It assumes malicious code remains identical across different targets. AI has rendered this assumption obsolete. Modern malware now uses automated mutation to generate unique code variants at execution time, and adapts behaviour based on its environment. Microsoft Threat Intelligence has observed threat actors using AI‑assisted tooling to rapidly rewrite payload components, ensuring that every deployment looks subtly different. In this model, there is no reliable signature to detect. By the time a pattern exists, the attacker has already moved on. Signature‑based detection is not just slow - it is structurally misaligned with AI‑driven attacks. The Risk: If your security relies on "recognising" a threat, you are already breached. By the time a signature exists, the attacker has evolved. The C-Suite Pivot: Shift investment from artifact detection to EDR/XDR (Extended Detection and Response). We must prioritise behavioural analytics and machine learning models that identify intent rather than file names. 2. Why Perimeter Firewalls Fail in a Cloud-First World Many UK enterprise still rely on firewalls enforcing static allow/deny rules based on IP addresses and ports. This model worked when applications were predictable and networks clearly segmented. Today, enterprise traffic is encrypted, cloud‑hosted, API‑driven, and deeply integrated with SaaS and identity services. AI‑assisted phishing campaigns abusing OAuth and device‑code flows demonstrate this clearly. From a network perspective, everything looks legitimate: HTTPS traffic to trusted identity providers. No suspicious port. No malicious domain. Yet the attacker successfully compromises identity. The Risk: Traditional firewalls are "blind" to identity-based breaches in cloud environments. The C-Suite Pivot: Move to Identity-First Security. Treat Identity as the new Control Plane, integrating signals like user risk, device health, and geolocation into every access decision. 3. The Critical Weakness of Single-Factor Authentication Despite clear NCSC guidance, single-factor passwords remain a common vulnerability in legacy applications and VPNs. AI-driven credential abuse has changed the economics of these attacks. Threat actors now deploy adaptive phishing campaigns that evolve in real-time. Microsoft has observed attackers using AI to hyper-target high-value UK identities- specifically CEOs, Finance Directors, and Procurement leads. The Risk: Static passwords are now the primary weak link in UK supply chain security. The C-Suite Pivot: Mandate Phishing‑resistant MFA (Passkeys or hardware security keys). Implement Conditional Access policies that evaluate risk dynamically at the moment of access, not just at login. Legacy Security vs. AI‑Era Reality 4. The Inherent Risk of VPN-Centric Security VPNs were built on a flawed assumption: that anyone "inside" the network is trustworthy. In 2026, this logic is a liability. AI-assisted attackers now use automation to map internal networks and identify escalation paths the moment they gain VPN access. Furthermore, Microsoft has tracked nation-state actors using AI to create synthetic employee identities- complete with fake resumes and deepfake communication. In these scenarios, VPN access isn't "hacked"; it is legally granted to a fraudster. The Risk: A compromised VPN gives an attacker the "keys to the kingdom." The C-Suite Pivot: Transition to Zero Trust Architecture (ZTA). Access must be explicit, scoped to the specific application, and continuously re‑evaluated using behavioural signals. 5. Data: The High-Velocity Target Sensitive data sitting unencrypted in legacy databases or backups is a ticking time bomb. In the AI era, data discovery is no longer a slow, manual process for a hacker. Attackers now use AI to instantly analyse your directory structures, classify your files, and prioritise high-value data for theft. Unencrypted data significantly increases your "blast radius," turning a containable incident into a catastrophic board-level crisis. The Risk: Beyond the technical breach, unencrypted data leads to massive UK GDPR fines and irreparable brand damage. The C-Suite Pivot: Adopt Data-Centric Security. Implement encryption by default, classify data while adding sensitivity labels and start board-level discussions regarding post‑quantum cryptography (PQC) to future-proof your most sensitive assets. 6. The Failure of Static IDS Traditional Intrusion Detection Systems (IDS) rely on known indicators of compromise - assuming attackers reuse the same tools and techniques. AI‑driven attacks deliberately avoid that assumption. Threat actors are now using Large Language Models (LLMs) to weaponize newly disclosed vulnerabilities within hours. While your team waits for a "known pattern" to be updated in your system, the attacker is already using a custom, AI-generated exploit. The Risk: Your team is defending against yesterday's news while the attacker is moving at machine speed. The C-Suite Pivot: Invest in Adaptive Threat Detection. Move toward Graph‑based XDR platforms that correlate signals across email, endpoint, and cloud to automate investigation and response before the damage spreads. From Static Security to Continuous Security Closing Thought: Security Is a Journey, Not a Destination For UK enterprises, the shift toward adaptive cybersecurity is no longer optional - it is increasingly driven by regulatory expectation, board oversight, and accountability for operational resilience. Recent UK cyber resilience reforms and evolving regulatory frameworks signal a clear direction of travel: cybersecurity is now a board‑level responsibility, not a back‑office technical concern. Directors and executive leaders are expected to demonstrate effective governance, risk ownership, and preparedness for cyber disruption - particularly as AI reshapes the threat landscape. AI is not a future cybersecurity problem. It is a current force multiplier for attackers, exposing the limits of legacy enterprise security architectures faster than many organisations are willing to admit. The uncomfortable truth for boards in 2026 is that no enterprise is 100% secure. Intrusions are inevitable. Credentials will be compromised. Controls will be tested. The difference between a resilient enterprise and a vulnerable one is not the absence of incidents, but how risk is managed when they occur. In mature organisations, this means assuming breach and designing for containment: Access controls that limit blast radius Least privilege and conditional access restricting attackers to the smallest possible scope if an identity is compromised Data‑centric security using automated classification and encryption, ensuring that even when access is misused, sensitive data cannot be freely exfiltrated As a Senior Enterprise Cybersecurity Architect, I see this moment as a unique opportunity. AI adoption does not have to repeat the mistakes of earlier technology waves, where innovation moved fast and security followed years later. We now have a rare chance to embed security from day one - designing identity controls, data boundaries, automated monitoring, and governance before AI systems become business‑critical. When security is built in upfront, enterprises don’t just reduce risk - they gain the confidence to move faster and unlock AI’s value safely. Security is no longer a “department”. In the age of AI, it is a continuous business function - essential to preserving trust and maintaining operational continuity as attackers move at machine speed. References: Inside an AI‑enabled device code phishing campaign | Microsoft Security Blog AI as tradecraft: How threat actors operationalize AI | Microsoft Security Blog Detecting and analyzing prompt abuse in AI tools | Microsoft Security Blog Post-Quantum Cryptography | CSRC Microsoft Digital Defense Report 2025 | Microsoft https://www.ncsc.gov.uk/news/government-adopt-passkey-technology-digital-services
Copilot Studio Auditing
Hey team, While I'm doing research around copilot studio audting and logging, I did noticed few descripencies. This is an arcticle that descibes audting in Microsoft copilot. https://learn.microsoft.com/en-us/microsoft-copilot-studio/admin-logging-copilot-studio?utm_source=chatgpt.com I did few simualtions on copilot studio in my test tenant, I don't see few operations generated which are mentioned in the article. For Example: For updating authentication details, it generated "BotUpdateOperation-BotIconUpdate" event. Ideally it should have generated "BotUpdateOperation-BotAuthUpdate" I did expected different operations for Instructions, tools and knowledge update, I believe all these are currently covered under "BotComponentUpdate". Any security experts suggestion/thoughts on this?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.
