Microsoft Purview enables developers with strong data security across AI apps and agents
Today, developers are at the center of a new wave of innovation—building AI applications and agents that are deeply connected to enterprise data. But with this opportunity comes a new and complex set of security challenges. AI systems operate across cloud platforms, third-party services, and even local and on-premises development environments, interacting dynamically with sensitive data such as customer records, financial information, and intellectual property. Traditional security approaches weren’t designed for this level of scale, autonomy, or fluid data movement—leaving developers to navigate fragmented tools, unclear policies, and the risk of unintentionally exposing sensitive information. At the same time, expectations are rising. Organizations need to ensure that AI applications and agents are compliant, auditable, and secure by default on an enterprise-level—not retrofitted after deployment. But for developers, adding security often means additional complexity, custom integrations, and slower time to market. This tension between speed and control has become one of the biggest barriers to moving AI from experimentation into production. Microsoft Purview is designed to help with this challenge by embedding data security and compliance controls across the development cycle. Purview provides a consistent way to govern how data is accessed, used, and shared—without requiring developers to become security experts. The result is a simpler path to building AI systems that are secure, compliant, and enterprise-ready by design. Extending data security and compliance to local agents and claws Local and endpoint agents, built in platforms such as GitHub Copilot CLI and OpenClaw, introduce a new class of data security challenges as they operate outside traditional control planes and directly on user machines. Unlike cloud systems, these agents can access local files, credentials, terminals, and enterprise apps simultaneously—often moving data across tools and environments. This expands data risks, from sensitive data being unintentionally stored, copied, or shared, to API keys and tokens being exposed, and autonomous workflows triggering data movement without explicit user intent. At the same time, many existing security controls were designed for browser or cloud-based activity, leaving a growing blind spot at the endpoint where agents are increasingly running. The result is a widening gap between how developers build agents to operate locally in the users machines, and how organizations can detect, govern, and protect the data those agents interact with. Microsoft Security and Windows are integrating management and security capabilities directly into the local agents’ development workflow, enabling security as an architectural guarantee rather than an implementation choice. At Build, we are thrilled to be extending Purview visibility and protection capabilities to local agents developed on GitHub Copilot CLI, Claude Code, OpenAI Codex, and OpenClaw - in Public Preview. Unlike traditional cloud applications, these agents operate closer to the data and often create new risks for data exposure. Purview addresses this challenge across all types of agent interactions with a clear, simplified set of scenarios: ▪ Observability: Visibility on Purview Data Security Posture Management (DSPM) across agent inventory, as well as into how local agents interact with sensitive data—across prompts, responses, and actions. ▪ Runtime data protection: Purview Data Loss Prevention (DLP) controls enforced directly into the agent execution flow, inspecting prompts and tool calls in real time to prevent sensitive data exfiltration. ▪ Agentic risk detection: Risky or anomalous agent behaviors detected through Insider Risk Management (IRM) signals, helping teams detect unsafe interactions early. ▪ Audit: Comprehensive, end-to-end logging of all local agent interactions—capturing prompts, responses, data access, and actions for data context. For example, a developer is using a local coding agent to generate code and accidentally includes sensitive credentials in a prompt. AI observability in DSPM surfaces the interaction and shows what data the agent accessed. DLP detects the sensitive data in real time and blocks it from being sent or processed (or sensitive files from being accessed and exfiltrated). At the same time, agentic risk detection flags the session as high risk based on the behavior pattern. All of this activity is captured in audit logs, enabling the security team to investigate and take action quickly. Developers and security teams gain visibility into agent activity and data interactions, while policies prevent sensitive data leakage. This ensures consistent security outcomes across both cloud and endpoint environments, without disrupting developer workflows. Strengthening visibility and controls for Foundry agents Foundry gives developers a central place to build and manage AI agents, but it also creates a need for data security context directly in that workflow—especially as prompts, model interactions, and downstream actions increasingly involve sensitive enterprise data. At Build, we are excited to announce the expansion of the Foundry integration with Purview. This includes Purview DLP runtime controls for prompt processing in Foundry, in Public Preview. As agents and applications built on Foundry increasingly interact with sensitive data, Purview ensures those interactions are governed by trusted controls, identifying Sensitive Information Types (SITs) in real time to detect and protect confidential data embedded in prompts. For example, if a user includes customer PII or financial data in a prompt, Purview can automatically identify the sensitive content and block that prompt from being processed by the model. This ensures that all Foundry apps and agents, regardless of how they’re built or deployed, inherit consistent data protection – allowing organizations to reduce risk of inadvertent data exposure, centralize compliance enforcement across AI workloads, and confidently scale AI adoption knowing sensitive data is protected by design. We’re also building up on the Purview coverage for Foundry shared at the last Microsoft Ignite by announcing Purview insights embedded directly into the Foundry Control Plane, in General Availability, bringing rich data security context to the plane where developers already work. Purview surfaces crucial signals—such as SITs detected in the agentic interactions, % of agentic interactions involving sensitive data, and spread of high-risk users — so Foundry admins can know how AI apps and agents are built in their environment. This shift enables developers to make faster, better decisions in the moment, reducing rework and closing security gaps early on. For customers, the value is clear: stronger security by design and at enterprise scale, accelerated development cycles, and reduced risk of data leaks or compliance issues—without slowing down innovation. Innovating for developers everywhere, at the pace of AI growth Microsoft is also expanding Purview’s reach across the broader developer ecosystem. New integrations help organizations apply consistent oversight to AI tools and platforms developers already use, without adding separate compliance workflows. GitHub Copilot is a critical productivity layer for developers, accelerating how code is written and shipped—making it equally important that developer interactions with GitHub Copilot are governed and secured with the same rigor as enterprise data. Microsoft Purview now extends data governance and compliance capabilities to GitHub Copilot interactions, in Public Preview, enabling GitHub Enterprise customers with Entra SSO to stream audit logs directly into Purview. This brings centralized visibility for AI activity, allowing security and compliance teams to analyze GitHub Copilot agent session activity alongside other AI workloads. With this native integration into GitHub workflows, Purview audits Copilot activity across repositories, pull requests, and developer sessions—ensuring AI-generated code aligns with enterprise data policies, compliance requirements, and secure development standards. By integrating Purview into existing workflows, organizations can govern GitHub AI usage without building parallel pipelines—reducing complexity while ensuring consistent compliance coverage across their entire data estate. Today’s AI agents aren’t built in just one ecosystem—they span custom apps, third-party platforms, and open-source frameworks. Without consistent controls, this creates blind spots where sensitive data can be exposed outside enterprise guardrails. That’s why extending Purview protection beyond Microsoft environments is critical: it ensures developers can apply the same data security, DLP policies, and compliance controls to any agent, anywhere—so innovation can scale without increasing risk. Developers already use Microsoft Purview APIs to embed data protection into enterprise workflows. Today, we’re introducing the Microsoft Purview SDK for .NET — a simple, drop-in toolkit that brings Purview capabilities directly into any application, in Public Preview. Instead of weeks spent wiring APIs, authentication, and error handling, developers can add content scanning, DLP checks, and sensitivity labeling in just a few lines of code. The SDK handles the heavy lifting — including auth, retries, caching, and telemetry — so teams can focus on building experiences. For AI apps and agents built outside of the Microsoft AI platforms, SDK adds built-in support and can evaluate prompts and responses in real time against DLP and content policies — helping prevent data exposure at runtime without custom logic. Designed for both real-time and asynchronous patterns, and for authenticated or anonymous flows, the SDK also feeds activity back into Purview to give security teams centralized visibility and control. The bottom line is- the Microsoft Purview SDK enables developers to build AI apps and agents that are secure and compliant by default — cutting integration time from weeks to days while ensuring data protection scales with AI. The SDK will be available in public preview within the next month. Together, these announcements represent a significant step forward in how developers build secure AI systems. Microsoft Purview is no longer just a data security and compliance solution—it is a first-class layer of the development process by protecting data across AI applications and agents, and enables a bridge between developers and security teams. As AI becomes more agentic, distributed, and deeply connected to enterprise data, the need for built-in security will only grow. With Purview, developers no longer must choose between speed and security—they can build both into every application from the start Getting connected with Microsoft Purview and learn more Learn more about Microsoft Purview on our website and Microsoft Learn. Explore Agent 365. Try Microsoft Purview data security. Learn more about Microsoft Purview SDK.Your AI agents are now employees. It’s time to treat them that way. Meet Loop.
Guest Author: Femke Cornelissen ✨ Chief Transformation Officer - Wortell Meet Loop. There’s a quiet shift happening in enterprise AI, and if you’re leading transformation, it deserves your attention. Microsoft has introduced new Defender capabilities within its Agent 365 tooling gateway, currently in preview. At first glance, it may look like just another security update. It isn’t. It signals a fundamental change in how organizations need to think about AI agents. For the past year, most organizations have onboarded AI agents the same way they onboard software tools. Deploy them, integrate them, and monitor them lightly. That model no longer holds. Today’s agents act autonomously. They access sensitive data. They interact across systems. They make decisions that once required human approval. They no longer behave like tools. They behave like employees. The new Defender functionality introduces something enterprises have been missing. Real-time behavioral oversight for AI agents. Every action an agent attempts is evaluated through webhooks. Behavior is analyzed for anomalies in near real time. Risky or malicious actions are blocked before execution. Activity can be investigated with security level visibility. This is not just monitoring. It is active governance at the point of action. The gap between having AI agents and operating on AI agents has always been trust. And trust requires control. If you cannot see what agents are doing, you cannot govern them. If you cannot govern them, you cannot scale them. If you cannot scale them, your AI strategy stalls at the pilot phase. This layer of visibility, governance, and protection is what closes that gap. If you are a CTO, CIO, or transformation leader, three questions matter right now. Who owns agent behavior in your organization? Do you know what each agent is allowed to do, and what it actually did yesterday? Is agent governance embedded in your security posture, or still treated as a separate conversation? The next generation of high-performing organizations will not just deploy AI agents. They will run on them. That only works if those agents are visible, governed, and protected. This is the real foundation. Not just capability, but control. Because at scale, AI is not just about what agents can do. It is about whether you can trust them to do it.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.Migrate Sentinel to Defender - Why It Is a Security Architecture Decision, Not Just a Portal Change
Microsoft will retire the Sentinel experience in Azure on March 31, 2027. Most of the conversation around this transition focuses on cost optimization and portal consolidation. That framing undersells what is actually happening. The unified Defender portal is not a new interface for the same capabilities. It is the platform foundation for a fundamentally different SOC operating model — one built on a 2-tier data architecture, graph-based investigation, and AI agents that can hunt, enrich, and respond at machine speed. Partners who understand this will help customers build security programs that match how attackers actually operate. This document covers four things: What the unified experience delivers — the security capabilities that do not exist in standalone Sentinel and why they matter against today’s threats. What the transition really involves - is not data migration, but it is a data architecture project that changes how telemetry flows, where it lives, and who queries it. Where the partner opportunity lives — a structured progression from professional services (transactional, transition execution, and advisory) to ongoing managed security services. Why does the unified experience win competitively — factual capability advantages that give partners a defensible position against third-party SIEM alternatives. The Bigger Picture: Preparing for the Agentic SOC Before getting into transition mechanics, partners need to understand where the industry is headed — because the platform decisions made during this transition will determine whether a customer’s SOC is ready for what comes next. The security industry is moving from human-driven, alert-centric workflows to an operating model built on three pillars: Intellectual Property — the detection logic, hunting hypotheses, response playbooks, and domain expertise that differentiate one security team from another. Human Orchestration — the judgment, context, and decision-making that humans bring to complex incidents. Humans set strategy, validate findings, and make containment decisions. They do not manually triage every alert. AI Agents - built agents that execute repeatable work: enriching incidents, hunting across months of telemetry, validating security posture, drafting response actions, and flagging anomalies for human review. The SOC of 2027 will not be scaled by hiring more analysts. It will be scaled by deploying agents that encode institutional knowledge into automated workflows — orchestrated by humans who focus on the decisions that require judgment. This transformation requires a platform that provides three things: Deep telemetry — agents need months of queryable data to analyze behavioral patterns, build baselines, and detect slow-moving threats. The Sentinel data lake provides this at a cost point that makes long-retention feasible. Relationship context — agents need to understand how entities connect. Which accounts share credentials? What is the blast radius of a compromised service principle? What is the attack path from a phished user to domain admin? Sentinel Graph provides this. Extensibility — partners and customers need to build and deploy their own agents without waiting for Microsoft to ship them. The MCP framework and Copilot agent architecture provide this. None of these exist in Azure experience for Sentinel. All three ship with the Defender experience. The urgency goes beyond the March 2027 deadline. Organizations are deploying AI agents, copilots, and autonomous workflows across their businesses — and every one of those creates a new attack surface. Prompt injection, data poisoning, agent hijacking, cross-plugin exploitation — these are not theoretical risks. They are in the wild today. Defending against AI-powered attacks requires a security platform that is itself AI Agent-ready. The new experience in Defender unlocks this experience. What Unified SIEM and XDR Actually Delivers The original framing — “single pane of glass for SIEM and XDR” — is accurate but insufficient. Here is what the unified platform delivers that standalone Sentinel does not. Cross-Domain Incident Correlation The Defender correlation engine does not just group alerts by time proximity. It builds multi-stage incident graphs that link identity compromise to lateral movement to data exfiltration across SIEM and XDR telemetry — automatically. Consider a token theft chain: an infostealer harvests browser session cookies (endpoint telemetry), the attacker replays the token from a foreign IP (Entra ID sign-in logs), creates a mailbox forwarding rule (Exchange audit logs), and begins exfiltrating data (DLP alerts). In standalone Sentinel, these are four separate alerts in four different tables. In the unified platform, they are one correlated incident with a visual attack timeline. 2-Tier Data Architecture The Sentinel data lake introduces a second storage tier that changes the economics and capabilities of security telemetry: Analytics Tier Data Lake Purpose Real-time detection rules, SOAR, alerting Hunting, forensics, behavioral analysis, AI agent queries Latency Sub-5-minute query and alerting Minutes to hours acceptable Cost ~$4.30/GB PAYG ingestion (~$2.96 at 100 GB/day commitment) ~$0.05/GB ingestion + $0.10/GB data processing (at least 20x cheaper) Retention 90 days default (expensive to extend) Up to 12 years at low cost Best for High-signal, low-volume sources High-volume, investigation-critical sources The architecture decision is not “which tier is cheaper.” It is “which tier gives me the right detection capability for each data source.” Analytics tier candidates: Entra ID sign-in logs, Azure activity, audit logs, EDR alerts, PAM events, Defender for Identity alerts, email threat detections. These need sub-5-minute alerting. Data lake candidates: Raw firewall session logs, full DNS query streams, proxy request logs, Sysmon process events, NSG flow logs. These drive hunting and forensic analysis over weeks or months. Dual-ingest sources: Some sources need both tiers. Entra ID sign-in logs are the canonical example — analytics tier for real-time password spray detection, Data Lake for graph-based blast radius analysis across months of authentication history. Implementation is straightforward: a single Data Collection Rule (DCR) transformation handles the split. One collection point, two routing destinations. The right framing: “Right data in the right tier = better detections AND lower cost.” Cost savings are a side effect of good security architecture, not the goal. Sentinel Graph Sentinel graph enables SOC teams and AI agents to answer questions that flat log queries cannot: What is the blast radius of this compromised account? Which service principals share credentials with the breached identity? What is the attack path from this phished user to domain admin? Which entities are connected to this suspicious IP across all telemetry sources? Graph-based investigation turns isolated alerts into context-rich intelligence. It is the difference between knowing “this account was compromised” and understanding “this account has access to 47 service principals, 3 of which have written access to production Key Vault.” Security Copilot Integration Security Copilot embedded in the defender portal helps analysts summarize incidents, generate hunting queries, explain attacker behavior, and draft response actions. For complex multi-stage incidents, it reduces the time from “I see an alert” to “I understand the full scope” from hours to minutes. With free SCUs available with Microsoft 365 E5, teams can apply AI to the highest-effort investigation work without adding incremental cost. MCP and the Agent Framework The Model Context Protocol (MCP) and Copilot agent architecture let partners and customers build purpose-built security agents. A concrete example: an MCP-enabled agent can automatically enrich a phishing incident by querying email metadata, checking the sender against threat intelligence, pulling the user’s recent sign-in patterns, correlating with Sentinel Graph for lateral risk, and drafting a containment recommendation — in under 60 seconds. This is where partner intellectual property becomes competitive advantage. The agent framework is the mechanism for encoding proprietary detection logic, response playbooks, and domain expertise into automated workflows that run at machine speed. Security Store Security Store allows partners to evolve from one‑time transition projects into repeatable, scalable offerings—supporting professional services, managed services, and agent‑based IP that align with the customer’s unified SecOps operating model As part of the transition, the Microsoft Security Store becomes the extension layer for the Defender —allowing partners to deliver differentiated agents, SaaS, and security services natively within Defender and Sentinel, instead of building and integrating in isolation The 4 Investigation Surfaces: A Customer Maturity Ladder The Sentinel Data Lake exposes four distinct investigation surfaces, each representing a step toward the Agentic SOC — and a partner service opportunity: Surface Capability Maturity Level Partner Opportunity KQL Query Ad-hoc hunting, forensic investigation Basic — “we can query” Hunting query libraries; KQL training Graph Analytics Blast radius, attack paths, entity relationships Intermediate — “we understand relationships” Graph investigation training; attack path workshops Notebooks (PySpark) Statistical analysis, behavioral baselines, ML models Advanced — “we predict behaviors” Custom notebook development; anomaly scoring Agent/MCP Access Autonomous hunting, triage, response at machine speed Agentic SOC — “we automate” Custom agent development; MCP integration The customer who starts with “help us hunt better” ends up at “build us agents that hunt autonomously.” That is the progression from professional services to managed services. What the Transition Actually Involves It is not a data migration — customers’ underlying log data and analytics remain in their existing Log Analytics workspaces. That is important for partners to communicate clearly. But partners should not set the expectation that nothing changes except the URL. Microsoft’s official transition guide documents significant operational changes — including automation rules and playbooks, analytics rule, RBAC restructuring to the new unified model (URBAC), API schema changes that break ServiceNow and Jira integrations, analytics rule transitions where the Fusion engine is replaced by the Defender XDR correlation engine, and data policy shifts for regulated industries. Most customers cannot navigate this complexity without professional help. Important: Transitioning to the Defender portal has no extra cost - estimate the billing with the new Sentinel Cost Estimator Optimizing the unified platform means making deliberate changes: Adding dual-ingest for critical sources that need both real-time detection and long-horizon hunting. Moving high-volume telemetry to the Data Lake — enabling hunting at scale that was previously cost-prohibitive. Retiring redundant data copies where Defender XDR already provides the investigation capability. Updating RBAC, automation, and integrations for the unified portal’s consolidated schema and permission structure. Training analysts on new investigation workflows, Sentinel Graph navigation, and Copilot-assisted triage. Threat Coverage: The Detection Gap Most Organizations Do Not Know They Have This transition is an opportunity to quantify detection maturity — and most organizations will not like what they find. Based on real-world breach analysis — infostealers, business email compromise, human-operated ransomware, cloud identity abuse, vulnerability exploitation, nation-state espionage, and other prevalent threat categories — organizations running standalone Sentinel with default configurations typically have significant detection gaps. Those gaps cluster in three areas: Cross-domain correlation gaps — attacks that span identity, endpoint, email, and cloud workloads. These require the Defender correlation engine because no single log source tells the complete story. Long-retention hunting gaps — threats like command-and-control beaconing and slow data exfiltration that unfold over weeks or months. Analytics-tier retention at 90 days is too expensive to extend and too short for historical pattern analysis. Graph-based analysis gaps — lateral movement, blast radius assessment, and attack path analysis that require understanding entity relationships rather than flat log queries. The unified platform with proper log source coverage across Microsoft-native sources can materially close these gaps — but only if the transition includes a detection coverage assessment, not just a portal cutover. Partners should use MITRE ATT&CK as the common framework for measuring detection maturity. Map existing detections to ATT&CK tactics and techniques before and after transition — a measurable, defensible improvement that justifies advisory fees and ongoing managed services. Partner Opportunity: Professional Services to Managed Services This transition creates a structured progression for all partner types — from professional services that build trust and surface findings, to managed security services that deliver ongoing value. The key insight most partners miss: do not jump from “transition assessment” to “managed services pitch.” Customers are not ready for that conversation until they have experienced the value of professional services. The bridge engagement — whether transactional, transition execution, or advisory — builds trust, demonstrates the expertise, and surfaces the findings that make the managed services conversation a logical next step. Professional Services (transactional + transition execution + advisory) → Managed Security Services (MSSP) The USX transition is the ideal professional services entry point because it combines a mandatory deadline (March 2027) with genuine technical complexity (analytics rule, automation behavioral changes, RBAC restructuring, API schema shifts) that most customers cannot navigate alone. Every engagement produces findings — detection gaps, automation fragility, staffing shortfalls — that are the most credible possible evidence for managed services. Professional Services Transactional Partners Offer Customer Value Key Deliverables Transition Readiness Assessment Risk-mitigated transition with clear scope Sentinel deployment inventory; Defender portal compatibility check; transition roadmap with timeline; MITRE ATT&CK detection coverage baseline Transition Execution and Enablement Accelerated time-to-value, minimal disruption Workspace onboarding; RBAC and automation updates; Dual-portal testing and validation; SOC team training on unified workflows Security Posture and Detection Optimization Better detections and lower cost Data ingestion and tiering strategy; Dual-ingest implementation for critical sources; Detection coverage gap analysis; Automation and Copilot/MCP recommendations Advisory Partners Offer Customer Value Key Deliverables Executive and Strategy Advisory Leadership alignment on why this transition matters Unified SecOps vision and business case; Zero Trust and SOC modernization alignment; Stakeholder alignment across security, IT, and leadership Architecture and Design Advisory Future-ready architecture optimized for the Agentic SOC Target-state 2-tier data architecture; Dual-ingest routing decisions mapped to MITRE tactics; RBAC, retention, and access model design Detection Coverage and Gap Analysis Measurable detection maturity improvement Current-state MITRE ATT&CK coverage mapping; Gap analysis against 24 threat patterns; Detection improvement roadmap with priority recommendations SOC Operating Model Advisory Smooth analyst adoption with clear ownership Redesigned SOC workflows for unified portal; Incident triage and investigation playbooks; RACI for detection engineering, hunting, and platform ops Agentic SOC Readiness Preparation for AI-driven security operations MCP and agent architecture assessment; Custom agent development roadmap; IP + Human Orchestration + Agent operating model design Cost, Licensing and Value Advisory Transparent cost impact with strong business case Current vs. future cost analysis; Data tiering optimization recommendations; TCO and ROI modeling for leadership The conversion to managed services is evidence-based. Every professional services engagement produces findings — detection gaps, automation fragility, staffing shortfalls. Those findings are the most credible possible case for ongoing managed services. Managed Security Services The unified platform changes the managed security conversation. Partners are no longer selling “we watch your alerts 24/7.” They are selling an operating model where proprietary AI agents handle the repeatable work — enrichment, hunting, posture validation, response drafting — and human experts focus on the decisions that require judgment. This is where the competitive moat forms. The formula: IP + Human Orchestration + AI Agents = differentiated managed security. The unified platform enables this through: Multi-tenancy — the built-in multitenant portal eliminates the need for third-party management layers. Sentinel Data Lake — agents can query months of customer telemetry for behavioral analysis without cost constraints. Sentinel Graph — agents can traverse entity relationships to assess blast radius and map attack paths. MCP extensibility — partners can build agents that integrate with proprietary tools and customer-specific systems. Partners who build proprietary agents encoding their detection logic into the MCP framework will differentiate from partners who rely on out-of-box capabilities. The Securing AI Opportunity Organizations are deploying AI agents, copilots, and autonomous workflows across their businesses at an accelerating pace. Every AI deployment creates a new attack surface — prompt injection, data poisoning, agent hijacking, cross-plugin exploitation, unauthorized data access through agentic workflows. These are not theoretical risks. They are in the wild today. Partners who can help customers secure their AI deployments while also using AI to strengthen their SOC will command premium positioning. This requires a security platform that is itself AI Agent-ready — one that can deploy defensive agents at the same pace organizations deploy business AI. The unified Defender portal is that platform. Partners who position USX as “preparing your SOC for AI-driven security operations” will differentiate from partners who position it as “moving to a new portal.” Cost and Operational Benefits Better security architecture also costs less. This is not a contradiction — it is the natural result of putting the right data in the right tier. Benefit How It Works Eliminate low-value ingestion Identify and remove log sources that are never used for detections, investigations, or hunting. Immediately lowers analytics-tier costs without impacting security outcomes. Right-size analytics rules Disable unused rules, consolidate overlapping detections, and remove automation that does not reduce SOC effort. Pay only for processing that delivers measurable security value. Avoid SIEM/XDR duplication Many threats can be investigated directly in Defender XDR without duplicating telemetry into Sentinel. Stop re-ingesting data that Defender already provides. Tier data by detection need Store high-volume, hunt-oriented telemetry in the Data Lake at at least 20x lower cost. Promote only high-signal sources to the analytics tier. Full data fidelity preserved in both tiers. Reduce operational overhead Unified SIEM+XDR workflows in a single portal reduce tool switching, accelerate investigations, simplify analyst onboarding, and enable SOC teams to scale without proportional headcount increases. Improve detection quality The Defender correlation engine produces higher-fidelity incidents with fewer false positives. SOC teams spend less time triaging noise and more time on real threats. Competitive Positioning Partners need defensible talking points when customers evaluate third-party SIEM alternatives. The following advantages are factual, sourced from Microsoft’s transition documentation and platform capabilities — not marketing claims. No extra cost for transitioning — even for non-E5 customers. Third-party SIEM migrations involve licensing, data migration, detection rewrite, and integration rebuild costs. Native cross-domain correlation across Sentinel + Defender products into multi-stage incident graphs. Third-party SIEMs receive Microsoft logs as flat events — they lack the internal signal context, entity resolution, and product-specific intelligence that powers cross-domain correlation. Custom detections across SIEM + XDR — query both Sentinel and Defender XDR tables without ingesting Defender data into Sentinel. Eliminates redundant ingestion cost. Alert tuning extends to Sentinel — previously Defender-only capability, now applicable to Sentinel analytics rules. Net-new noise reduction. Unified entity pages — consolidated user, device, and IP address pages with data from both Sentinel and Defender XDR, plus global search across SIEM and XDR. Third-party SIEMs provide entity views from ingested data only. Built-in multi-tenancy for MSSPs — multitenant portal manages incidents, alerts, and hunting across tenants without third-party management layers. Try out the new GDAP capabilities in Defender portal. Industry validation: Microsoft’s SIEM+XDR platform has been recognized as a Leader by both Forrester (Security Analytics Platforms, 2025) and Gartner (SIEM Magic Quadrant, 2025). Summary: What Partners Should Take Away Topic Key Message Framing USX is a security architecture transformation, not a portal transition. Lead with detection capability, not cost savings. Platform foundation Sentinel Data Lake + Sentinel Graph + MCP/Agent Framework = the platform for the Agentic SOC. 4 investigation surfaces KQL → Graph → Notebooks → Agent/MCP. A maturity ladder from “we can query” to “we automate at machine speed.” Architecture 2-tier data model (analytics + Data Lake) with dual-ingest for critical sources. Cost savings are a side effect of good architecture. Transition complexity Analytics rules and automation rules. API schema changes. RBAC restructuring. Most customers need professional help. Partner engagement model Professional Services (transactional + transition execution + advisory) → Managed Services (MSSP). Competitive positioning No extra cost. Native correlation. Cross-domain detections. Built-in multi-tenancy. Capabilities third-party SIEMs cannot replicate. Partner differentiation IP + Human Orchestration + AI Agents. Partners who build proprietary agents on MCP have competitive advantage. Timeline March 31, 2027. Start now — phased transition with one telemetry domain first, then scale.Safeguarding Sensitive Data in Microsoft 365 Copilot Interactions: DLP for Microsoft 365 Copilot
Microsoft 365 Copilot is redefining how organizations work, bringing the power of generative AI directly into our secure productivity tools. As Copilot adoption accelerates, we’ve heard that you want more control over how your sensitive data can be used in interactions with Copilot. At Ignite 2025, Microsoft announced a major enhancement: Microsoft Purview Data Loss Prevention for Microsoft 365 Copilot to safeguard Microsoft 365 Copilot and Copilot Chat prompts, now entering General Availability. Even better, this capability is included for all users of Microsoft 365 Copilot and Copilot Chat. Why DLP for Copilot Prompts Is a Game-Changer As organizations adopt Copilot, their ways of sharing, creating, and interacting with data expand. With just a prompt, users can have Copilot summarize documents, analyze spreadsheets, or help brainstorm presentations. However, it raises an important question: what if the prompt includes sensitive information, like project code names, financial account numbers, health records, or other sensitive data? Over the last 2 years, Microsoft has been building a set of Data Loss Prevention (DLP) controls specifically designed for Copilot. Below is a quick overview of these related capabilities — ranging from already available to newly in preview — before we dive deep into today's GA announcement: Prevent Copilot processing of files & emails based on sensitivity labels In November 2024, Microsoft introduced the ability to create a DLP policy to restrict Microsoft 365 Copilot and Copilot Chat from processing sensitive files and emails using Sensitivity Labels for grounding data. This capability gives you control over whether content with the sensitivity labels you specify is restricted from being used in Microsoft 365 Copilot and Copilot Chat to generate summaries and responses. Prevent web searches for prompts containing Sensitive Information Types (SITs) The latest feature entering Public Preview is DLP for Microsoft 365 Copilot and Copilot Chat to prevent web searches for prompts containing sensitive data. This real-time control helps organizations mitigate data leakage and oversharing risks by preventing Microsoft 365 Copilot and agents from using sensitive data for external web searches. If a sensitive information type (SIT) is detected in a user prompt, Copilot can still leverage your enterprise data to form a response without sending the sensitive data to external search engines for web grounding. This capability extends to Microsoft 365 Copilot and agents built in Copilot Studio that are published to Microsoft 365 Copilot. DLP to Safeguard Copilot Prompts with Sensitive Information Types (SITs) The rest of this blog focuses on a key addition to this capability set: DLP for Microsoft 365 Copilot + Copilot Chat prompts to prevent processing of prompts containing sensitive information, now entering General Availability. Unlike the web search capability above, which prevents sensitive data from being sent externally during a web query, this capability evaluates the user’s text input directly, before processing occurs, to determine whether both enterprise data and web grounding can proceed. This feature uses Sensitive Information Types (SITs) as a condition within a Purview DLP policy to assess whether a user prompt sent to Copilot contains sensitive data, even if the data is unlabeled. With DLP for Copilot prompts, a user’s text input is scanned in real time for SITs, whether built-in (like Social Security Numbers, credit card numbers, etc.) or custom-defined by your organization (such as confidential terms or project names). If a text prompt contains one of the SITs you specify, Copilot restricts processing, halts any Graph or web grounding, and displays a clear message to the end user that the request cannot be completed. A user enters a prompt in Microsoft 365 Copilot Chat containing sensitive information. How DLP for Copilot Protects Prompts: Real-Time, Intelligent Protection The new DLP capability integrates seamlessly with Microsoft Purview, leveraging its powerful data classification & detection engine for sensitive information types. Here’s how it works: Input: When a user submits a prompt, Copilot checks the prompt for sensitive information using built-in or organization-defined sensitive information types (SITs). Immediate Action: If a SIT is detected, Copilot restricts the prompt from being processed. No AI response is generated, and no data is sent for Graph or web grounding. Output: Users receive a clear notification that their request cannot be completed due to company policies. This real-time protection ensures that sensitive data is not leaked or overshared, even as users explore new ways to work with AI. Setting Up DLP for Copilot Prompts: Data Security Admin Experience The easiest way to get started is through the new Microsoft Purview Data Security Posture Management (DSPM) portal, which provides a guided, one-click setup experience: 1. In Purview, go to Solutions > DSPM (preview) 2. Select the "Prevent data exposure in Microsoft 365 Copilot and Microsoft Copilot interactions" objective. 3. Follow the guided workflow and apply the recommended one-click DLP policy. The policy starts in simulation mode so you can review activity before enforcing it. Alternatively, you can configure and customize this policy directly from the Purview DLP portal Policies page or enable it from the Microsoft 365 Admin Center. view the remediation plan. view policy details and review. Then click the button, create a custom policy in DLP simulation mode to protect sensitive data referenced in Microsoft 365 Copilot and Microsoft Copilot. the confidence level and instance count. Practical Scenarios: Protecting What Matters Most Protect PII, financial data, and intellectual property: Financial institutions can block prompts containing deal terms, account numbers, or other sensitive data, preventing leaks through AI interactions. Similarly, healthcare organizations can safeguard patient information, and manufacturers can secure intellectual property and trade secrets from exposure, along with many other practical use cases. Once the prompt is detected and blocked, Microsoft Graph grounding and Bing web grounding is restricted. Safeguard sensitive non-public information: Imagine an organization involved in a confidential merger. By using DLP for Copilot prompts, administrators can set up a custom SIT that includes the project’s code name. If a user asks Copilot about the merger using the project’s code name, their request will be blocked, keeping sensitive information secure and protected. Visibility into DLP for M365 Copilot Prompts When a user’s prompt triggers a DLP policy, notifications and alerts are surfaced directly in the Microsoft Purview and Defender portals for security administrators. These alerts provide detailed information about which policy was activated, the type of sensitive information detected, and the context of the attempted Copilot interaction. Using these alert queues in Purview and Defender XDR, administrators can efficiently track policy activity, investigate potential incidents, and refine DLP rules to better align with organizational needs. The ability to review historical alerts and track ongoing enforcement empowers admins to maintain strong data security and proactively safeguard sensitive information. Defender XDR portal investigation of prompt DLP based incident. Takeaways The introduction of this latest enhancement to DLP for Copilot represents a key advancement in secure Copilot deployment and adoption. By empowering organizations to block sensitive data at the prompt level, Microsoft is helping customers unlock the full potential of Copilot, without compromising security or compliance. This innovation reflects Microsoft’s commitment to responsible AI, continuous improvement, and customer-driven development. As Copilot evolves, so will the tools to protect your data, ensuring that productivity and security go hand in hand. For more details, stay tuned for updates to the Product Roadmap and Learn documentation. Learn about using DLP to protect interactions with Microsoft 365 Copilot and Copilot Chat Learn about the default DLP policy for Microsoft 365 Copilot location | Microsoft Learn Permissions to create or edit a DLP policy to safeguard Microsoft 365 Copilot and Copilot Chat Learn about the new Microsoft Purview Data Security Posture Management (DSPM) | Microsoft Learn Roadmap Item: DLP for Microsoft 365 Copilot to safeguard prompts Roadmap Item: DLP to safeguard web search in Microsoft 365 CopilotWhy 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-servicesPart 3: DSPM for AI: Governing Data Risk in an Agent‑Driven Enterprise
Why Agent Security Alone Is Not Enough? Foundry‑level controls are designed to prevent unsafe behavior and bound autonomy at runtime. But even the strongest preventive controls cannot answer key governance questions on their own: Where is sensitive data being used in AI prompts and responses? Which agents are interacting with high‑risk data—and how often? Are agents oversharing, drifting from expected behavior, or creating compliance exposure over time? How do we demonstrate control, auditability, and accountability for AI systems to regulators and leadership? These are not theoretical concerns. With agents acting continuously and autonomously, risk no longer shows up as a single event—it shows up as patterns, trends, and posture. DSPM for AI exists to make those patterns visible. At its core, DSPM for AI provides a centralized, risk‑centric view of how data is used, exposed, and governed across AI applications and agents. It shifts the conversation from individual incidents to organizational posture. DSPM for AI answers a simple but critical question: “Given how our AI systems are actually being used, what is our current data risk—and where should we intervene?” Unlike traditional DSPM, DSPM for AI expands visibility into: Prompts and responses Agent interactions with enterprise data Oversharing patterns Agent‑driven risk signals Trends across first‑party and third‑party AI usage What DSPM for AI Brings into Focus? 1. AI Interaction Visibility DSPM for AI treats AI prompts, responses, and agent activity as first‑class security telemetry. This allows security teams to see: Sensitive data being submitted to AI systems High‑risk interactions involving regulated information Repeated exposure patterns rather than one‑off events In short, AI conversations become auditable security signals, not blind spots. 2. Oversharing and Exposure Risk One of the most common AI risks is unintentional oversharing—especially when agents retrieve or combine data across systems. DSPM for AI makes it possible to: Identify where sensitive data exists but is poorly labeled Detect when unlabeled or over‑shared data is being accessed via AI Prioritize remediation based on actual usage, not static classification This ties directly back to the Sensitive Data Leakage patterns discussed earlier—but at an organizational scale. 3. Agent‑Level Risk Context DSPM for AI extends posture management beyond users to agents themselves. Security teams can: Inventory agents operating in the environment View agent activity trends Identify agents exhibiting higher‑risk behavior patterns This enables a powerful shift: agents can be assessed, reviewed, and governed just like digital workers. 4. Bridging Security, Compliance, and Audit DSPM for AI connects operational security with governance outcomes. Through integration with audit logs, retention, and compliance workflows, organizations gain: Evidence for investigations and regulatory inquiries Consistent compliance posture across human and agent activity A defensible, repeatable governance model for AI systems This is where AI risk becomes explainable, reportable, and manageable—not just prevented. How DSPM for AI Complements Azure AI Foundry? If Azure AI Foundry provides the control plane that enforces safe agent behavior, DSPM for AI provides the visibility plane that measures how that behavior translates into risk over time. Think of it this way: Foundry controls prevent and constrain DSPM for AI observes, measures, and prioritizes Together, they enable continuous governance Without DSPM, security teams are left guessing whether controls are effective at scale. With DSPM, risk becomes quantifiable and actionable. Why This Matters for Security Leaders? For security leaders, agentic AI introduces a familiar challenge in an unfamiliar form: Risk is non‑deterministic Behavior changes over time Impact can span multiple systems instantly DSPM for AI gives leaders the ability to: Monitor AI risk like any other enterprise workload Prioritize remediation where it matters most Move from reactive investigations to proactive governance This is not about slowing innovation—it’s about making AI adoption defensible. Closing: From Secure Agents to Governed AI Securing agents is necessary—but it is not sufficient on its own. As AI systems increasingly act on behalf of the organization, governance must shift from individual controls to continuous posture management. DSPM for AI provides the missing link between prevention and accountability, turning fragmented AI activity into a coherent risk narrative. Together, Azure AI Foundry and DSPM for AI enable organizations to not only build and deploy agents safely, but to operate AI systems with clarity, confidence, and control at scale. In the agentic era, security prevents incidents—but governance determines trust.Part 2: Securing AI Agents with Azure AI Foundry: From Abuse Patterns to Lifecycle Controls
Every agent abuse pattern we’ve explored points to a specific control gap, not a theoretical flaw. Across all patterns, one theme consistently emerges: agents behave logically according to how they are configured. When failures occur, it’s rarely because the model “got it wrong”—it’s because the surrounding system granted too much freedom, trust, or persistence without adequate guardrails. This is exactly the problem Azure AI Foundry is designed to address. Rather than treating security as an add‑on, Foundry embeds controls directly into the agent platform, ensuring protection does not rely on custom glue code or fragmented tools. Effective agent security, therefore, is not concentrated in a single layer—it is enforced end‑to‑end across the agent lifecycle. In practice, Foundry delivers controls across all of the critical dimensions where agent abuse occurs: Instructions — governing what the agent is intended to do, with built‑in protections for prompts, prompt injection, and task adherence Identity — treating agents as first‑class identities, enforcing least privilege and accountability from day one Tools — constraining which tools agents can invoke, under what conditions, and with what approvals Data — extending enterprise data security, classification, and DLP controls directly to agent interactions Runtime behavior — providing continuous observability, detection, and evaluation of what agents are actually doing in production Because these controls are natively integrated, Foundry enables teams to secure agents without redesigning their architecture around security after the fact. With that context, let’s map each agent abuse pattern to the specific Foundry controls that help prevent it, detect it early, or limit its impact in real‑world deployments. Jailbreaks → Instruction & Runtime Protection in Azure AI Foundry The Risk Recap Jailbreaks attempt to override system or developer instructions by exploiting language ambiguity, instruction hierarchy, and the model’s default helpfulness. For agents, this risk escalates quickly—from unsafe outputs to unauthorized real‑world actions—once tools and identities are involved. How Azure AI Foundry Addresses This? Azure AI Foundry implements jailbreak protection before execution and at runtime, ensuring malicious intent is intercepted early and contained if it reappears later in the workflow. Foundry capabilities applied: Prompt Shields (Azure AI Content Safety) to detect and block direct jailbreak attempts at input Spotlighting to reduce the influence of adversarial or instruction‑override prompts Runtime detection and alerting (via built‑in observability and Defender integration) to surface attacker intent and suspicious prompts Least‑privilege agent identity (Entra integration) to ensure that even successful linguistic manipulation cannot translate into unauthorized actions Continuous evaluation and red‑teaming built into the agent lifecycle to validate resilience before deployment Core takeaway: In Foundry, jailbreak protection is not limited to prompt design—it is enforced across instruction handling, identity, and runtime execution. Prompt Injection → Context & Task Integrity in Azure AI Foundry The Risk Recap Prompt injection alters what the agent believes its instructions are—often indirectly through documents, emails, or RAG data sources. For agents, indirect prompt injection (XPIA) is especially dangerous because it is invisible to users and can quietly redirect agent behavior. How Azure AI Foundry Addresses This Foundry treats prompt trust and task integrity as first‑class security concerns, not just input filtering problems. Foundry capabilities applied: Prompt Shields with Spotlighting to neutralize hidden or embedded instructions from untrusted content Task Adherence Controls to continuously verify that the agent remains aligned to its approved goal or workflow Runtime detection to identify context manipulation and instruction smuggling as it occurs—before tools are invoked Core takeaway: Azure AI Foundry protects not just prompts, but the integrity of agent context and intent throughout execution. Memory Poisoning → Memory Governance & Observability in Azure AI Foundry The Risk Recap Memory poisoning persists across sessions and workflows. Once malicious or misleading information is written into memory, agents continue to act on it—often silently—making memory a long‑term attack surface. How Azure AI Foundry Addresses This? Foundry treats agent memory as a governed state, not an unrestricted persistence layer. Foundry capabilities applied: Controlled memory persistence to reduce what information can be written and retained Built‑in observability and tracing to monitor behavioral drift across interactions and over time Task adherence over time to detect delayed‑trigger abuse and gradual deviation from intended goals Red‑team evaluation workflows that simulate memory‑based abuse scenarios before agents reach production Core takeaway: In Azure AI Foundry, memory is governed, observable, and testable—preventing attackers from gaining persistence through long‑lived agent state. Excessive Autonomy → Identity, Tool & Approval Guardrails in Azure AI Foundry The Risk Recap Excessive autonomy occurs when agents are over‑empowered—too many tools, too many permissions, too little oversight. The agent may function “correctly,” but the blast radius grows exponentially. How Azure AI Foundry Addresses This? Foundry is designed to constrain autonomy without breaking productivity by enforcing boundaries at identity, tool, and workflow levels. Foundry capabilities applied: Agent identity as a first‑class identity with least‑privilege enforcement from creation Tool guardrails to explicitly define which tools an agent can invoke, and under what conditions Approval and checkpointing controls to introduce human‑in‑the‑loop enforcement for high‑impact actions Runtime tool monitoring to detect anomalous or risky behavior across integrated systems Core takeaway: Azure AI Foundry ensures that autonomy is intentional, bounded, and accountable—not accidental or unchecked. Sensitive Data Leakage → Integrated Data Security & Governance in Azure AI Foundry The Risk Recap Sensitive data leakage is often unintentional and difficult to detect after the fact. Agents can expose data through responses, memory, logs, or tool outputs while behaving “helpfully.” How Azure AI Foundry Addresses This? Foundry extends enterprise‑grade data security directly into agent workflows, rather than treating agents as exceptions. Foundry capabilities applied: Output content filtering to detect and redact sensitive data before responses are returned Microsoft Purview integration to enforce classification, labeling, DLP, auditing, and compliance policies on agent interactions Runtime exfiltration detection to identify risky access or transfer patterns as they happen End‑to‑end observability and lineage to trace exactly where sensitive data was accessed, used, or leaked Core takeaway: In Azure AI Foundry, agents inherit the same data security and governance expectations as humans and applications—by default. Closing: Governing Agent Risk at Enterprise Scale The patterns outlined in this post point to a critical shift in how organizations must think about AI risk. As agents gain the ability to act autonomously, retain state, and operate continuously across systems, risk becomes systemic, fast‑moving, and inherently scalable. In this environment, isolated safeguards or one‑time reviews are no longer sufficient. Azure AI Foundry addresses this challenge by embedding security controls across the entire agent lifecycle—from how agents are designed and authorized, to how they behave in production, to how their actions are continuously monitored and evaluated over time. This lifecycle‑integrated approach ensures that autonomy is paired with visibility, enforceable boundaries, and accountability by design. For security and risk leaders, the question is no longer whether agents can be deployed safely in a controlled pilot. The real test is whether they can be operated predictably, transparently, and at scale as they become part of critical business workflows. As you evaluate or expand agentic AI in your organization: Inventory and classify your agents as you would any other enterprise workload Treat agents as identities, enforcing least privilege and clear accountability Align controls to the full lifecycle, not just prompts or outputs Demand continuous visibility and evaluation, not point‑in‑time assurances Agents will increasingly act on behalf of the business. Ensuring they do so safely requires governance that moves at the same speed as autonomy. In an agent‑driven enterprise, trust isn’t assumed—it is continuously enforced.
