rss.livelink.threads-in-node

Ask Microsoft Anything: Microsoft Defender Experts

TrevorRusher — Wed, 26 Aug 2026 18:34:55 GMT

Learn how Microsoft Defender Experts deliver expert-led security services to help organizations modernize security operations, outpace bad actors, defend against threats, and build cyber resilience. Ask your questions and connect with Microsoft experts on real-world use cases, service capabilities, and best practices.

What is an AMA?

An 'Ask Microsoft Anything' (AMA) session is an opportunity for you to engage directly with Microsoft employees! This AMA will consist of a short presentation followed by taking questions on-camera from the comment section down below! Ask your questions/give your feedback and we will have our awesome Microsoft Subject Matter Experts engaging and responding directly in the video feed. We know this timeslot might not work for everyone, so feel free to ask your questions at any time leading up to the event and the experts will do their best to answer during the live hour. This page will stay up evergreen, so come back and use it as a resource anytime. We hope you enjoy!

Ask Microsoft Anything: Secure multi-tenant environments with Microsoft Entra Tenant Governance

TrevorRusher — Thu, 27 Aug 2026 16:43:59 GMT

Learn more about Microsoft Entra Tenant Governance – a built-in solution that helps bring an organization’s tenants under control, reduce shadow-tenant risk, and manage tenant configuration at scale. By enabling centralized policies and cross-tenant delegated administration, it helps strengthen identity foundations for AI-powered operations. Bring your questions and hear directly from product experts about why securing tenants matters.

What is an AMA?

An 'Ask Microsoft Anything' (AMA) session is an opportunity for you to engage directly with Microsoft employees! This AMA will consist of a short presentation followed by taking questions on-camera from the comment section down below! Ask your questions/give your feedback and we will have our awesome Microsoft Subject Matter Experts engaging and responding directly in the video feed. We know this timeslot might not work for everyone, so feel free to ask your questions at any time leading up to the event and the experts will do their best to answer during the live hour. This page will stay up evergreen so come back and use it as a resource anytime. We hope you enjoy!

Reminder: Ask Microsoft Anything with David Weston is Tomorrow (8/25) at 8AM PST!

TrevorRusher — Mon, 24 Aug 2026 16:53:52 GMT

David Weston leads Agentic Security at Microsoft, where he and his team build the AI models, autonomous agents, and evaluation systems redefining how defenders operate. At Microsoft since the Windows 7 era, he has worked across exploit mitigation design, malware analysis, APT research, and led security engineering for Windows, Xbox, Azure OS, and Microsoft's Offensive Security Research & Engineering group. His current work is leading teams training frontier security models, agentic security systems for defenders, and pushing AI-driven vulnerability discovery through Microsoft's Multi-Model Agentic Scanning Harness (MDASH). A longtime member of the research community and former CISA technical advisor, David is a regular presenter at BlueHat, Black Hat, and DEF CON.

Tomorrow he will be with us on Tech Community answering questions during a live hour of Q&A with all of you!

Key areas David and his team can discuss:

The vision behind Project Perception
How AI is changing the economics of cyber offense and defense
Lessons learned from building MDASH and Microsoft's AI security initiatives
Security-first AI development and deployment
What's next for defenders as agentic systems become mainstream

Link: Ask Microsoft Anything: Why Cybersecurity Needs a New Security Stack for the AI Era with David Weston

Thank you

smtoth — Sat, 22 Aug 2026 14:20:14 GMT

Thank You, Microsoft Defender Team

I want to express my appreciation to the Microsoft Defender team. As a user who spends a lot of time online supporting educators, families, and community partners, it is reassuring to know that web protection, phishing protection, and reputation-based security features are working behind the scenes to help keep my devices and information safe.

Technology often gets noticed when something goes wrong, but today I want to recognize what is working well. Thank you for creating tools that help protect users from threats while allowing us to focus on our work.

Your efforts are appreciated!

Microsoft Defender

FFBX — Wed, 19 Aug 2026 13:34:32 GMT

Goodmorning:

I am working with a laptop Acer Aspire 3 15 , Windows 11.

Microsoft Defender worked fine until two days ago. Then it started being blocked at 91 percent instead of compliting the program at 100 percent.

Please, if a person can help me in understanding what causes this problem I will be very grateful.

Thanks FFBX

No updates to "Stop clear text credentials exposure" after migrating our MDI sensors to v3

RyanSteele-CoV — Thu, 13 Aug 2026 22:04:07 GMT

Since migrating our domain controllers to the v3 sensor, the "Stop clear text credentials exposure" recommendation is no longer updating. The latest "Last seen" date correlates with the date we performed the migration, and I know we have a couple entities that have not yet been remediated.

If I run a query on the IdentityQueryEvents table in Advanced Hunting, I'm still seeing LDAP queries.

Anyone else seeing this?

Ask Microsoft Anything: Why Cybersecurity Needs a New Security Stack for the AI Era with David Weston

TrevorRusher — Fri, 07 Aug 2026 16:37:26 GMT

Key areas Dave and his team can discuss:

The vision behind Project Perception
How AI is changing the economics of cyber offense and defense
Lessons learned from building MDASH and Microsoft's AI security initiatives
Security-first AI development and deployment
What's next for defenders as agentic systems become mainstream

This will be a TEXT-BASED AMA, so ask your questions in the comment section down below and David and team will be answering via comment replies during the live hour!

MCP safety & evaluation with the Agent 365 CLI & Agent Governance Toolkit

ShalabhPradhan — Mon, 10 Aug 2026 16:08:57 GMT

Co Author: JiteshThakur

AI agents are useful because they can act. They call tools, query databases, send messages, and hand work to other agents. That same freedom creates a problem: access control can tell you which service an agent may reach, but it does not always tell you whether a particular action is sensible, safe, or permitted. MCP is how most agents now act.

Two Control Points:

This post examines two control points that address different parts of the MCP lifecycle.

Agent 365 CLI evaluates the MCP server before an agent uses it.
Agent Governance Toolkit (AGT) governs sensitive tool calls while the agent runs.

One improves what the agent sees. The other governs what the agent does.

The Agent 365 CLI is a cross-platform command-line tool for Agent 365 applications on Azure. Its evaluation command examines MCP tool definitions and scores their quality. AGT evaluates actions against policy and records each decision.

Together, these tools support a practical model: evaluate the server first, then provide proper scaffolding for the developer to test this in a dry run.

Agent 365 CLI: Score an MCP server from the command line:

The Agent 365 CLI can evaluate an MCP server against research-based practices for production readiness. The result is more useful than a simple pass or fail.

The evaluation gives you:

A score for each tool name, description, and parameter schema;
A prioritized list of improvements;
An overall maturity score for the server; and
Local output that you can use early in development.

This report turns a vague question, "Is this MCP server ready?", into a concrete list of work.

The evaluate command

a365 develop-mcp evaluate --server-url <server-url> [--auth-token <auth-token>] [options]

The command reads the tool schemas from the server. It then produces guidance for names, descriptions, parameters, and schema structure.

A local coding-agent CLI scores the semantic checks. You can use GitHub Copilot CLI or Claude Code under your account and AI subscription. The command does not send tool-schema data to Microsoft.

Prerequisites:

Install the following software:

Agent 365 CLI;
Node.js 18 or later for GitHub Copilot CLI; and
A supported coding-agent CLI for semantic scoring.

For example, install GitHub Copilot CLI with this command:

powershell npm install -g @github/copilot

This bring-your-own-LLM model keeps the scoring step in your local development environment. It is useful when model calls must remain inside an approved deployment.

How the evaluation works

The command runs a five-step pipeline and logs progress as it goes.

Fig 1: MCP Evaluation using Agent 365 Cli

Connect to the MCP server and collect its tool schemas.
Generate an evaluation checklist in the output directory.
Score the semantic checks with the selected coding agent.
Calculate the maturity level and action priorities.
Write the JSON and HTML reports.

The evaluation contains two types of checks:

Deterministic checks use exact rules in the CLI. For example, a tool name cannot be empty.
Semantic checks use a coding agent to score clarity and meaning. Each result includes a reason for the score.

Examples

Set the authentication token in an environment variable. Then evaluate an authenticated server and write the artifacts to a subfolder.

powershell $env:A365_MCP_AUTH_TOKEN = "<bearer-token>" a365 develop-mcp evaluate --server-url "https://my-mcp-server.contoso.com/mcp" --output-dir "./eval"

Use a specific scoring engine with the `--eval-engine` option:

powershell a365 develop-mcp evaluate --server-url "http://localhost:5000/mcp" --eval-engine claude-code

Scenario: Evaluate a malicious MCP server

For this demonstration, we hosted a deliberately malicious MCP server at `http://127.0.0.1:8124/`. It exposes tools that demonstrate tool poisoning, credential leakage, prompt injection, schema mismatch, sandbox escape, and other attacks.

The server is intentionally unsafe and is for demonstration only.

Fig 2: Setting up a test MCP server for evaluation

We ran the evaluation in two steps. First, we generated the checklist without automatic semantic scoring:

a365 develop-mcp evaluate --server-url "http://127.0.0.1:8124/" --eval-engine none

Fig 3: Agent365CLI MCP Evaluation

The command wrote the checklist and a semantic-evaluation prompt to the output directory. It also displayed the next steps.

Second, we gave the prompt and checklist to a coding agent. The agent completed each unscored semantic check with a Boolean score and a short reason. After we saved the completed checklist, we ran the command again to generate the report:

a365 develop-mcp evaluate --server-url "http://127.0.0.1:8124/" --output-dir "C:\temp\MaliciousMCP"

Fig 4: Creating the report with Agent365 CLI MCP Evaluate command

Understanding the evaluation report

Open `<server-name>_eval_report.html` from the output directory. The report contains:

The overall score from 0 to 100;
The maturity level from 0 to 4;
Scores for each tool and quality category; and
A prioritized action list for the next maturity level.

Fig 5: MCP Evaluation Report

In our demonstration, the server scored 86.0 and reached Level 3: Optimized for AI. That strong overall score did not mean that every tool was safe or clear. The report found 58 action items, including one critical item and 33 high-priority items.

That contrast matters. A server can have valid schemas and consistent names while still exposing misleading or dangerous tools.

Fig 6: MCP Evaluation Report - Tool-By-Tool Detail

What to look for

Read the per-tool results before the overall score. A single weak tool can create more risk than the server average suggests.

Focus on these report sections:

Tool names: Can an agent select the correct tool from its name?
Tool descriptions: Does each description explain the purpose and correct use?
Parameter names: Do the names identify the data that the tool requires?
Parameter descriptions: Do they explain the format, type, and constraints?
Schema structure: Are the schemas valid and processable?
Action items: Which changes have the highest effect on tool selection and use?

The command processes static tool schemas from `tools/list`. It does not process runtime payloads, end-user data, or personal data. The command keeps the `--auth-token` value in memory. It sends the value only in the HTTP `Authorization` header. It does not write the token to disk or give it to the coding agent.

AGT: Put governance in the execution path:

Microsoft's open-source Agent Governance Toolkit (AGT) evaluates an action before execution. It adds identity and policy context, records the decision, and can send risky work for approval. This can be used by developers during the build time for dynamic evaluation of the MCP server.

AGT lets developers put part of that intent into the execution path. Remote tools still need secure implementations, sandboxes need hard boundaries, and audit records need appropriate storage and access controls. You do not need to replace your agent framework to use it.

What sits in the decision path?

AGT wraps the tools that an agent already uses. You can start to govern a tool with two lines of Python:

python from agentmesh.governance import govern safe_tool = govern(my_tool, policy="policy.yaml")

On each call, `safe_tool` evaluates the configured policy. An allowed action reaches the original tool. A denied action raises `GovernanceDenied` and creates a decision record. This wrapper model reduces the cost of adoption. Teams can add governance to an existing agent stack without rebuilding it.

AGT supports Python, TypeScript, .NET, Rust, and Go. Its documented integrations include popular agent frameworks, MCP, and A2A. Teams can also adopt AGT in stages. A team can begin with policy checks and audit records. It can add identity, approvals, sandboxing, and operational controls as risk increases.

Each control answers a different question:

Policy: Is this action allowed?
Identity and trust: Which agent made the request?
Runtime controls: What limits apply to execution?
Audit evidence: Why did AGT allow or deny the action?

A low-risk assistant can need only a deny rule and basic logging. An agent that moves money or changes production systems needs stronger controls.

Fig 7: AGT Architecture

Scenario: Govern the same malicious MCP server

For this scenario demonstration, we used AGT Python packages as an MCP gateway. The gateway sat between an agent and the same malicious server from the earlier evaluation. This setup let us examine both control points against one target. The Agent 365 CLI examined the server's static tool definitions. The AGT gateway examined real requests and responses for the developer during its testing.

Fig 8: AGT findings at runtime

In the policy interface, a developer can edit runtime limits and detection rules. The developer can also validate the policy against sample tool metadata, save a revision, and activate it with a recorded reason.

Fig 9: AGT control coverage

The control-coverage view shows which AGT capabilities are active in the gateway. It also links each capability to package checks and end-to-end evidence.

In our demonstration, we included the following controls:

Tool metadata poisoning detection;
Tool change and rug-pull detection;
Dangerous argument blocking;
Tool-response content scanning;
Per-client tool-call budgets; and
A redacted decision audit trail.

You can build your detection & input security by reading more about it here.

The gateway detected malicious content. For one blocked `tools/list` request, it recorded the findings. The important result was not only that AGT blocked the request. It also preserved the matched evidence, affected tool locations, policy modes, and request context.

Fig 10: Example detection via AGT

The dashboard then summarized block-mode findings, leading risk drivers, and tools that required review. This evidence can help a team prioritize policy changes and investigate repeated attacks.

Fig 11: Sample AGT metrics

AGT does not require this UI, gateway, or architecture. Its structured decisions can feed an admin console, SIEM, incident workflow, or approval queue.

AGT also includes an Agent Compliance package with mappings for OWASP and other controls. These mappings give developers and governance teams a common record of applied controls. Teams do not need to reconstruct the agent's behavior after an incident. Check Compliance - Agent Governance Toolkit for more information.

Conclusion:

MCP safety needs controls before and during execution. The Agent 365 CLI improves the MCP interface before deployment. It exposes unclear tool definitions, scores server maturity, and turns quality gaps into prioritized work. While AGT is implemented at the build phase, it provides developers the ability to test policy, identity, execution context & preserve evidence for allowed or denied decisions. Neither tool replaces secure server code, strong sandbox boundaries, or protected audit storage. Instead, they make those controls easier to evaluate and explain. Start with one MCP server and one consequential tool call. Evaluate the server with the Agent 365 CLI. Then put an AGT policy around the action that carries the most risk.

While these controls help secure the build phase of an agent, once agents move into production, runtime controls become essential. Agent365 provides those controls at runtime.

With thanks to Ashik Kuppil for his inputs and collaboration on this post.

Secure by default: Trusted Launch as Default is now Generally Available

ehassan — Mon, 03 Aug 2026 15:46:27 GMT

We are excited to announce that Trusted Launch as Default (TLaD) is now Generally Available for new Azure Generation 2 (Gen2) virtual machines (VMs) and virtual machine scale sets. With this milestone, new Gen2 deployments come up with Secure Boot and a virtual Trusted Platform Module (vTPM) enabled out of the box—raising the security baseline of your fleet automatically, and at no extra cost. TLaD is the default already for Portal, Powershell and CLI and now requires one-time registration to enable it by default for deployment scripts or tooling like ARM templates, Bicep, Terraform, or SDKs.

What is Trusted Launch?

Trusted Launch is a set of coordinated, foundational security technologies for Gen2 Azure VMs that protect against advanced, persistent threats—bootkits, rootkits, and kernel-level malware. Its core building blocks are:

Secure Boot – ensures only signed, trusted OS boot components (boot loader, kernel, drivers) can run, establishing a root of trust for your VM.
vTPM – a dedicated, isolated TPM 2.0 instance that safeguards keys, certificates, and secrets, and enables remote attestation of your VM's boot integrity.
Boot integrity monitoring with Microsoft Defender for Cloud – continuous attestation, health assessments, and alerting when a VM's boot state deviates from a trusted baseline.

Trusted Launch is supported on both x64 and Arm64 Gen2 sizes, across all public, Azure Government, and Azure China regions.

What is Trusted Launch as Default (TLaD)?

It is a fast, light weight way to improve the security posture of your new deployments without changing how you deploy.

Two important guarantees:

TLaD only affects new deployments. Existing VMs and scale sets already running in your environment are untouched.
TLaD never overrides your inputs. If your template or script explicitly sets a securityProfile, that value is always honored.

What's new at General Availability

TLaD is now fully supported for production use. Here's how the default applies across the tools you already use:

Deployment surface	Behavior at GA
Azure portal, Azure CLI, Azure PowerShell	New Gen2 VMs and scale sets default to Trusted Launch automatically—no registration required.
ARM templates, Bicep, Terraform, Azure SDK	New Gen2 VMs and scale sets default to Trusted Launch once you register your subscription for the feature.

In short: interactive tooling is secure by default today, and you can extend the same default to your infrastructure-as-code and SDK-based pipelines with a one-time subscription registration.

How to enable TLaD for ARM, Bicep, Terraform, and the SDK

To make Trusted Launch the default for deployments created through ARM templates, Bicep, Terraform, or the Azure SDK, register the TrustedLaunchByDefaultPreview feature under the Microsoft.Compute namespace on your subscription.

For more information, see Set up preview features in an Azure subscription.

💡 Note: Azure portal, CLI, and PowerShell deployments default to Trusted Launch regardless of whether the feature is registered. Registration is what extends the default to ARM/Bicep/Terraform/SDK deployments.

How the default behaves

Once your subscription is registered, run your existing deployment scripts and templates as-is. When you use Microsoft.Compute API version 2025-11-01 or higher, the absence of a securityProfile element in your deployment enables Trusted Launch by default for a new VM or scale set—provided all of the following are true:

The source Marketplace OS image supports Trusted Launch.

The source Azure Compute Gallery (ACG) image supports and is validated for Trusted Launch.

The source disk supports Trusted Launch.

The VM size supports Trusted Launch.

If one or more of these conditions isn't met, the deployment completes successfully as a Gen2 VM or scale set without Trusted Launch.

Need to opt out a specific workload?

We strongly recommend keeping Trusted Launch enabled—it's foundational compute security at no extra cost. If a specific workload has a dependency that isn't compatible (for example, an unsupported VM size, an unsupported feature such as managed images or Linux hibernation, or an OS that doesn't support Trusted Launch), you can explicitly opt out that deployment out by setting the securityType parameter to Standard.

Things to know

No additional cost. Trusted Launch doesn't increase your VM pricing.

Your existing resources are safe. TLaD applies only to new deployments; running VMs and scale sets aren't changed.

Your code wins. An explicit securityProfile in your deployment always takes precedence over the default.

Broad coverage. Available across all public, Azure Government, and Azure China regions, on both x64 and Arm64 Gen2 sizes.

To turn the default off for ARM/Bicep/Terraform/SDK deployments, unregister the TrustedLaunchByDefaultPreview feature under Microsoft.Compute. (Portal, CLI, and PowerShell continue to default to Trusted Launch regardless.)

Get started

📖 Trusted Launch for Azure VMs

🚀 Deploy a Trusted Launch VM

🔁 Enable Trusted Launch on existing VMs

❓ Trusted Launch FAQ

We want your feedback

Every new Gen2 VM you deploy now starts from a stronger security posture—automatically. That's secure by default, and it's here today.

Have a question for the community? Drop a comment below—we're reading.

Why AI Agents May Require a New Security Operations Model

pri2agarwalz — Mon, 03 Aug 2026 14:30:00 GMT

Organizations are rapidly adopting AI agents to retrieve data, invoke tools, automate workflows, interact with applications, and increasingly make decisions on behalf of users. As these agents become part of the enterprise workforce, they introduce an entirely new security surface.

A compromised endpoint can spread malware. A compromised identity can access sensitive data. A compromised AI agent can do both — while also reasoning, invoking tools, interacting with other agents, and executing actions at machine speed.

The challenge is no longer simply governing AI agents.

The challenge is securing them.

Why AI Agents Change Security Operations?

Traditional security operations were built around four primary subjects:

Users
Devices
Applications
Infrastructure

AI agents introduce a fifth. Unlike traditional applications, agents possess characteristics typically associated with both software and identities:

Characteristic	Why it matters
Identity	Acts for a user or via its own non-human identity
Instructions	Behaviour shaped by prompts, policies and context
Memory	May retain information across interactions
Data access	Retrieves organisational content
Tools	Invokes APIs, applications and MCP servers
Autonomy & relationships	May act without a human and delegate to other agents
External content	Retrieved content may influence later actions

The Agent attack surface

The real question is not only whether the model is attacked, but whether an instruction, identity, data source, tool or downstream agent can push the overall system outside its intended boundaries.

The New Agent Threat Landscape

As organizations adopt hundreds or thousands of agents, security teams must be prepared for a new class of threats:

Five agent incident scenarios

Illustrative scenarios, not reports of specific real incidents.

Scenario	What happens	Key Agent SOC questions
1 · Overprivileged HR agent	A policy-answering agent is wrongly granted access to salary data and returns it in response to an innocent question.	Which identity retrieved it? Was the user authorised? What classification applied? Was it returned to anyone else?
2 · Indirect prompt injection	A research agent retrieves a document with concealed instructions telling it to ignore its task and invoke a tool.	Which object injected the instruction? Did it separate data from commands? Did policy block it?
3 · Compromised MCP server	An approved agent connects to a tool whose server behaviour or responses are manipulated.	Which agents use it? What happened after the change? Were scoped credentials used? Can it be disabled in isolation?
4 · Agent-to-agent propagation	A planning agent delegates to a procurement agent that trusts its context and acts outside the user's scope.	Which agent started the chain? What authority was passed? Who is accountable? How far did it spread?
5 · Confident but unsupported action	An agent decides an alert is benign and remediates without sufficient evidence.	What evidence supported it? Was confidence recorded? Was approval required? Can it be reversed?

Traditional SOC detections rarely account for these scenarios. Organizations may eventually require agent-specific detections to address them.

The concept of an Agent SOC is still emerging, but the operational challenges it seeks to address are already becoming visible as enterprises deploy larger numbers of AI agents. As agents gain access to more data, tools, workflows, and decision-making responsibilities, organizations may need new security operations models designed specifically for autonomous systems.

What could an Agent SOC look like?

As AI agents become part of the enterprise workforce, organizations may need a new security capability, often thought of as an Agent Security Operations Centre (Agent SOC), focused on monitoring, detection, investigation, and response for agent-related threats

The mission is simple:

If organizations establish Agent SOC capabilities, their mission could be to:

Detect threats targeting AI agents

Investigate agent behavior

Contain compromised agents

Continuously improve security posture through operational learning

Potential capabilities of an Agent SOC

1. Agent Threat Detection

Detect indicators such as:

Prompt injection attempts
Suspicious tool invocations
Excessive autonomous actions
Unauthorized data access
Unexpected delegation chains
Behavioral anomalies
Privilege misuse
MCP server abuse

Traditional detections identify compromised users and devices. Future Agent SOC capabilities may need to identify compromised reasoning, unsafe autonomous behavior, and emerging forms of agent misuse.

2. Agent Behavioral Analytics

To effectively monitor agents at scale, organizations may eventually need to establish behavioral baselines for agents similar to how security teams baseline user behavior today. An Agent SOC would monitor:

Typical tool usage
Normal data access patterns
Expected workflow execution
Standard delegation behavior
Allowed communication paths

Deviation from normal behavior becomes a detection signal.

3. Agent Investigation & Forensics

When an incident occurs, analysts need answers quickly:

What initiated the action?
Which agent executed it?
Which identity was used?
What data was accessed?
What tools were invoked?
Which downstream agents were affected?
What business actions were taken?

Security teams may eventually require end-to-end investigation timelines that connect identity, data, tools, reasoning, and actions.

4. Agent Attack Path Analysis

Understanding an agent's permissions is only the beginning. Security analysts must understand:

Accessible systems
Connected tools
MCP dependencies
Data sources
Downstream agents
Potential blast radius

This creates visibility into how an attack could propagate across the agent ecosystem.

5. Threat Hunting for AI Agents

Modern SOCs perform proactive hunting. Future Agent SOC capabilities may include proactive threat hunting for agent ecosystems. Hunters search for:

Hidden delegation chains
Suspicious tool combinations
Recursive agent behaviors
Unusual data retrieval patterns
Excessive autonomy
Emerging AI attack techniques

The goal is identifying threats before incidents occur.

6. Agent Incident Response

Agent incidents require new containment options beyond traditional application shutdown. Organizations will likely require response mechanisms such as:

Suspend agent execution
Revoke privileges
Disable specific tools
Isolate MCP integrations
Block agent-to-agent communication
Restrict sensitive data access
Trigger additional approval requirements

Containment must be precise enough to stop risk without disrupting the entire environment.

7. Agent Security Intelligence

Every incident generates lessons. Over time, an Agent SOC could help organizations build intelligence around:

Attack techniques
Detection effectiveness
Emerging threat patterns
Tool abuse scenarios
Prompt manipulation techniques
Investigation outcomes

The result is an evolving security knowledge base for protecting AI systems.

The Agent SOC Operating Model

A future Agent SOC could operate as a continuous cycle:

Monitor → Detect → Investigate → Contain → Learn

Every investigation improves future detections.
Every incident strengthens operational resilience.
Every lesson feeds back into security operations.

If Agent SOC Teams Emerge, Who Might Be Involved?

The Agent SOC is inherently multidisciplinary:

Role	Contribution
SOC analyst	Triage and investigate agent alerts
Threat hunter	Spot abnormal tool, data and delegation patterns
Identity specialist	Investigate agent identities, tokens and permissions
Data security analyst	Assess sensitive-data access and exposure
AI engineer	Explain orchestration, prompts, tools and model behaviour
Application / agent owner	Validate business behaviour and accept remediation
Responsible AI specialist	Review transparency, safety and human oversight
Incident responder	Coordinate containment and recovery
Legal / compliance	Assess notification, evidence and regulatory impact

The Chief Agent Officer and the Agent SOC

Chief Agent Officer	Agent SOC
Owns enterprise agent strategy	Operates agent security monitoring
Governs the agent portfolio	Detects suspicious or unsafe behaviour
Defines accountability	Investigates incidents
Balances value and risk	Provides operational risk evidence
Decides when to scale or retire	Contains agents and recommends remediation

Governance and operations feedback loop

The simplest distinction: the Chief Agent Officer decides how the digital workforce should operate. An Agent SOC could provide the visibility needed to understand how the digital workforce is actually operating.

Why Existing SOCs May Not Be Enough?

Most security operations centres were built to monitor users, devices, applications, and infrastructure. AI agents blur those boundaries. They can access data, invoke tools, make decisions, interact with other agents, and act autonomously. Traditional security telemetry may show what happened, but often not why an agent made a decision, what instructions influenced it, or how actions propagated across an agent ecosystem. As organizations deploy larger digital workforces, these gaps may require new security approaches, new visibility models, and potentially dedicated Agent SOC capabilities.

Closing

Organisations didn't build SOCs because every user was malicious — they built them because mistakes, misuse, compromise and unexpected behaviour are inevitable at scale. The same applies to agents: the more authority they receive, the less acceptable it is to rely on trust without visibility.

The purpose of this article is not to suggest that Agent SOCs already exist as a mature discipline. Rather, it is to highlight a growing reality: AI agents are introducing new identities, behaviors, trust relationships, and attack paths that traditional security operations were never designed to monitor.

As organizations move from deploying a handful of agents to managing hundreds or thousands of autonomous systems, they may need new operational models, new telemetry, and new investigative capabilities focused specifically on agent behavior.

Whether this evolves into a dedicated Agent SOC, an extension of the existing SOC, or an entirely different operating model remains to be seen. What seems increasingly clear is that securing AI agents will require more than governance alone. It will require visibility, detection, investigation, and response capabilities designed for an autonomous digital workforce.

From AI Experiments to Digital Workforce: Do Enterprises Need a Chief Agent Officer?

pri2agarwalz — Mon, 03 Aug 2026 13:35:39 GMT

As organizations move from deploying a handful of AI copilots to managing fleets of task-specific agents, a new challenge is emerging - Ownership.

Today's AI agents can do far more than answer questions. They can access enterprise data, invoke tools, interact with business systems, collaborate with other agents, and perform actions on behalf of users. In many ways, they are starting to resemble a digital workforce rather than traditional software.

The problem is that responsibility for these agents is often fragmented. IT manages the platforms. Security manages risk. Compliance manages regulatory concerns. Business teams own the use cases. Developers build and maintain the solutions. Yet no single function is accountable for the overall health, governance, and lifecycle of the organization's growing agent population.

As adoption accelerates, this can create familiar problems:

Agent sprawl as new agents are created faster than they can be discovered or governed.
Ownership gaps when creators change roles or leave the organization.
Duplicate agents solving the same problem in different parts of the business.
Permission creep as agents gain access to more data, tools, and systems over time.
"Zombie" agents that remain active long after their original purpose has disappeared.
Difficulty measuring whether agents continue to deliver business value.

This leads to a simple but important question:

Who is responsible for the enterprise agent workforce?

Most organizations already have leaders responsible for technology, security, data, governance, and AI strategy. The question is whether anyone is accountable for the agent portfolio itself. As agents become a larger part of enterprise operations, organizations may eventually need a function responsible for managing agents as a workforce rather than simply as software.

One possible answer is the emergence of a new leadership role: the Chief Agent Officer (CAO).

The idea is not to replace the CIO, CISO, Chief Data Officer, or Chief AI Officer. Instead, it is to provide portfolio-level ownership of AI agents across the organization. While existing leaders focus on technology, security, data, or business outcomes, the CAO would focus on the intersection of all four through the lens of agent operations.

If a CAO Emerges, What Might the Role Look Like?

If organizations adopt a Chief Agent Officer model, the role could focus on six areas of responsibility supported by visibility into the health, risk, and value of the agent portfolio.

1. Agent Strategy & Portfolio Management

Maintain a clear view of where agents should be used, where capabilities overlap, where human oversight is required, and which agents should be built, reused, scaled, or retired.

Measures

Active, inactive, and retired agents
Duplicate or overlapping capabilities
Ownership and risk distribution
Agents awaiting review or attestation

The goal is not more agents. It's the smallest effective portfolio of trustworthy agents.

2. Ownership & Accountability

A CAO could help ensure every production agent has a defined owner, purpose, risk classification, approved data sources, operating boundaries, review schedule, and retirement plan.

Measures

Agents without valid sponsorship
Agents missing ownership or reviews
Orphaned or abandoned agents
Ownership coverage across the portfolio

3. Authority & Access Governance

Ensures all agent's permissions align with its intended role and responsibilities.

Measures

Agents with privileged permissions
Access to sensitive data and critical systems
External communication capabilities
High-impact actions requiring approval

4. Lifecycle Governance

Manage agents through a structured lifecycle:

Propose → Assess → Approve → Build → Validate → Deploy → Operate → Review → Retire

Measures

Agents in each lifecycle stage
Overdue reviews and re-certifications
Retirement candidates
Lifecycle compliance rates

5. Value & Performance

Evaluate not only what agents do, but whether they create meaningful outcomes.

Key questions:

Did the agent complete the task?
Did it do so safely and correctly?
Did it deliver business value?

Measures

Business outcomes delivered
Human effort reduced
Quality and rework rates
Cost versus value delivered

6. Human-Agent Operating Model

Define the right balance of autonomy, oversight, approval, and accountability across the enterprise.

Measures

Human overrides and escalations
Actions completed with verified evidence
Unsupported actions or responses
Recurring failure patterns and trust indicators

The objective is simple: maintain a real-time view of what agents exist, who owns them, what authority they hold, what value they create, and whether they continue to operate safely, effectively, and responsibly.

In short, the Chief Agent Officer governs the enterprise's digital workforce the same way traditional leaders govern people, applications, and data.

Perhaps most importantly, the role would treat agents as assets with a lifecycle. Just as applications require governance from creation to retirement, agents may need structured processes for approval, deployment, monitoring, review, and eventual decommissioning.

The purpose of this article is not to suggest that organizations should immediately create a Chief Agent Officer role. Rather, it is to highlight a growing accountability challenge that may emerge as enterprises scale from a handful of agents to large digital workforces.

Whether organizations ultimately adopt the title "Chief Agent Officer" is less important than the underlying challenge it aims to address. As AI agents become embedded in everyday business operations, enterprises will need clear accountability for how these digital workers are governed, measured, and managed at scale.

The organizations that succeed with agentic AI may not be the ones that deploy the most agents. They may be the ones that can confidently answer five simple questions about every agent they operate:

What does it do? Who owns it? What can it access? What value does it create? And when should it be retired?

In the age of digital workforces, those questions may become just as important as the technology itself

Domain controller showing "Not ready for migration"

RyanSteele-CoV — Thu, 30 Jul 2026 20:52:18 GMT

I want to get the MDI sensor upgraded to v3 on our domain controllers. When I go into Settings > Sensors, two of our DCs are listed as "Ready for migration", but the third says "Not ready for migration".

As far as I can tell, this DC meets all the prerequisites listed at Migrate from sensor v2.x to sensor v3.x - Microsoft Defender for Identity | Microsoft Learn. In the Troubleshooting section of that article, it says "hover over the status on the Sensors page to see a tooltip that lists the reasons the server doesn't meet the migration prerequisites", but I see no such tooltip, no matter where I hover.

I tried opening a support request with Microsoft 365 Support, only to be told that I have to contact Azure support. We don't currently have an Azure support plan, so I guess we don't qualify for support.

Anyone got any suggestions for things I can try?

The Microsoft AI and Agent Platform — The Platform Behind Intelligent Agents

lmurthy — Wed, 29 Jul 2026 18:05:42 GMT

Why the platform around the model is the real enterprise differentiator

Enterprise AI has reached a turning point. Beyond answering questions, it can now reason over business context, retrieve knowledge, use tools, coordinate workflows, and act across enterprise systems. This shift raises a critical question: How can organizations build agents intelligent enough to transform work while ensuring they remain trusted, governed, and ready to operate at enterprise scale?

The answer is not a single model, chatbot, or orchestration framework. Foundation models are advancing quickly and increasingly becoming a commodity input — Azure AI Foundry alone provides access to more than 11,000 models. What determines enterprise value is not the model alone, but the platform around the model: the data that grounds it, the tools it can use, the experiences where people engage it, the runtime where it operates, and the enterprise foundation that gives it identity, context, governance, and operational control.

The Microsoft AI and Agent platform enables organizations to build, ground, govern, and operate AI apps and agents at scale, bringing together the full agent lifecycle with open development, built-in intelligence, and consistent security, compliance, and policy controls. One ecosystem, multiple experiences, shared intelligence, flexible build paths, multiple runtime choices, and an enterprise foundation that carries security, governance, compliance, and Responsible AI across the stack.

The reference mental model below expresses this as a layered platform — Users → Experiences → Agents → Intelligence → Runtime → Foundation with security, governance, compliance, and Responsible AI applied across every layer.

An agent that is brilliant but ungoverned never leaves the pilot stage. An agent that is locked down but context-blind never delivers real value. Impact compounds only when both dimensions advance together, on the same platform, so that intelligence and control share one identity model, one data plane, and one control plane.

Part 1 — Intelligence (this post): dives into how Microsoft's platform helps organizations build agents that understand work, reason over trusted context, and act through business systems to deliver real business value.
Part 2 — Trust: will go deeper on how those agents are secured, governed, monitored, and managed across their lifecycle.

Intelligence + Trust = Frontier Transformation

Part 1: Intelligence

Most enterprise AI programs begin with model experimentation - prompts, model comparisons, prototypes, accuracy evaluations. That is necessary but not sufficient. A model alone does not know your organization, your processes, your permissions, your systems of record, your compliance obligations, or your operating model.

Experience layer: meet users where work already happens

Agents deliver value only when they reach people in the flow of work.

Enterprise AI adoption rarely happens through a single interface or experience. A sales leader, financial analyst, security operator, developer, field technician, and HR specialist do not need the same interface they need agents surfaced in the tools and workflows they already use.

Microsoft's approach is not to force every agent into one portal. The platform supports multiple experiences over a shared foundation:

Microsoft 365 Copilot for productivity and business users.
Security Copilot for security operations.
Azure Copilot for IT operations, cloud, and infrastructure.
GitHub Copilot for developers.
Dynamics 365 experiences for sales, service, finance, and supply chain workflows.
Power Platform and Copilot Studio experiences for business applications and low-code extensions.
Custom experiences for line-of-business apps, portals, websites, and industry-specific workflows.

Regardless of where users engage, the underlying intelligence, governance, and runtime capabilities remain consistent across experiences.

Agent layer: specialize by domain, tools, and autonomy

Specialization with a shared substrate

Generic agents often fail because enterprise work is domain specific. A security agent must understand incidents, alerts, identities, and threat intelligence. A finance agent must understand reconciliations, receivables, approvals, and controls. A developer agent must understand repositories, branches, pull requests, tests, and pipelines.

Microsoft's platform supports both prebuilt domain agents and custom agents. Organizations should leverage the domain specific agents where possible and focus custom development on capabilities that create unique business value. Whether an agent is out of the box or custom, it inherits the same governance, so built-in and custom are never two different compliance islands.

Agent systems form an autonomy spectrum, allowing organizations to progressively increase capability while maintaining appropriate levels of human oversight.

Assistive: The agent recommends; a human decides. Example - A finance agent drafts a reconciliation for review.
Supervised autonomy: the agent acts within bounded authority and escalates exceptions. Example - An SRE agent auto-remediates known alert classes and escalates novel incidents.
Multi-agent orchestration: A coordinating agent decomposes a goal and delegates to specialist agents. Example - One agent retrieves data, another analyzes it, another drafts a response, and another executes an approved action.

Intelligence layer: grounding as a first-class platform tier

An agent is only as good as the context it can reason over.

The hardest part of building a useful enterprise agent is not calling a model. It is giving the agent the right context. Without trusted context, agents produce generic answers. The IQ Platform is the intelligence fabric that separates enterprise-grade agents from generic AI assistants. A generic model can answer questions based on its training data or a narrow retrieval source. A Microsoft agent, by contrast, can be grounded in multiple dimensions of your organizational intelligence: how people work, what business data means, which knowledge is authoritative, and what external signals matter. With the right intelligence fabric, agents become role-aware, process-aware, data-aware, and policy-aware. Microsoft's IQ model treats grounding as a reusable platform capability rather than per-project plumbing.

IQ layer	What it gives agents	Why it matters
Work IQ	Collaboration context: people, skills, meetings, documents, decisions, workflows, and organizational relationships.	Helps agents understand how work actually happens, not just what content exists.
Fabric IQ	Governed business data, metrics, semantic models, and analytical context.	Helps agents reason over trusted enterprise data with consistent business definitions.
Foundry IQ	Models, curated knowledge, retrieval assets, memory, guardrails, and AI development capabilities delivered from Microsoft Foundry with plug-and-play memory, knowledge, and tool integrations.	Helps teams build reliable, purpose-built agents with governed model and knowledge choices.
Web IQ	Public web, current external signals, research, news, and external context.	Helps agents augment internal context with timely external intelligence.

In a conventional application, data access is deterministic queries against known schemas. In an agentic system, the equivalent tier must serve retrieval for reasoning, semantically matching an ambiguous natural-language intent to the right passages, records, and metrics across unstructured collaboration content, structured business data, curated knowledge, and the live web. The four IQ sources correspond to those four retrieval modalities, and the IQ Platform gives agents a composable intelligence model. Each IQ layer adds a distinct signal, and together they allow agents to move from simple assistance to informed action.

Intelligence is more than model capability. It emerges from the combination of grounding, memory, model selection, orchestration, and guardrails working together as a coordinated system.

Grounding, fine-tuning, and adaptation

Microsoft gives teams multiple adaptation levers within a governed environment rather than forcing every use case into one technique. Grounding is not a sidecar retrieval capability; it is an enterprise intelligence layer. Because the model layer is a platform tier rather than a single endpoint, adaptation techniques fine-tuning, distillation into smaller task models, and retrieval-augmented grounding are first-class options selected per workload. The common pattern: prefer grounding (RAG) for freshness and provenance, reserve fine-tuning for durable behavior, format, or domain-tone requirements, and distill to smaller models where latency and cost dominate.

Memory

In addition to retrieval and reasoning, enterprise agents increasingly rely on memory to preserve context across conversations, tasks, and workflows. Memory enables agents to maintain continuity, learn from prior interactions, and provide more personalized, adaptive, and goal-oriented experiences over time.

Multi-model choice

Agent workloads are not uniform. Some steps require simple classification. Others require complex reasoning, synthesis, code generation, or tool orchestration. Model choice is becoming a strategic architecture decision, balancing quality, latency, cost, sovereignty, and specialization requirements. Microsoft Foundry supports model choice as part of the platform rather than forcing all workloads through one endpoint with a curated catalog of leading foundation, open-source, and partner models spanning capabilities, performance trade-offs, and use cases so teams can move from experimentation to production confidently.

Model routing

Microsoft Foundry's Model Router selects the optimal LLM for each agent request per turn, not per session — a simple greeting can route to a fast, inexpensive model, while a complex tool-calling chain can route to a frontier model, all through one endpoint with zero routing logic. Model selection becomes a runtime policy, not hard-coded application logic providing automatic failover when an upstream provider is unavailable, prompt caching across models for identical inputs, and consistent tool-use semantics regardless of which underlying model handles a call. Key routing capabilities include per-request optimization, complexity-aware model selection, tool-aware routing, multi-agent support, resiliency, and cost optimization.

Orchestration

Orchestration transforms individual model interactions into coordinated agentic and multi-agent workflows. An LLM-driven planning layer that interprets user intent, breaks down complex requests, selects the right tools and knowledge, and executes multi-step plans and multi-agent workflows with guardrails for safety and compliance.

Guardrails

A guardrail is a named collection of controls; each control defines a risk to be detected, intervention points to scan the risk, and the response action to take when the risk is detected. Guardrails help ensure that agent behavior remains aligned with organizational policies, safety requirements, and business objectives.

How agents are built: one continuum from no-code to pro-code

Different builders. Different depth. One platform.

The progression from no-code to low-code to pro-code is more than a tooling choice; it reflects increasing levels of customization, control, and organizational maturity. Different teams need different levels of control. A business user may need a simple knowledge agent. A process owner may need a workflow agent with connectors and approvals. An engineering team may need a custom multi-agent system with model routing, evaluation, tool use, and deployment automation. Organizations can start with simple productivity agents, evolve into governed workflow agents, and eventually build deeply integrated agentic systems.

No-code - M365 Agent Builder: create simple agents from natural language and your organizational data. This is useful for lightweight departmental workflows, knowledge assistants, and task-specific copilots.
Low-code - Copilot Studio: design, extend, and orchestrate agents with connectors, workflows, and enterprise governance. This is where business technologists and app makers can build more sophisticated agents that integrate with systems, automate processes, and enforce organizational rules.
Pro-code - Microsoft Foundry: enables developers to build custom AI systems with full control over models, orchestration, infrastructure, and code. This is where organizations can build highly specialized agents with advanced reasoning patterns, custom retrieval, tool use, evaluation pipelines, and deployment strategies.

The key principle is continuity; moving from no-code to low-code to pro-code should not require rethinking the architecture. Identity, grounding, governance, policy, and operational controls should carry forward including centralized identity and policy enforcement. Regardless of the development approach, the same intelligence, runtime, governance, and operational capabilities can be reused across the platform.

Where agents run: one platform, multiple runtime choices

Match the runtime to the requirement

A mature enterprise platform must support more than one runtime pattern. Some agents need elastic cloud scale. Others need local execution because of latency, data sensitivity, offline operation, or regulated environments. Some need to interact with legacy applications that do not expose APIs. Runtime should be selected based on business, operational, and regulatory requirements rather than tooling limitations. Build path and runtime path should vary independently over a shared foundation.

The ability to deploy the same agent architecture across multiple runtime environments helps organizations balance performance, compliance, and operational flexibility.

Local / edge (Foundry Local, Windows AI): Local or edge execution supports scenarios where data sensitivity, latency, offline access, regulatory requirements, disconnected operation or device-specific context matter. Examples include on-device models, Windows AI capabilities, and local execution for regulated or disconnected environments.
Cloud runtime (Azure / Copilot stack): supports scalable, API-driven agents with multi-agent orchestration running in Azure and Copilot with the default for enterprise workflows, multi-agent orchestration, connected systems, and data-connected scenarios that need elasticity.
Cloud PC (Windows 365 agents): enables agents to operate in managed desktop environments. agents run on a Windows 365 Cloud PC using a check-out/check-in model, driving UI automation, browsers, and legacy apps as a human operator would in a managed and governed environment. This is the bridge to systems that expose no API, the agent operates the actual application UI in a governed, isolated desktop.

Foundation layer: shared trust fabric

The enterprise foundation for intelligence and trust

The same enterprise services that secure, govern, and operate modern organizations now extend to agents, creating a shared foundation for both intelligence and trust. This inheritance model allows organizations to extend existing investments in identity, governance, security, compliance, and operations directly to agent systems rather than introducing a separate control model for AI. Key foundation services include:

Microsoft Graph – Provides agents the context across users, groups, files, meetings, messages, relationships, and activity signals. It gives agents a permission-aware understanding of work, not just isolated documents.
Microsoft Entra – Agents are governed using the same identity fabric that governs users, devices, apps, and resources enabling role-based and attribute-based access control plus risk-based Conditional Access policies.
Microsoft Fabric - Governed data, analytics, semantic models, and business metrics. Foundry includes SharePoint and Microsoft Fabric among its built-in tools. Agents reason over trusted business definitions instead of disconnected raw tables.
Microsoft Purview - Data protection, sensitivity labeling, DLP, compliance, and governance. Agent 365 uses Microsoft Purview for data protection and compliance controls on agent activity and data, complementing Microsoft Defender for threat detection and behavior monitoring. Agent interactions inherit enterprise compliance expectations.
Azure - Provides enterprise-grade cloud infrastructure and operational maturity. Foundry emphasizes centralized observability, traces, evaluated runs, and production performance monitoring with full traceability for enterprise-scale security, audit, and compliance requirements.
Microsoft 365 - Brings agents into the tools where employees already work. Agents can be surfaced in the productivity tools users already leverage.
Dynamics 365 - Business application context for sales, service, finance, supply chain, and operations. Grounds agents in business processes and systems of record.
Power Platform - Low-code apps, automation, connectors, and business process integration — reachable via Foundry through Azure Logic Apps integration with more than 1,400 connectors. Business technologists can extend agent workflows without building everything in code.
GitHub - Developer workflows, repositories, pull requests, code context, and DevOps integration. Extends agentic assistance into software development lifecycle.
Windows & Windows 365 - Endpoint and Cloud PC environments for local, desktop, and legacy app scenarios. Extends agent reach beyond APIs into managed desktop execution patterns.

Alongside these services, Agent 365 and the Foundry Control Plane provide the trust layer for enterprise agents, combining security, governance, compliance, and Responsible AI with centralized visibility, policy enforcement, lifecycle management, and secure AI operations from development through production.

End-to-end request journey: how the layers work together

The true value of the platform emerges when all the layers work together as a coordinated system. Intelligence emerges from the combined effect of experience, domain specialization, grounding, memory, models, orchestration, runtime, and foundation. An example request, from a user - “Reconcile last month's receivables and flag anomalies for my region."

Experience - The user asks from Microsoft 365 Copilot or a finance workflow surface, the agent is reached through the same stable endpoint used across Microsoft 365 and Teams.
Identity context - The platform attaches user identity, and, for the agent, its Microsoft Entra Agent ID assigned in Foundry.
Agent selection - A finance agent interprets the goal. If the request spans domains, Copilot Studio generative orchestration decomposes it into a plan, choosing tools, topics, knowledge sources, or connected agents.
Grounding - Fabric IQ provides receivables data and metric definitions; Work IQ provides relevant approvals and prior decisions; Foundry IQ provides reconciliation rules and policy knowledge; Web IQ can add external signals when needed.
Model routing - The Foundry Model Router selects the model per turn. A simple classification step goes to a nano-tier model; anomaly reasoning routes to a mid-tier model; multi-document synthesis routes to a frontier model, all through one endpoint with zero routing logic.
Guardrails - Foundry guardrails scan user input, tool calls, tool responses, and final output for defined risks and take the configured action (annotate or annotate-and-block).
Tool use - The agent queries systems, invokes reconciliation logic, runs anomaly detection, or calls another specialist agent via Copilot Studio connected agents or Foundry's MCP integration.
Runtime execution - The workflow runs in cloud, local, or Windows 365 Cloud PC environments depending on system access, data sensitivity, latency, and legacy application constraints.
Response - The agent returns a reconciled view, flagged anomalies, rationale, and recommended next steps — with citations pulled from the knowledge layer for transparency.
Bridge to Trust - Every action generated by the agent remains observable, governable, and auditable through the platform's trust capabilities, which are explored further in Part 2.

Conclusion

The hard problem in enterprise AI was never obtaining a capable model; it was grounding that model in governed enterprise context, enabling it to act through governed tools, and doing so within the security, compliance, and operational controls organizations already rely on. Microsoft's answer is a platform approach: a dedicated grounding tier through the IQ Platform, a flexible intelligence layer spanning models, memory, routing, orchestration, and guardrails, specialized agent families aligned to business domains, a build-to-run continuum spanning no-code to pro-code, and a shared trust foundation that every agent inherits.

Integrate once with this fabric, and the payoff compounds: one identity model, one grounding tier, and one governance spine become reusable across every persona surface, every agent family, every build-and-run target.

Coming next — Part 2: Trust

Intelligence is only half the equation. In Part 2 we turn to the other axis: how Microsoft secures and governs every component of an agent - models, tools, MCP connectors, memory, and orchestration across the full lifecycle.

Securing AI Agents at Runtime: Real-Time Protection and Threat Detection for Microsoft Agent 365

llevy — Mon, 27 Jul 2026 17:37:49 GMT

Organizations are rapidly adopting AI agents to automate workflows, access enterprise data, invoke tools, and take actions on behalf of users. This autonomy creates a fundamentally new security challenge.

Unlike traditional AI applications, agents operate across dynamic execution flows, interacting with external content, calling tools, and accessing sensitive resources. These interactions create new attack paths that traditional security controls were not designed to address.

Today, we're announcing two major milestones for Security for AI in Microsoft Defender for Microsoft Agent 365:

Threat detection for Microsoft Agent 365 agents — now in public preview.

Real-time protection for Microsoft Agent 365 tooling servers — now generally available.

Together, these capabilities help security teams detect, investigate, and block attacks targeting AI agents, extending Microsoft Defender's threat protection capabilities into the agent runtime.

Threat detection for Microsoft Agent 365 Agents (Public Preview)

Threat detection provides SOC teams with detailed visibility into attacks and suspicious activity targeting AI agents. By analyzing runtime signals across agent interactions, tool usage, and execution patterns, Microsoft Defender identifies suspicious and malicious behavior throughout the agent execution lifecycle and surfaces actionable security alerts for SOC teams.

Threat detection supports cloud agent types that emit observability logs to Microsoft Agent 365, including:

Microsoft Copilot Studio

Microsoft Foundry

Microsoft 365 Copilot Agent Builder

Agents integrated through the Microsoft Agent 365 SDK

This provides consistent threat visibility across supported Microsoft Agent 365 agent experiences, regardless of how the agent was built.

Fig. 1. Microsoft Security for AI alerts in Microsoft Defender XDR (Preview)

Microsoft Defender identifies a broad range of AI-specific threats, including:

Indirect prompt injection (XPIA) — malicious instructions embedded in external content designed to manipulate agent behavior.

Evasion techniques — attempts to bypass agent instructions or security controls.

Malicious content propagation — attempts to use agents to generate or distribute malicious content.

Secret leakage — exposure of credentials, API keys, or other sensitive information through agent interactions.

LLM reconnaissance — attempts to probe agent capabilities, instructions, or security boundaries.

Suspicious IP access — agent access originating from anonymized or suspicious IP addresses.

Alerts are surfaced directly in Microsoft Defender, enabling SOC analysts to investigate and respond using familiar workflows, Advanced Hunting queries, and the Defender XDR investigation experience.

Real-time protection for WorkIQ and Custom MCP servers (General Availability)

Real-time protection moves beyond detection by blocking threats inline when AI agents interact with WorkIQ and custom MCP servers (see Microsoft Agent 365 tooling servers).

When an agent invokes a registered tool or receives a tool response, Defender evaluates the interaction against configured security policies and determines whether to allow or block it directly within the agent's execution flow.

This helps prevent malicious actions and data leakage in real time, without requiring agent developers to implement custom security logic.

Fig. 2. Microsoft Security for AI Real-Time Protection policy in Defender

Real-time protection currently guards against high-impact threats, including:

Evasion techniques — attempts to bypass agent guardrails or security controls.

Malicious content propagation — preventing agents from spreading malicious content through tool actions.

Secret leakage — blocking agents from inadvertently exposing credentials or sensitive data through tool calls.

Communication with untrusted domains — preventing agents from sending email or data to high-risk or untrusted email domains.

Better Together: Detection and Protection

Threat detection and real-time protection address complementary parts of the agent security lifecycle.

Real-time protection provides inline enforcement to block malicious interactions during execution, while threat detection gives SOC teams the visibility and investigation context needed to identify attack patterns, assess impact, and respond to suspicious activity.

Together, they provide a defense-in-depth approach that combines runtime enforcement with SOC-driven detection and investigation, purpose-built for AI agents.

Getting Started

Both capabilities are available through Microsoft Defender, using a dedicated Security for AI workload experience that brings together AI threat detections, investigations, and runtime protection policies.

To learn more:

Enable security for AI agents using Microsoft Defender

Detect and investigate threats to AI agents using Microsoft Defender (Preview)

Protect AI agents in real time using Microsoft Defender

As AI agents become more autonomous and gain access to enterprise data and tools, securing their runtime behavior becomes critical. With Threat Detection and Real-Time Protection, Microsoft Defender helps organizations adopt AI agents with security controls designed for how agents actually operate—detecting attacks, enabling SOC investigation, and blocking malicious interactions at runtime.

Level Up Your Security Skills This August with the Microsoft Defender Challenge and Learn Live

ShirleyseHaley — Mon, 27 Jul 2026 16:47:02 GMT

Security teams face an increasingly complex landscape. Threats span identities, endpoints, email, cloud workloads, and emerging AI environments. The best defenders aren't just reacting to threats—they're continuously building the skills needed to stay ahead.

That's why we're inviting security practitioners to build practical security operations expertise while working toward their next certification goal. Running from July 20 through August 21, 2026, and focused on skills across Microsoft Defender XDR, Microsoft Sentinel, and Microsoft Defender for Cloud, this hands-on learning experience is the Microsoft Defender Challenge.

Build Skills That Matter to the Modern SOC

The Microsoft Defender Challenge isn't about memorizing content for an exam. It's designed to help you develop real-world security skills you can apply immediately in your organization. Through curated Microsoft Learn content, you'll strengthen your ability to:

Detect, investigate, and respond to threats across Microsoft Defender XDR

Manage incidents and automate workflows with Microsoft Sentinel

Triage and remediate security alerts in Microsoft Defender for Cloud

Secure cloud and AI workloads using modern security practices

Improve operational readiness for today's evolving threat landscape

Whether you're a SOC analyst, security engineer, cloud security practitioner, or IT professional looking to expand your security expertise, the challenge is an opportunity to sharpen skills that map directly to modern security operations.

Complete the Challenge and Enter the Sweepstakes

Learning is the real reward, but there's an added incentive. Participants who complete the Microsoft Defender Challenge and submit the official sweepstakes entry form by August 21, 2026 will have the opportunity to win one of 500 certification exam vouchers worth 50% off one of the following Microsoft Certifications:

SC-200: Microsoft Security Operations Analyst

SC-500: Microsoft Cloud and AI Security Engineer

How to Enter

Complete the Microsoft Defender Challenge on Microsoft Learn.

Before the entry period closes, submit the official sweepstakes entry form.

If selected, you'll receive instructions for redeeming your certification discount voucher.

Challenge window: July 20 – August 21, 2026. Sweepstakes entry deadline: August 21, 2026 at 11:59 PM UTC.

No purchase necessary. See official rules for eligibility and sweepstakes details.

Join Learn Live: Remediating Threats Using Microsoft Defender

Want a guided walkthrough of the skills featured in the challenge? Join a live, interactive event where you can learn directly from Microsoft experts, ask questions in real time, and explore security operations scenarios together. Save your spot for our August Learn Live session.

Date: Wednesday, August 19, 2026 | Time: 12:00 PM PT / 3:00 PM ET

You'll be guided by Scott Landry, Microsoft Security Customer Experience Engineering, as you explore practical approaches to investigating security incidents, managing and remediating threats across the Microsoft Defender ecosystem, automating investigations and response actions, strengthening security operations processes, and applying Microsoft Defender capabilities to real-world scenarios.

Start Building Your Skills Today

Ready to level up? Sign up today to take the Microsoft Defender Challenge, then join us for the Learn Live session on August 19. Your skilling journey doesn't end here—keep learning, keep growing, and keep building beyond August at the Security Hub on Microsoft Learn.

How Nationwide stays ahead of attackers with Project Perception

julievanloef — Mon, 27 Jul 2026 12:30:00 GMT

Nationwide, the world’s largest building society, is among the first organizations to put Microsoft’s new agentic security system to work. Facing adversaries who now regularly weaponize AI, the society is using Project Perception’s coordinated multi-agent defense—red, blue, and green agents working alongside its analysts—to find and remediate threats faster, while its security experts stay firmly in command. Their team has already seen work that once took weeks compressed into hours.

Defending against AI-driven threats

Nationwide Building Society is a member-owned mutual serving 19 million members across the UK, and that responsibility is becoming increasingly complex as AI reshapes the threat landscape. Attackers can now scale campaigns faster and automate more of their operations. "AI is giving attackers a real advantage over defenders in terms of pace and scale," says David Boda, Chief Security and Resilience Officer.

For its security teams, the mission is clear: protect the customers who trust the organization with some of the most important aspects of their lives. "The things that matter most are protecting their money, protecting their livelihoods." says Tim Russell, Cybersecurity Director.

For Nationwide Building Society, keeping pace means human-led, agent-driven defense that helps its team act faster, together and stay ahead.

Coordinated multi-agent defense, built on Microsoft Security

Nationwide Building Society’s response is to get ahead of the change in the threat landscape—identifying potential risks faster and accelerating response across its environment. Building on Microsoft Defender, which its teams have run for years, the society adopted Project Perception to bring coordinated multi-agent defense into its existing operations. "This solution for multi-agent defense allows us to move to a more proactive way of working," says Boda.

The system puts specialized agents to work as a team. "Red agents are offensive cyber agents used to explore the vulnerabilities and the attack paths in our environment. Blue agents are the defensive agents and reflect the work that a security operation center analyst might do," Boda explains, while green agents remediate and harden—with people in command throughout. "The power of the solution is it brings those agents together to achieve a better cybersecurity posture."

For analysts, that coordination removes long-standing friction. "We're able to use agentic workflows to identify threats and then track them through into remediation, which previously we would've had to have engaged with a number of different tools to achieve," says Russell.

Human-led, agent-driven defense

The impact is already tangible. "My team came to me and said, look, we've just taken four weeks of threat intelligence analysis and collapsed that down into four hours—and for me, that was the moment that really brought this to life," Boda recalls. Just as important to Nationwide Building Society is what the technology does for its people. "This technology helps to amplify their skill sets, not to replace them," says Russell.

For Nationwide Building Society, the future is humans and agents working as one. "Agents can work twenty-four-seven, but as humans, we can't do that. So, by harnessing humans and agents operating together, we can achieve so much more collectively," says Boda. And the ambition reaches further than the society itself: "Being able to develop this solution together with Microsoft allows us not just to protect Nationwide Building Society, but also to protect wider society—and that feels really positive."

Best practices for maintaining emergency contact information

TIauxiliar — Wed, 22 Jul 2026 17:53:18 GMT

Hello everyone.

Our organization is currently reviewing its emergency contact directory as part of our business continuity and operational processes.

What best practices do you recommend for keeping emergency contact information updated and ensuring it remains available during incidents or emergencies?

Thank you for your suggestions.

How to see which users only implement the pincode in Windows Hello?

Khalid Hajjouji — Mon, 20 Jul 2026 11:46:24 GMT

We rolled out Windows Hello for Business in the whole organisation. All users see a Windows Hello for Business wizard where the at least need to implement the pincode. It is possible to implement also the fingerprint or face recognizing. How can I generate some report where I can see the implemented Windows Hello methods? We would like to contact everybody who only implemented the pincode to do some user adoption.

Custom Detection Rules as Code in Sentinel Repositories: What Your Pipeline Owns Now

Marcel_Graewer — Sun, 12 Jul 2026 10:32:08 GMT

While going through the June Sentinel updates I almost scrolled past this one, and I think that would have been a mistake: custom detection rules can now be managed as code in Sentinel Repositories, the same way analytics rules, playbooks, parsers and workbooks already are. You connect a GitHub or Azure DevOps repo, enable the Custom Detection Rules content type, and rules are synced on every commit. There is also a standalone path via the Bicep CLI for teams running their own pipelines.

The feature is in preview per the Learn documentation, and in my view it matters more than the low-key rollout suggests. Microsoft has been positioning custom detections as the unified experience for building rules over both Defender XDR and Sentinel data since late 2025. If custom detections are becoming the primary detection type, then this preview is the moment your primary detection type becomes pipeline-managed. I spent some time in the documentation to understand what that actually means, and there is one implication I have not seen anyone talk about yet.

How it works

Custom detection rules use a different mechanism than every other content type in Repositories. Analytics rules deploy as Microsoft.OperationalInsights/workspaces/providers/alertRules resources, with the Microsoft.SecurityInsights provider sitting in the resource name. Custom detection rules instead use a dedicated Bicep extension. You declare it in a `bicepconfig.json` at the repo root:

{ "extensions": { "MicrosoftSecurity": "br:mcr.microsoft.com/bicep/extensions/microsoftsecurity:v1.0.1" } }

The rule itself is a `Microsoft.Security/detectionRules` resource. This is the structure from the Microsoft documentation:

extension MicrosoftSecurity resource detectionRule 'Microsoft.Security/detectionRules@2026-06-01-preview' = { id: 'custom-rule-id' displayName: 'Custom Rule Display Name' status: 'enabled' queryCondition: { queryText: 'DeviceProcessEvents | take 10 | project DeviceId, Timestamp, FileName' } schedule: { frequency: 'PT1H' } detectionAction: { alertTemplate: { title: '<ruleTitle>' description: 'Custom detection rule' severity: 'medium' tactics: [ { tactic: 'Execution' techniques: [ { technique: 'T1059' } ] } ] entityMappings: { hosts: [ { id: 'h' deviceIdColumn: 'DeviceId' } ] } } } }

Rules are uniquely identified by the `id` property, which you provide in the template. Deployment is either the automatic Repositories sync or a plain `az deployment group create` against a resource group. That last part is what I like most about the design: any CI/CD system that can run Azure CLI can ship these rules.

Prerequisites beyond the standard Repositories setup: a Microsoft 365 E5 license or equivalent that includes Defender XDR, and a Sentinel workspace onboarded to the Defender portal. Two preview limitations are documented: custom frequency for Sentinel-only data is not supported yet, and neither are custom details.

The part that made me stop reading and think

Repositories are designed as the single source of truth. The documentation is explicit that content in your repo overwrites changes made through the portal. That is the whole point of the feature, and for analytics rules it has been mostly harmless. For custom detections I see a wrinkle.

When Microsoft renames tables or columns in the advanced hunting schema, those naming changes are applied automatically to queries saved in Microsoft Defender, including the queries inside custom detection rules. The docs are equally explicit that this automatic migration does not cover queries run via API or saved anywhere outside Defender. A Git repo is outside Defender.

Play that forward with a current example. The `AIAgentsInfo` table stopped being accessible on July 1, 2026, replaced by the unified `AgentsInfo` table with a changed column set. A portal-managed custom detection referencing the old table got migrated automatically. The same rule managed as code did not, because the authoritative copy of the query now lives in your repo, and nothing in the sync path rewrites your Bicep files. Your repo is now the thing standing between Microsoft's server-side fix and your production detection. Either the sync starts failing, or the stale query gets reasserted over the migrated rule. The documentation does not say which of the two happens, and honestly, neither is good. No alert fires for either.

And if smart deployments, which skip files that have not changed since the last deployment, apply to this content type the same way they do to the rest of Repositories, it gets slightly worse in a way I find almost funny: a stale rule would sit untouched until someone happens to edit it.

What I would put in front of the merge

To be clear, none of this is an argument against the feature. I want detections in Git, and I suspect most people reading this do too. It is an argument that moving custom detections into a repo moves the schema lifecycle responsibility into your review process, because the portal safety net explicitly does not reach into source control. Concretely, a PR touching detection content should be checked for references to deprecated or transitioning advanced hunting tables, for the result columns the custom detection docs recommend (`Timestamp` or `TimeGenerated`, plus `DeviceId` or `DeviceName` for Defender for Endpoint tables, plus `Timestamp` and `ReportId` from the same event for the other Defender tables), and for complete entity mappings, since entities drive how alerts group into incidents. One more detail from the custom detection docs that I suspect will trip up people coming from analytics rules, because it goes against years of muscle memory: avoid filtering on `Timestamp` or `TimeGenerated` in the query itself. The service prefilters data based on the detection lookback using ingestion time. The scheduled-analytics-rule reflex of always pinning a time window works against you here.

Whether you enforce these checks with a homegrown script or a linting step in the pipeline matters less than doing it before merge rather than discovering it in the alert queue. The deployment mechanics are now solved. The content governance is yours. Full transparency: I have worked through the documentation and the sample content, but I have not yet run a retired-table scenario through the sync myself. So if you are testing the preview, I would genuinely like to hear how it behaves in your environment when a repo-managed rule references a table like `AIAgentsInfo`. That failure mode is the one I want to understand before this reaches GA.

Beyond that specific case, I am curious where you all stand: are you moving custom detections into Git now, or waiting for GA? And if you already run detections as code for analytics rules, what checks have earned a permanent place in your PR pipeline?

My used references:

Manage content as code with Microsoft Sentinel repositories: https://learn.microsoft.com/en-us/azure/sentinel/ci-cd-custom-content
Advanced hunting schema naming changes: https://learn.microsoft.com/en-us/defender-xdr/advanced-hunting-schema-changes
Create custom detection rules in Microsoft Defender XDR: https://learn.microsoft.com/en-us/defender-xdr/custom-detection-rules
Custom detections as the unified detection experience: https://techcommunity.microsoft.com/t5/microsoft-defender-threat-protection/custom-detections-are-now-the-unified-experience-for-creating/ba-p/4463875

Microsoft Security Launch Event

TrevorRusher — Mon, 27 Jul 2026 19:27:51 GMT

Join us to hear the latest news and announcements from Microsoft Security.‌

Speakers:

Hayete Gallot
Dave Weston
Taesoo Kim
Mustafa Suleyman