As this community reaches 1,006 subscribers, I’ve realised something interesting.

The most valuable conversations I’ve had haven’t really been about technology at all.

They’ve been about risk. They’ve been about governance. They’ve been about leadership.

And increasingly, they’ve been about how organisations prepare for a future where AI is fundamentally changing how businesses operate.

Looking Back

One thing I haven’t been particularly good at this last year is publishing as consistently as I would have liked.

Between a demanding day job, some exciting professional opportunities, and the small matter of raising a young family, finding time to sit down and write has often been harder than I expected.

Like many people, the limit is that there are only so many hours in the day. Sometimes the article I wanted to publish remained a draft for weeks, and ideas that seemed brilliant during a meeting, customer engagement or commute never quite made it onto the page.

In many ways, reaching 1,000 subscribers is therefore even more meaningful to me. This community has continued to grow despite the fact that I haven’t always been able to dedicate the time to it that I would have liked.

Over the last twelve months, I’ve also been fortunate to experience a number of personal and professional milestones.

I was honoured to be renewed as a Microsoft Most Valuable Professional (MVP), continuing a journey that has connected me with an incredible global community of experts, practitioners and leaders.

The content shared across LinkedIn generated more than 115,000 impressions, creating opportunities to engage with customers, security leaders, architects, operational teams, Microsoft product groups, partners and peers from across the industry. Or just have a bit of Geeky Fun, with Truth or a Lie posts!

Most significantly, my role has continued to evolve.

While technology remains at the centre of everything I do, much of my focus today is increasingly centred on strategy, operating models, skills & resourcing, service design, governance, business outcomes and helping organisations understand how emerging technologies can be adopted safely and sustainably at scale.

I’ve found myself spending less time asking:

“How does this technology work?”

And more time asking:

“How does this technology change the organisation?”

That difference may seem subtle.

In reality, it changes everything.

From Technology to Leadership

Earlier in my career, success often meant being the person closest to the technology.

Today, success increasingly comes from helping specialists & teams succeed.

It comes from connecting security, operations, architecture, governance, commercial’s and business leadership.

It comes from understanding how individual technical decisions support wider organisational objectives.

Most importantly, it comes from helping organisations navigate uncertainty. Delivering value. Nowhere is that more evident than with AI.

The conversations I’m having today are rarely focused on prompts, models or individual features.

Instead, they centre on questions such as:

• Who owns an AI agent?

• How do we govern autonomous systems?

• What does accountability look like in an AI-enabled enterprise?

• How do security teams adapt to agentic AI?

• What new operating models are required?

• How do leaders balance innovation with risk?

Those aren’t purely technical questions. They’re leadership questions.

The reality is that organisations & MSSP’s already have exceptional technical specialists. My role is increasingly about bringing those capabilities together, helping teams move in the same direction, and ensuring technology delivers meaningful outcomes for the business.

I sometimes joke about the word “frontier” because it has become one of those industry buzzwords that everyone likes to use. Yet there is some truth behind it.

AI genuinely feels like the next frontier for security, governance and business transformation. The challenge isn’t simply understanding the technology.

The challenge is helping organisations navigate what comes next.

What This Means For This Blog

As a result, you’ll likely notice an evolution in the content I publish going forward.

Microsoft Security will remain a core theme. So will Microsoft Sentinel, Defender XDR, Entra, Purview and the technologies many of us work with every day.

But you’ll also see more writing around:

• AI governance

• Security leadership

• Enterprise operating models

• Digital workers and agentic AI

• Strategic security transformation

• Organisational change

• Risk and accountability

• The future of cyber security leadership

The technical depth isn’t going away. Far from it. In fact, it has never been more important.

But increasingly, I believe the organisations that succeed will be those that can connect technology, people, process and strategy into a coherent whole.

Technology enables change. Leadership determines whether that change succeeds.

Looking Forward

The next twelve months will be interesting.

Not just because of what AI, security and Microsoft technologies are likely to do, but because of how organisations themselves are changing.

My hope is that the next chapter contains more writing, more discussion, more challenging questions and more opportunities to share what I’m learning as security, leadership and AI increasingly converge.

If the last year was about evolving from technology-focused conversations towards broader discussions around governance, operating models and strategy, perhaps the next year is about taking that a step further.

We’ll see where the journey goes.

Thank You

To everyone who has subscribed, commented, challenged my thinking, shared posts, connected on LinkedIn or simply taken the time to read what I’ve written:

Thank you.

Reaching 1,000 subscribers is a milestone I’m genuinely grateful for. Not because of the number itself. But because every subscriber represents a professional interested in having better conversations about security, technology and the future of our industry.

This community has grown into something far bigger than I expected when I published my first article. And I suspect the next chapter will be the most interesting one yet.

We’re entering a period where AI, security and business transformation are converging. The technology is changing quickly. The leadership challenge may be changing even faster. I’m looking forward to exploring both with you.

Thank you for being part of the first 1,000.

The journey continues.

Connect With Me

If you’ve followed this blog for Microsoft Security content, thank you.

If you’re interested in AI governance, security leadership, operating models and what comes next for enterprises adopting AI at scale, I hope you’ll stay for the next chapter.

I’d love to hear how your own role has evolved over the last 12 months and what challenges you see ahead for security leaders navigating the AI era.

If this article was useful, please subscribe for more content on Microsoft Security, AI governance, enterprise operating models and the future of cyber security leadership.

#MicrosoftSecurity

#ArtificialIntelligence

#CyberSecurity

#MicrosoftMVP

#SecurityLeadership

#AIGovernance

#DigitalTransformation

#AgenticAI

#MicrosoftCopilot

#SecurityStrategy

There is a moment in most emerging technology conversations when the tone changes.

At first, everybody wants to know what the technology can do. People bring demonstrations, possible use cases and ambitious ideas. They talk about productivity, automation and how quickly a task might be completed if an intelligent agent could undertake part of it.

Then someone asks a different question.

Who owns it?

That question is usually followed by several more. What information can it access? Who approved it? What happens if it behaves unexpectedly? Can anyone stop it? Who supports it once it becomes operational? How do we know whether it is still doing what it was originally approved to do?

This is the point at which an AI conversation becomes a governance conversation.

Since Microsoft Agent 365 became generally available on 1 May 2026, I have been speaking with clients, customers, security leaders, development teams and operational stakeholders about what agent governance will mean in practice. The product is still relatively new, so it would be misleading to suggest that anybody has years of operational experience with its generally available form. What we do have are early insights from organisations trying to move from experimentation towards structured, enterprise-scale adoption.

Microsoft describes Agent 365 as a control plane for observing, governing and securing agents. Its stated capabilities include centralised visibility, lifecycle management and integration with existing identity, data protection, security and administrative capabilities.

Yet the most important conclusion from those conversations is this:

Agent governance is not primarily a technology implementation. It is an operating-model challenge.

The conversation that starts with a licence

For many organisations, the initial conversation is a commercial one.

Should the organisation uplift to Microsoft 365 E7? Should it purchase Agent 365 separately? Should it select another product to discover and govern agents? Would a consolidated suite offer better value than maintaining several individual technologies?

These are all reasonable questions, particularly when organisations are being asked to plan for an environment in which agents may become as common as applications, service accounts or user identities.

Microsoft positions Microsoft 365 E7 as bringing together Microsoft 365 E5, Microsoft 365 Copilot, the Microsoft Entra Suite and Microsoft Agent 365 — with Agent 365 as the control plane through which agents can be observed, governed and secured.

This creates an understandable temptation to begin with a feature comparison. Which product has the strongest agent registry? Which platform offers the best discovery? Which one provides the clearest visualisation of agent activity? Which licence includes the most advanced controls? Which supplier appears to have the strongest long-term roadmap?

I increasingly find myself suggesting that this may be the wrong starting point.

Before asking whether a new licence or governance platform will solve the problem, an organisation should ask how effectively it is using the controls it already owns.

Many enterprises have invested heavily in identity, endpoint management, information protection, data classification, cloud security, secure access, audit, incident response and compliance technology. However, these capabilities are often deployed at different levels of maturity. Some may have been implemented as separate projects. Some may be technically enabled but lack clear operational ownership. Others may have been deployed only to selected parts of the organisation.

The controls may exist, but may not yet operate as one coherent system.

That matters, because a new AI governance capability does not automatically correct weaknesses in the underlying environment. If identities are not properly managed, data is not consistently classified, access reviews are irregular, security telemetry is fragmented and operational ownership is unclear, adding an agent control plane may make those gaps more visible. It will not make them disappear.

So an E7 uplift, a standalone Agent 365 purchase or an alternative agent-governance discussion should be accompanied by a more fundamental assessment:

Are the existing identity, security, compliance, endpoint and data-governance capabilities deployed cohesively enough to support AI agents?

For many organisations, answering that question honestly could deliver a greater immediate operational benefit than beginning with a long list of new feature requirements.

The discovery problem: there is rarely one AI estate

When speaking to operational teams about AI, one theme appears repeatedly: what people initially describe as “the AI environment” is rarely one environment.

There may be formally sponsored programmes, small proofs of concept, individual productivity tools, embedded functionality inside existing applications, development experiments, supplier-provided services and business-led automations. Some capabilities will sit inside the organisation’s primary technology ecosystem. Others will operate through specialist third-party platforms, software-as-a-service applications, local development environments, or features that have been quietly introduced into products the organisation already owns.

This changes the nature of the governance challenge. The organisation is not simply trying to govern one development platform. It is trying to establish a consistent way of understanding many different forms of AI activity.

The first practical requirement is therefore not a sophisticated technical control. It is dependable visibility.

Organisations need to be able to answer some apparently simple questions:

• What AI systems and agents exist?

• Why do they exist?

• Who owns them?

• Which business processes do they support?

• What information do they use?

• Which platforms and suppliers are involved?

• Are they experimental, approved or operational?

• What would happen if they became unavailable?

Those questions are simple to write down. They are much harder to answer across a large enterprise.

Tooling will help, especially where an agent platform can provide centralised discovery and registry capabilities. But tooling alone is unlikely to identify every use case or provide all the business context required. Discovery needs to combine technical telemetry with direct engagement with customers, business units, developers, platform teams, procurement functions and operational owners.

That leads to an important distinction.

An agent registry records technical objects. An enterprise AI register records business context.

The two overlap, but they are not identical. A technical registry may tell an organisation that an agent exists, where it was created, who published it and perhaps whether it is being used. The enterprise record should explain why it exists, what outcome it supports, which process depends on it, what information it uses, who is accountable for it and what would happen if it were disabled.

Both views are necessary, and they need a dependable relationship between them. If a security team needs to isolate an agent, it should not have to search through old project documentation to determine whether doing so will interrupt a critical business service. Equally, a business register should not simply state that an AI use case is “live” without identifying the technical identities, integrations, models, applications and data sources that make the service operate.

This is one of the points at which governance stops being an administrative exercise and starts becoming operational.

Two journeys running alongside each other

I have found it helpful to describe two connected journeys.

The first is the business and governance journey. It begins with an idea, problem or request. The organisation asks what outcome is being sought, whether AI is appropriate, who will own the outcome, what risks could be introduced and whether the proposed activity should proceed.

The second is the engineering and operational journey. It covers how the solution is designed, developed, tested, released, monitored, changed, supported and eventually retired.

These journeys should run alongside one another. Neither should replace the other.

Governance determines what must be true. The secure development lifecycle establishes how the solution will be built and evidenced. Architecture confirms whether the intended design is appropriate. Service transition determines whether the organisation is ready to operate it. Security operations define how abnormal activity will be detected and handled. Business ownership determines whether the agent continues to deliver an acceptable outcome.

In practice, I often see these activities operating as adjacent processes rather than one connected lifecycle. A governance team writes a framework. A development team follows its established delivery method. Architecture conducts a review. Security performs an assessment. Privacy becomes involved if personal information is identified. A service team receives the solution shortly before deployment.

Each activity may be entirely reasonable when considered on its own. Yet the overall process can still contain gaps, duplicated effort and unclear hand-offs.

The solution is not necessarily to create another standalone lifecycle specifically for AI. A more sustainable approach is to extend and connect existing processes, so that an organisation can trace an AI use case from its initial request through design, approval, implementation, operation, material change and retirement.

This also helps distinguish between the role of governance and the role of the secure development lifecycle.

Governance defines the organisational expectations, decision rights, accountability and risk thresholds. The secure development lifecycle converts those expectations into design requirements, testing activities, engineering controls and evidence.

Governance should not attempt to tell development teams how to implement every technical control. Equally, a development lifecycle should not be expected to define the organisation’s risk appetite or decide whether a use case is ethically, legally or operationally acceptable.

They need to meet at clearly defined points.

Beginning with governance, not technology

Starting with governance is valuable because it forces an organisation to address questions that technology cannot answer.

• A tool can help show that an agent exists. It cannot decide whether the business should accept the associated risk.

• A platform can expose permissions. It cannot determine whether those permissions are proportionate to the expected business outcome.

• A security product can identify unusual behaviour. It cannot decide how much disruption is acceptable if the agent must be suspended.

• A register can record the name of an owner. It cannot make that owner meaningfully accountable.

• A reporting dashboard can display usage. It cannot determine whether the use case continues to deliver sufficient value.

These decisions require an organisational governance structure.

For that reason, I regularly refer clients and customers to the NIST AI Risk Management Framework (the NIST AI RMF) as a practical starting point. It organises AI risk-management activity around four connected functions: GOVERN, MAP, MEASURE, MANAGE.

I do not believe organisations should treat the framework as a checklist that requires every available statement to be converted into a separate control or document. Its value lies in providing structure, common language and a method of challenging whether the organisation has considered the right questions.

In practical terms, I explain the four functions as follows:

Function - The question it forces you to answer

Govern - Who is accountable, what rules apply, how are decisions made, and how does leadership maintain oversight?

Map - What is the use case, who may be affected, what information is involved, where are the dependencies, and in what context will the AI operate?

Measure - How will risk, performance, security, reliability and control effectiveness be assessed?

Manage - What action will be taken, who will take it, how will risks be prioritised, and how will the organisation respond when the context changes?

This creates a recognisable governance structure without forcing every organisation to invent a proprietary method.

One framework is not enough

Although the NIST AI RMF provides a strong risk-management structure, it is not the only framework that will influence enterprise agent governance.

The NIST AI RMF Generative AI Profile provides additional considerations for risks associated with generative AI.

ISO/IEC 42001 provides an AI management-system perspective for organisations seeking a structured and potentially auditable governance approach.

The OWASP Top 10 for Large Language Model Applications, together with emerging agentic-security guidance, can support technical threat modelling, secure design and testing.

Privacy and data-protection requirements continue to apply wherever personal information is processed. And existing cybersecurity standards remain relevant, because an AI agent still depends on identities, endpoints, applications, integrations, cloud services, APIs and data stores.

The challenge is to avoid creating several competing governance systems.

The more workable approach is to establish a primary framework and use the other standards as specialist lenses. For example:

• NIST AI RMF — to structure enterprise AI risk management.

• ISO/IEC 42001 — to inform management-system maturity, governance and assurance.

• OWASP guidance — to support technical threat modelling.

• Existing cybersecurity standards — to govern identity, logging, secure configuration and incident response.

• Privacy requirements — to determine when a formal data-protection assessment is needed.

• A secure development lifecycle — to translate governance requirements into design, testing and release evidence.

The purpose is not to claim compliance with every framework. It is to create a traceable and proportionate control environment in which the organisation can explain which sources it has used, why they are relevant and how they influence its decisions.

The proof of concept is not outside governance

One of the more uncomfortable issues raised in customer and delivery-team conversations is the treatment of proofs of concept.

It is easy to assume that experimentation is inherently low risk because nothing has formally entered production. However, a proof of concept may already be connected to live systems, personal information, commercially sensitive data, external models, APIs or privileged accounts.

The words “proof of concept” describe the maturity of the idea. They do not describe the sensitivity of the data or the significance of the access being used.

This changes where governance needs to begin. It cannot start only when a delivery team requests production approval. There needs to be an earlier and proportionate trigger.

That does not mean every idea should be subjected to a lengthy committee review. It means the organisation should know when a seemingly small experiment crosses an important boundary. Examples may include:

• The introduction of live or sensitive data

• The processing of personal information

• Privileged access to a system

• Connectivity to an external service

• The ability to initiate an action or transaction

• Reliance on an unassessed supplier

• Use in a safety-critical or high-impact process

• The ability to influence a material business decision

The early-stage process should be deliberately lightweight. Its purpose is to identify important risks before design decisions become expensive or politically difficult to reverse.

Some organisations may support low-risk experimentation through controlled environments, synthetic data and pre-approved patterns. This allows innovation to move quickly without treating experimentation as a governance-free zone.

The moment the agent becomes a digital worker

One of the most useful ways I have found to explain agents to non-technical audiences is to describe them as a form of digital worker.

The comparison is not perfect, but it makes the governance challenge tangible.

A human worker has an identity, a manager, a role, defined access, expected behaviour and a leaving process. An agent may also have an identity, permissions, tools, knowledge sources, an owner and the ability to perform actions.

That leads to a set of questions senior leaders and operational teams already understand:

• Who sponsors this worker?

• What is it expected to do?

• Which systems may it access?

• What information may it see?

• What decisions may it influence?

• How is its activity supervised?

• What happens when its role changes?

• How is its access removed when it is retired?

This framing also exposes a common weakness in technical inventories: knowing who created an agent is not the same as knowing who is accountable for it.

The original developer may change role or leave the organisation. The initial project may close. The agent may gradually be adopted by other teams. Its data access may expand. Its importance may increase without a formal decision being recorded.

Every operational agent therefore needs, at minimum, a clear business owner and a clear technical owner. The business owner should remain accountable for the outcome, appropriateness and continuing need. The technical owner should be accountable for maintainability, configuration, integration and operational health.

Security, privacy, architecture, procurement, risk and operational functions may hold important responsibilities — but they should not accidentally become the owner of the business risk simply because they operate a review or a control.

Agent 365 is an enabler, not the governance model

This is where Microsoft Agent 365 becomes relevant.

Microsoft describes it as providing centralised capabilities to observe, govern and secure agents. Its documented capabilities include a central registry, lifecycle and access governance, integration with Entra for identity controls, Purview for data security and compliance, and Defender for threat protection.

That addresses a genuine requirement for visibility and control.

However, organisations should be careful not to describe Agent 365 as a universal scanner that will automatically discover, understand and fully govern every possible agent. Coverage will depend on the technology involved, the available integration path, the telemetry being generated, licensing, configuration, and whether the relevant capability is generally available or still emerging.

This matters when setting expectations with executives.

The product can support an operating model. It is not the operating model.

It cannot determine the organisation’s risk appetite. It cannot create meaningful accountability where none exists. It cannot decide the business impact of suspending an agent. It cannot ensure that service transition has been completed. It cannot determine whether an approval forum is effective. It cannot decide whether a business outcome justifies the remaining risk.

Buying the technology before designing these processes could leave an organisation with a well-presented inventory of poorly governed objects.

E7 uplift or standalone agent governance?

The choice between an E7 uplift, a standalone Agent 365 purchase or an alternative governance platform should therefore come later in the discussion. The organisation should first identify the outcomes it is trying to achieve:

• Does it need basic discovery, or an enterprise-wide register?

• Does it need consistent identity governance for agents?

• Does it require advanced data-security and compliance controls?

• Is runtime threat detection required?

• Must third-party and locally running agents be represented?

• Which people will interact with, own, sponsor or manage governed agents?

• Which underlying capabilities are already licensed?

• Which existing technologies are deployed but underused?

• Which operational teams will respond to the alerts, insights and governance tasks generated?

The licensing model also needs careful consideration. Microsoft documents Agent 365 as generally available for commercial customers on a per-user basis. This means organisations should not assume that the number of agents maps directly to an identical number of licences — the relevant human population, roles and use of premium capabilities need to be properly understood.

This is particularly important during an E7 conversation. An uplift may be commercially and operationally sensible when an organisation genuinely requires the combined capabilities and has a credible plan to operate them coherently.

But an attractive licence bundle is not a target operating model.

Before recommending further investment, I would normally encourage an organisation to examine five foundations.

1. Identity. Are user, workload and application identities governed consistently? Are privileged access, conditional access, authentication, sponsorship and lifecycle processes working as intended?

2. Data. Does the organisation know where its sensitive information resides? Is that information classified and protected in a way that can be extended to AI interactions?

3. Endpoints and applications. Are devices, applications, browser-based services and cloud platforms sufficiently visible and controlled?

4. Operations. Are alerts, incidents, vulnerabilities, exceptions and changes connected to accountable operational teams with defined response processes?

5. Ownership. Can the organisation identify who is answerable for the agent, the business outcome, the underlying service and the information involved?

If these foundations are weak, improving them may create more immediate risk reduction than purchasing an additional layer of advanced functionality.

This is not an argument against E7, Agent 365 or another governance product. It is an argument for sequencing the investment sensibly.

The lifecycle does not stop at deployment

A significant governance gap often appears after production approval.

Traditional projects are organised around delivery. Funding, attention and governance build towards go-live. Once the solution is released, the project closes and responsibility is transferred to operational teams.

Agents do not fit comfortably into that model. Their instructions may change. The underlying model may be updated. Connected information sources may expand. New tools or integrations may be added. User behaviour may evolve. Suppliers may modify their services.

A low-impact assistant can gradually become part of a critical business workflow without anybody making a formal decision that this should happen.

This means the approval decision represents the beginning of operational governance, not its conclusion. A practical lifecycle therefore needs to cover:

Request → Triage → Assessment → Decision → Implementation → Operational monitoring → Material change → Exception management → Reassessment → Retirement

Material changes should trigger some form of reassessment. Higher-risk changes may require renewed approval.

The practical question should not simply be:

“Was this agent approved?”

It should be:

“Is this still the agent that was approved?”

That question captures one of the central challenges of operational AI governance. Approval is based on a specific understanding of purpose, data, access, behaviour and context. When one of those factors changes materially, the original decision may no longer be valid. Risk change = Change.

Governance must meet the end user

It is possible to design excellent governance for professional development teams and still leave a major source of risk largely untouched.

An end user may discover an AI feature inside an application they already use. They may create a simple agent themselves. They may use a public service because an approved alternative feels too restrictive. They may paste information into an assistant without understanding how that information is processed or retained. They may not even recognise that a new feature uses AI.

This is why citizen-developed agents and shadow AI need to form part of the same operating model. The answer cannot simply be prohibition.

If governance is slow, inaccessible or confusing, people will avoid it. If approved tools do not meet a genuine business need, alternative services will appear. If acceptable-use guidance is written only for legal defensibility, it may do little to guide everyday behaviour.

The end-user experience therefore needs a simple route for common situations:

• “I have an idea.”

• “I want to use this tool.”

• “I have built something.”

• “I need to publish an agent.”

• “I think an agent is behaving incorrectly.”

• “I need to know what information I can use.”

Each statement should lead somewhere clear.

For lower-risk citizen development, organisations may need approved environments, standard templates, restricted connectors, publication checks and accessible guidance. For higher-risk use cases, there should be a visible escalation route into architecture, security, privacy or formal delivery governance.

The objective is not to remove innovation from end users. It is to provide a safe and understandable route through which useful innovation can become supported capability.

What customers are preparing for next

When discussing the future with clients and operational teams, five concerns appear consistently.

Scale. A manually maintained register may be sufficient when an organisation has a small number of known experiments. It becomes much less sustainable when agents can be built by professional developers, citizen developers, software suppliers, business users and specialist platforms.

Interconnection. An individual agent may appear low risk when viewed alone. The risk can change when that agent calls tools, invokes workflows, communicates with other agents or gains access to additional data.

Identity. Agents may act on behalf of users, through shared credentials, with their own identity, or through application permissions. Each pattern has different implications for accountability, access management and investigation.

Operational dependency. As teams begin to trust agents, previously optional capabilities may become embedded in normal working practices. At that point, resilience, change control, incident response and continuity planning become essential.

Assurance. Leaders will increasingly want to know not only how many agents exist, but whether they are controlled, whether they are delivering value, and whether the organisation can produce evidence of its decisions.

These future concerns reinforce the need to begin with core governance components rather than a product-led requirements list. A platform can help an organisation respond at scale. It cannot compensate for the absence of ownership, classification, lifecycle rules and operational responsibility.

The operating model organisations are moving towards

The model emerging across these conversations is not a new central AI department that owns everything. It is more likely to be a connected set of existing capabilities, with AI-specific triggers, controls and evidence:

1. A business idea enters an established demand route.

2. A proportionate triage identifies ownership, data, autonomy, technology and risk.

3. Low-risk activity follows a shorter path using approved patterns.

4. Higher-risk, sensitive or novel activity receives specialist review.

5. Development controls produce the necessary technical evidence.

6. Architecture, security, privacy and business decisions are recorded where relevant.

7. The technical agent is linked to its approved business use case.

8. Service transition confirms support, monitoring and operational readiness.

9. Usage and risk are reviewed after release.

10. Material change triggers reassessment.

11. Retirement removes access, dependencies and obsolete records.

Agent 365, or another suitable control plane, can provide valuable technical visibility throughout that journey. But the organisational process should still function as a governance model when a particular agent is not fully visible through one product.

That is an important test:

If governance works only for agents discovered by one technical platform, it is product governance rather than enterprise AI governance.

What I would recommend organisations do differently

If an organisation is beginning this journey, I would resist the urge to write the perfect framework first.

I would start with a small number of real use cases and follow them from beginning to end. Where did the request enter the organisation? Who decided that it should proceed? What information was captured? Who accepted the risk? What technical components were created? Who approved access? What testing was completed? How was operational support arranged? How would the agent be suspended? What would trigger reassessment? How would it be retired?

The gaps tend to become visible quickly.

I would also separate three concepts that are frequently confused:

• A policy states the organisation’s expectations.

• A lifecycle describes how work progresses and where decisions occur.

• A platform provides technical visibility, administration and enforcement.

All three are required. None can substitute for the others. Platform can block all.

Finally, I would assess the existing estate before defining the target technology stack — including the current use of identity, endpoint, information-protection, cloud-application, audit, security-monitoring and threat-detection capabilities.

The technology conversation can then become evidence-led rather than feature-led. Instead of asking, “What can the new product do?”, the organisation can ask:

• “Which governance outcome do we require?”

• “Which capability do we already own?”

• “Is that capability operating effectively?”

• “What remains missing?”

• “Which investment closes that gap most sensibly?”

That is a much stronger basis for an E7 uplift, a standalone Agent 365 decision, or the selection of another agent-governance platform.

The lesson from the first months

It is still early. Agent 365 became generally available on 1 May 2026, and organisations should continue to distinguish between generally available functions and preview or emerging capabilities when designing production controls and making commitments.

More cost management features are expected imminently.

Yet the early lessons are already becoming clear.

The difficult part is not creating an AI policy. It is connecting business demand, risk assessment, secure development, architecture, identity, data protection, service transition, security operations, monitoring, change management and end-user behaviour into one repeatable system.

The most effective starting point is not a long list of product features. It is a clear understanding of what already exists, what is already licensed, what is already operating, what is fragmented and what is missing. From there, an organisation can make a rational choice about Microsoft 365 E7, Agent 365 or another governance platform.

A control plane can consolidate visibility. A framework can create consistency. A lifecycle can provide repeatability.

But only an operating model can turn all three into governance.

That is the work now in front of organisations: not simply governing a new technology, but embedding a new category of digital participant into the way the enterprise already makes decisions, manages risk and remains accountable.

The real question is no longer whether organisations will use agents.

It is whether they will be able to explain, with confidence, who those agents work for, what they are allowed to do, what information they can access, how they are supervised, and who is accountable when something changes.

That is the difference between adopting agents and governing them.

If you are working through agent governance in your own organisation, I would be interested to hear which of the five foundations — identity, data, endpoints, operations or ownership — is proving hardest to get right. Replies and comments are open.

If this was useful, please subscribe for more on enterprise AI governance, Microsoft security and the operating models behind them.

Tags #

#MicrosoftSecurity

#MicrosoftLearn

#CyberSecurity

#MicrosoftSecurityCopilot

#Microsoft

#MSPartnerUK

#msftadvocate

WordCloud

Secure AI Foundry

Secure AI Agent Foundry

AI Security Foundry

Secure Agentic AI

Enterprise AI Agent Security

Secure AI Operations

Secure AI at Scale

AI Safety by Design

AI-SecOps

AI-native SecOps

Microsoft Defender for AI agents

Microsoft Defender for AI security

Microsoft Agent 365 security

Secure Microsoft AI agents

Microsoft AI agent posture management

Defender AI agents Ignite

Microsoft secure AI development

Azure AI agent security best practices

That is precisely the gap Microsoft Agent 365 and Microsoft Defender XDR are designed to address.

Microsoft Agent 365 provides the control plane for observing, governing, and securing AI agents. Microsoft positions Agent 365 as a way to manage agents through the same enterprise administration and security platforms organisations already use, including Microsoft 365 Admin Centre, Microsoft Defender, Microsoft Entra, Microsoft Intune, and Microsoft Purview.

Defender then adds the security operations layer: discovery, posture assessment, threat detection, investigation, Advanced Hunting, and runtime protection for supported agent scenarios. Microsoft describes Defender posture and runtime protection for cloud agents in Agent 365 as a unified capability that consolidates security posture assessment and runtime protection across Microsoft Foundry, Microsoft Copilot Studio, and third-party managed agents.

The key takeaway for security leaders is simple:

Agent 365 is not just an inventory screen, and Defender is not just another alert source.

Together, they form the foundations of an AI agent security operating model.

Overall Summary

If you need to explain the relationship between Agent 365 and Defender XDR to a SOC manager, CISO, security architect, or programme board, the message can be distilled into nine key points:

1. Microsoft Agent 365 acts as the governance and observability control plane for AI agents.

2. Microsoft Defender XDR provides threat detection, posture management, investigation, runtime protection, and enforcement using Agent 365 signals.

3. Agent 365 is generally available, but some Defender capabilities for AI agent detection and investigation remain in Public Preview.

4. Discovery and posture assessment are available through the AI Agents experience within Defender, exposing risk levels, recommendations, alerts, identities, tools, and related security context.

5. Near real-time detection uses Agent 365 observability data to identify behaviours such as:

   • Jailbreak attempts

   • Cross-Prompt Injection Attacks (XPIA)

   • Malicious content propagation

   • Credential and secret leaks

   • Evasion techniques

   • Suspicious user activity

6. Agents built in Copilot Studio, Microsoft Foundry, and Microsoft 365 Copilot Agent Builder send observability data to Microsoft 365 by default.

7. Third-party platforms require observability instrumentation through the Microsoft Agent 365 SDK.

8. Local runtime protection requires Microsoft Defender for Endpoint running in Active Mode.

9. Data residency must be reviewed. For Defender as part of Agent 365, Microsoft states that tenants provisioned in the UK or EU store data within the EU, while tenants provisioned elsewhere store data in the United States.

The headline is reassuring, but the implementation detail matters.

You can now see and protect significantly more of the AI agent estate, but actual coverage depends on licensing, connectors, telemetry availability, platform support, endpoint configuration, and whether a capability is generally available or still in preview.

Why AI Agents Require a Different Security Model

Traditional enterprise security is built around users, devices, applications, workloads, and data flows.

AI agents fundamentally change that model.

An agent can:

• Receive natural language instructions

• Reason over context

• Select tools autonomously

• Execute workflows

• Read or update information

• Communicate with external systems

• Make decisions based on inputs

In practice, the agent becomes more than a passive application. It becomes an active participant in business process execution.

That creates a new set of security questions:

• What can the agent access?

• Which identity is it operating under?

• Which tools can it invoke?

• What data sources can it query?

• Can its instructions be manipulated?

• Can untrusted content influence its actions?

• Can runtime decisions be inspected or blocked?

Microsoft’s documentation reflects this reality, highlighting that deployed AI agents can operate autonomously, invoke tools, access connected systems, and take actions in response to natural language interactions.

For security teams, the question is no longer simply:

“Who has access?”

Instead, it becomes:

“What can this agent decide to do with that access?”

The Four Major AI Agent Threat Categories

1. Model and Supply Chain Compromise

Agents rarely rely on a single component.

Most modern agents depend upon:

• Foundation models

• Tools

• APIs

• Connectors

• Plugins

• Prompt libraries

• Orchestration logic

• Knowledge sources

• Third-party services

Compromise anywhere in that chain can influence downstream behaviour.

This becomes especially significant for custom-built agents and third-party ecosystems where governance and observability may not be enabled by default.

2. Misconfiguration and Excessive Permissions

An over-permissioned agent can rapidly become a data exposure risk.

Security concerns commonly include:

• Excessive access rights

• Weak authentication controls

• Over-privileged tool permissions

• Lack of ownership

• Inadequate lifecycle management

Defender’s AI Agent Inventory helps address this by surfacing:

• Configuration details

• Identity information

• Authentication context

• User and endpoint relationships

• Security alerts

• Security recommendations

• Tool inventory

• MCP server relationships

3. Runtime Misuse

Design-time security is only half the story.

An agent may be correctly configured yet still become dangerous during execution.

Examples include:

• Following manipulated instruction chains

• Processing malicious content

• Using tools unexpectedly

• Retrieving unauthorised information

• Performing actions outside intended business workflows

This is where runtime protection becomes essential.

Defender’s runtime protection capabilities are specifically designed to reduce these AI-specific operational risks.

4. Prompt and Content-Based Attacks

Prompt injection introduces a threat model unlike traditional malware.

Attack content may be embedded inside:

• Emails

• Documents

• Knowledge bases

• Websites

• Retrieved content

• Shared repositories

Defender analyses telemetry, execution behaviour, and tool utilisation patterns to identify:

• Jailbreak attempts

• XPIA attacks

• Malicious content propagation

• Credential exposure

• Secret leakage

• Evasion behaviour

• Suspicious access patterns

Understanding the Architecture

The easiest way to understand Microsoft’s approach is to separate control plane from security plane.

Microsoft Agent 365: The Control Plane

Agent 365 provides:

• Governance

• Observability

• Administration

• Security configuration

• Cross-platform agent management

Its purpose is to enable organisations to observe, govern, and secure agents consistently regardless of implementation model.

Microsoft Defender XDR: The Security Plane

Defender provides:

• Centralised inventory

• Risk assessments

• Security recommendations

• Near real-time detections

• Incident correlation

• Advanced Hunting

• Runtime behaviour recording

• Real-time enforcement

The two capabilities work together:

Agent 365 tells you what exists and how it is configured.

Defender tells you whether it is risky, under attack, or performing suspicious actions.

Coverage Is Not Equal Across Every Agent

One of the most dangerous assumptions organisations can make is:

“Agent 365 is enabled, therefore all agents are fully protected.”

That is not necessarily true.

There are effectively two layers of coverage.

Core Agent 365 and Defender Coverage

Provides:

• Discovery

• Inventory

• Posture assessment

• Risk indicators

• Security recommendations

• Detection and investigation capabilities where telemetry exists

Applicable to:

• Agent 365 managed agents

• Supported local agents

Extended Platform-Specific Coverage

Provides:

• Enhanced detections

• Deep runtime protection

• Platform-native enforcement

Applicable to:

• Copilot Studio

• Microsoft Foundry

• Microsoft 365 Copilot Agent Builder

• Supported local endpoint agents

A critical rollout question should therefore always be:

“Is this agent merely discoverable, or is it supplying the telemetry required for detection, investigation, and protection?”

Onboarding: What Must Be In Place

Treat onboarding as a programme of work, not a single configuration activity.

Step 1: Validate Security for AI Data Collection

Administrators can independently enable or disable Security for AI capabilities through Defender without impacting other Agent 365 services.

Never assume collection is enabled.

Verify it.

Step 2: Enable the Microsoft 365 Connector

The Microsoft 365 connector is a prerequisite for Agent 365 observability data collection.

Without it, investigation, hunting, and incident evidence will be significantly limited.

Step 3: Integrate Copilot Studio

Real-time protection for Copilot Studio requires collaboration between:

• Defender Administrators

• Power Platform Administrators

This should be planned as a joint ownership model rather than a security-only task.

Step 4: Validate Local Agent Requirements

Local agents require separate onboarding.

Microsoft states that local agent threat detection requires:

• Defender for Endpoint

• Active Mode operation

• Dedicated local agent onboarding

Cloud and endpoint onboarding should therefore be treated as separate workstreams.

Inventory and Posture Management

Once enabled, the AI Agents experience within Defender becomes the primary operational dashboard.

According to Microsoft, the inventory can expose:

• Risk levels

• Risk indicators

• Recommendations

• Active alerts

• Configuration data

• Identity information

• Authentication context

• User relationships

• Endpoint relationships

• Attack surface mappings

• Tools

• MCP servers

This allows security teams to answer practical governance questions:

• Which agents exist?

• Who owns them?

• What platform created them?

• Which agents have active alerts?

• Which agents present risk indicators?

• Which agents require remediation?

• Which agents have excessive privileges?

For Advanced Hunting, the primary inventory source is AgentsInfo, which replaces the earlier AIAgentsInfo table as part of the Agent 365 transition.

Detection and Investigation

Defender’s AI detection capability is valuable, but should be presented accurately.

At the time of writing, Microsoft still labels key AI agent detection and investigation capabilities as Public Preview.

That distinction matters.

Preview capabilities are valuable for operational visibility and early detection, but organisations should avoid representing them as mature, SLA-backed controls until Microsoft formally declares them generally available.

Defender continuously analyses:

• Agent telemetry

• Tool invocations

• Execution patterns

• Observability signals

to identify suspicious behaviour.

Alerts then enter the normal Defender workflow for:

• Triage

• Investigation

• Correlation

• Incident response

• Advanced Hunting

A mature SOC investigation approach should correlate:

1. Agent identity and configuration from AgentsInfo

2. Runtime activity and tool usage from CloudAppEvents

3. Alert and protection evidence from AlertInfo, AlertEvidence, BehaviorInfo, and BehaviorEntities

This allows analysts to answer:

What happened, which agent performed it, under which identity, against which data, and was anything prevented?

Real-Time Protection and Behaviour Recording

Runtime protection exists to stop risky actions before damage occurs.

According to Microsoft, audit and block events generated by runtime protection are recorded within the BehaviorInfo table.

SOC teams building detections, dashboards, hunting queries, or automated response playbooks around BehaviourInfo should not assume identical evidence exists across every agent platform.

Prompt Evidence Collection

Prompt evidence collection is enabled by default and can include portions of prompts that triggered security detections.

For investigators, this can greatly assist root cause analysis.

However, it is equally a privacy and governance consideration.

If prompts may include:

• Customer information

• Employee information

• Commercial information

• Legal content

• Confidential business data

then privacy, legal, and governance stakeholders should review whether prompt evidence collection remains appropriate.

The critical question is not:

Can Defender collect it?

The critical question is:

Should Defender collect it in this environment?

Data Handling, Residency and Retention

This is one of the most significant topics for regulated organisations.

Microsoft states that Agent 365 and Defender collect observability traces generated during agent execution.

Depending on instrumentation choices, this may include:

• Inputs

• Outputs

• Session details

• Trace payloads

• User identifiers

• Tenant identifiers

• Agent identifiers

• Subscription information

Administrators remain responsible for configuring what data is collected.

Data Retention

Microsoft states that:

• Observability and session data may be retained for up to 30 days

• Agent inventory and Defender-related data may be retained for up to 180 days

• Customer data is deleted within 30 days following contract termination or expiry

Governance documentation should explicitly cover:

• What is collected

• Why it is collected

• Where it is stored

• Retention periods

• Access controls

• Prompt evidence collection settings

• Tenant residency model

Licensing and Prerequisites

Before rollout, verify:

• Agent 365 licensing

• Microsoft 365 licensing requirements

• Microsoft 365 E5 / E7 security dependencies where relevant

• Security Administrator permissions

• Power Platform Administrator support

• Defender for Endpoint Active Mode

• Defender Antivirus Active Mode where required

• Microsoft 365 Connector configuration

The most common governance mistake is overstating coverage.

Simply enabling Agent 365 does not guarantee that every agent is monitored, protected, or fully evidenced for incident response.

Recommended SOC Rollout Approach

A practical rollout should follow a controlled, evidence-led sequence.

1. Build the Initial Inventory

Use the AI Agents dashboard and AgentsInfo to establish a verified list of active agents.

2. Validate Telemetry and Connectors

Confirm observability data is flowing correctly and can be used for detection and investigation.

3. Integrate Copilot Studio Correctly

Ensure Power Platform administration forms part of the ownership model.

4. Start in Audit Mode

Understand normal behaviour before introducing enforcement controls.

5. Introduce Targeted Blocking

Begin with high-confidence use cases such as:

• Credential leakage

• Unsafe tool usage

• Malicious content propagation

6. Build Hunting and Incident Playbooks

Use:

• AgentsInfo

• CloudAppEvents

• AlertInfo

• AlertEvidence

• BehaviorInfo

• BehaviorEntities

to create repeatable investigation workflows.

7. Document Preview Components

Any capability still designated Preview should be explicitly recorded within solution documentation and risk registers.

8. Complete Privacy and Residency Review

Ensure trace payload handling, prompt evidence, data retention, and residency considerations are documented before production deployment.

What Leadership Needs to Hear

The balanced executive message is:

Microsoft now provides a credible framework for securing AI agents through the combination of Agent 365 and Defender XDR.

Discovery, posture management, investigation, Advanced Hunting, and runtime protection are beginning to converge into a comprehensive security capability that directly addresses agent sprawl and autonomous behaviour risks.

However, there is no universal “all agents are protected” switch.

Coverage ultimately depends upon:

• Which agents are onboarded

• Which platforms are supported

• Which telemetry is available

• Which connectors are configured

• Whether endpoint prerequisites have been met

• Whether privacy controls have been reviewed

• Whether the capability is GA or Preview

The most effective strategy is therefore:

Use Agent 365 as the governance plane.
Use Defender as the security operations layer.
Validate coverage by agent type.
Start with visibility and evidence.
Move to enforcement once behaviour is understood.
Treat Preview capabilities with appropriate caution.

Final Thoughts

Microsoft Agent 365 and Defender XDR are important because they address a challenge security teams have been facing since AI agents started appearing across enterprise environments:

Visibility without governance.
Automation without monitoring.
Runtime actions without sufficient evidence.

The strongest use case is not simply switching the technology on.

It is establishing a repeatable AI Agent Security Operating Model:

1. Know what agents exist.

2. Know who owns them.

3. Know what they can access.

4. Know what tools they can use.

5. Know whether they are risky.

6. Know whether suspicious behaviour is detected.

7. Know whether unsafe actions can be blocked.

8. Know where evidence is stored.

9. Know the limitations of Preview capabilities before depending upon them.

That is the difference between enabling AI agents and securing AI agents.

Extras & References

Microsoft Documentation

• Security for AI and Microsoft Agent 365 Privacy Guidance

• Detect and Investigate Threats to AI Agents Using Microsoft Defender

• AI Agents in Microsoft Defender

• Advanced Hunting for AI Agents

Microsoft Product Pages

• Microsoft Agent 365

Tags #

#MicrosoftSecurity

#MicrosoftLearn

#CyberSecurity

#MicrosoftSecurityCopilot

#Microsoft

#MSPartnerUK

#msftadvocate

WordCloud

Secure AI Foundry

Secure AI Agent Foundry

AI Security Foundry

Secure Agentic AI

Enterprise AI Agent Security

Secure AI Operations

Secure AI at Scale

AI Safety by Design

AI-SecOps

AI-native SecOps

Microsoft Defender for AI agents

Microsoft Defender for AI security

Microsoft Agent 365 security

Secure Microsoft AI agents

Microsoft AI agent posture management

Defender AI agents Ignite

Microsoft secure AI development

Azure AI agent security best practices

Shadow AI refers to AI-powered tools, agents, or extensions being used by users without formal IT awareness, approval, or governance.

Common examples include:
Unauthorized AI coding assistants, such as OpenClaw.
Local agents, MCP servers, and agentic command-line tools.
Browser extensions with embedded AI capabilities.

The new Shadow AI experience is designed to help administrators identify and manage these risks without unnecessarily disrupting legitimate business workflows.

One of the more interesting mechanics is the blocking workflow. When a Shadow AI agent is blocked, such as OpenClaw, Microsoft creates a new Intune policy that is automatically propagated to managed Windows devices enrolled in Intune.

For example, the Microsoft article references a policy called:
A365 - Block OpenClaw

Depending on how Intune is configured, the policy update may apply in as little as 15 minutes, but could take up to 8 hours across the estate.

This is definitely one to test in detail. The key questions for me are:

How dynamic is the detection logic?
How transparent is the policy creation and assignment process?
How much control do administrators have before enforcement?
How well does this scale across complex enterprise environments?

This feels like an important step towards governing agentic AI usage in the enterprise, especially as local agents, MCP servers, AI-enabled developer tools, and browser-based AI extensions become more common.

Official Docs : Understand Shadow AI in Microsoft 365 admin center - Microsoft 365 admin | Microsoft Learn

Tags #

#MicrosoftSecurity

#MicrosoftLearn

#CyberSecurity

#MicrosoftSecurityCopilot

#Microsoft

#MSPartnerUK

#msftadvocate

WordCloud

Secure AI Foundry

Secure AI Agent Foundry

AI Security Foundry

Secure Agentic AI

Enterprise AI Agent Security

Secure AI Operations

Secure AI at Scale

AI Safety by Design

AI-SecOps

AI-native SecOps

Microsoft Defender for AI agents

Microsoft Defender for AI security

Microsoft Agent 365 security

Secure Microsoft AI agents

Microsoft AI agent posture management

Defender AI agents Ignite

Microsoft secure AI development

Azure AI agent security best practices

On paper, it’s clean and modern. In the real world, it collides with two things that don’t fit neatly on a slide: trust and cost.

And once you add data security into the mix, the question stops being “where does the centre of the stack live?” and becomes “who owns the blast radius when it goes wrong?”

The tidy architecture everyone keeps drawing

After a couple of years of enterprise AI hype, a familiar pattern has settled in:

• Execution layer (systems of record): Salesforce, Workday, SAP/Oracle, ServiceNow. These hold the authoritative record, run workflows, and keep audit trails.

• Context layer (data platform): Snowflake, Databricks, Fabric, and similar. These unify data, enrich context, and support analytics and ML work.

• Intelligence and interaction layer (agents): Natural language requests, context retrieval, orchestration, and workflow triggers back into the systems of record.

It makes sense in theory. It’s also not how most organisations are funded or governed.

Most teams are still wrestling with data foundations and app sprawl. Adding agentic AI isn’t just “one more tool”. It’s another moving layer that touches identity, data access, workflow execution, and accountability.

“Agents replace apps” sounds nice… until you need the truth

One practical pushback keeps coming up: transactional systems don’t vanish, because they’re where work actually executes and where accountability lives.

If a sales rep asks an agent for the “truth” about CRM data, they’ll still want to verify it against the authoritative record. That verification needs a clear path back to the CRM system of record, not a vague answer that can’t be traced.

From a data security angle, that link back matters even more. When you’re challenged on a decision later, the question won’t be “what did the agent say?”. It’ll be:

• What was the source of truth?

• Who changed it?

• What evidence exists that controls were followed?

Agents can change the interface. They don’t remove the need for governed execution.

The messier reality: systems of record are already being treated like endpoints

There’s also a grounded counterpoint: plenty of Snowflake and Databricks estates already have agents and point solutions orbiting around them. Conversation intelligence tools, workflow automation, and specialised assistants often sit “above” the stack, with systems of record increasingly treated as endpoints.

That’s the real shape of “unbundling”:

• The system of record stays essential.

• But it stops being the place people spend their day.

• The agent layer becomes the surface users actually touch.

Once that happens, uncomfortable commercial questions show up fast:

• Do you still pay per seat for Salesforce if fewer people log in?

• Does value shift to the agent layer because that’s where behaviour changes?

• Does the data platform start looking like the operating system for work?

None of that resolves cleanly, because pricing models tend to lag behind how people actually work.

The awkward question vendors dodge: who pays for cross-system AI?

Here’s where it gets real.

Agentic AI is cross-system by design. But most enterprises are organised in silos by budget, accountability, and risk. So when someone presents the elegant “agent layer spanning the enterprise” vision, the operational question is painfully simple:

Who signs the PO?

• Data platforms are often funded under analytics budgets, measured on quality, reliability, and cost control. They rarely own end-to-end user outcomes.

• Transactional applications are owned by departments. Sales ops funds Salesforce, HR owns Workday, finance owns ERP. Each has its own priorities and tolerance for change.

• Central IT is expected to enable and standardise, but often doesn’t hold the budgets for the apps that matter most day-to-day. Or budget to SECURE THEM!

This is how you get the classic “everyone agrees, nobody funds it” pattern.

Why systems of record still hold the ground that matters

Even if agents become the interface, systems of record keep strategic gravity for four reasons:

1. They remain the authoritative record
   When an agent answers questions about customers, contracts, patients, or finances, verification matters. The organisation expects truth to live in a governed system with ownership and stewardship.

2. They execute workflows with state and control
   “Doing the work” isn’t the same as “moving data”. Approvals, segregation of duties, exception handling, rollback paths, and audit evidence are hard-earned capabilities.

3. They carry process meaning, not just APIs
   The hard part isn’t connecting systems. It’s agreeing what a “customer”, “order”, or “employee” means across them, and how processes really work when exceptions hit.

4. They own the user relationship and operational muscle memory
   Teams have trained people, built processes, and carry accountability for outcomes. Even if the screen changes, the ownership doesn’t evaporate.

In regulated industries, this becomes non-negotiable. You can’t have probabilistic systems updating critical records without strong controls, traceability, and clear accountability.

Everyone wants to own orchestration (because that’s where leverage lives)

The orchestration layer is where user experience lives, where behaviour changes, and where commercial leverage tends to land. That’s why multiple players can make plausible claims:

• Microsoft can push Copilot as the horizontal interface because it sits across identity and day-to-day work surfaces. The challenge is depth across wildly different business rules and data models.

• Salesforce can position Agentforce because it already sits in customer execution paths. The challenge is persuading organisations a CRM vendor should own the wider agent strategy.

• ServiceNow has a strong story where work spans systems and needs control, especially across IT and operations. The challenge is expanding beyond its historic core.

• ERP and HCM platforms (SAP, Oracle, Workday) bring deep governance in their domains. The challenge is orchestrating beyond their ecosystems without building another garden wall.

The likely outcome isn’t one orchestration layer. It’s multiple orchestration surfaces aligned to organisational boundaries, because that’s how budgets, accountability, and risk management already work.

The data effects nobody should ignore: context changes risk

Agents thrive on context. Context is built from data. And data rarely behaves the way the slide deck suggests.

When you unify context in a data platform, you also create new security and governance pressure points:

• Data lineage becomes a security requirement, not a “nice to have”
  If an agent makes a recommendation, you’ll want to know which datasets shaped it and whether they were current.

• Access patterns shift from “user opens app” to “agent queries everything”
  That changes the threat model. It’s no longer just interactive access; it’s automated, cross-system, and often high volume.

• The risk of inappropriate disclosure rises quietly
  A single prompt can pull sensitive context into a response. That’s a data privacy problem as much as it is a security problem.

This is where “Generative AI security” stops being a headline and becomes day-to-day operational design.

So what’s the cost, really?

There’s the obvious cost: licences, platforms, implementation, and ongoing operations.

But the harder cost is the one that shows up later:

• Duplicated spend as departments buy their own agents and point solutions “just to move faster”

• Higher data platform bills because warehouse usage grows when it becomes the context engine (try defending a 40% increase because it “enables other teams”)

• Governance overhead because security, legal, and compliance will require controls that many early agent deployments don’t include

• Incident cost when the wrong action is taken, the wrong record is updated, or sensitive context is exposed

And then there’s the cost nobody likes naming: ownership. If an agent acts across systems, the organisation needs to agree who owns outcomes, who owns failures, and who carries audit responsibility.

Governance is the forcing function most demos underplay

Every agentic architecture quietly assumes the same thing: agents can query context here, execute there, and update elsewhere.

That’s not how regulated environments run once security, legal, and compliance lean in. The questions become direct:

• Where is the audit trail?

• What identity executed the action?

• What data was used as context?

• Was the agent authorised to access that data in that moment?

• What controls prevent exfiltration or inappropriate disclosure?

• What policy constrains high-risk workflows?

• What evidence exists for an auditor?

In the real world, governance isn’t an overlay. It’s the shape of the system.

If agents must operate through governed platforms rather than around them, systems of record keep their commercial gravity even if the interface becomes more agent-driven.

Where this lands: architecture is easy, operating models are hard

Right now, most organisations are still in the architecture phase, not the operating model phase:

• People still work inside the same apps they’ve always used.

• Data platforms are being modernised to support departmental AI initiatives.

• Agentic tooling is adopted opportunistically, often without coordination.

• Governance and security lag in less regulated areas, and clamp down quickly in regulated ones.

The clean “agent layer across the enterprise” story might come later. But the path there runs through cost models, ownership, security and governance that actually fits how enterprises are funded and audited.

If you’re exploring AI cybersecurity tools, incident summarisation with AI, or broader cyber threat response automation, the best move is to treat agents like what they really are: a new interface to your data and execution systems. That interface can be brilliant. It can also be expensive and risky if you don’t design for trust from day one.

If you’re seeing this play out in your own stack, I’d love to hear what’s getting in the way: funding, identity, data quality, or the sheer politics of “who owns it”.

Tags #

#MicrosoftSecurity

#MicrosoftLearn

#CyberSecurity

#MicrosoftSecurityCopilot

#Microsoft

#MSPartnerUK

#msftadvocate

WordCloud #

Secure AI Foundry

Secure AI Agent Foundry

AI Security Foundry

Secure Agentic AI

Enterprise AI Agent Security

Secure AI Operations

Secure AI at Scale

AI Safety by Design

AI-SecOps

AI-native SecOps

Microsoft Defender for AI agents

Microsoft Defender for AI security

Microsoft Agent 365 security

Secure Microsoft AI agents

Microsoft AI agent posture management

Defender AI agents Ignite

Microsoft secure AI development

Azure AI Foundry security

Secure Azure AI Foundry patterns

Azure AI agent security best practices

Share

When you pair agents with a platform like Foundry, the conversation shifts from “can it generate text?” to “can it run safely, scale cleanly, and be operated like any other service?”

Quick caveat: I’m not an expert in agents or Foundry — I’m a critical thinker, who’s curious, slightly sceptical, and trying to learn out loud. I’m sharing how I’m thinking about multi-agent systems as I explore the space, “I intend to apply to security agents” with a focus on what feels practical (and what still feels fuzzy). If you’re deeper in this world, I’d genuinely welcome your views, and if there are experts, papers, talks, or real-world deployments you think I should be reading, please point me in the right direction via comments!

Most don’t need this level of platform thinking yet — and that’s fine. But architecturally, it’s genuinely fascinating.

Agents are more than chat: they reason, act, and remember

An agent isn’t just a prompt with a personality. It’s typically a combination of:

• A model that can reason through a problem

• Tools it can call to take action (query data, run code, trigger processes)

• Memory or context so it can keep track of what matters across steps

That mix is what makes agents useful in day-to-day IT and security work. Instead of asking for an answer, you’re asking for an outcome.

Why one agent quickly hits a wall

Single agents work fine for simple tasks. But once you ask for anything that involves multiple steps, pulling data, cleaning it up, analysing it, then writing it out clearly, - one agent starts to behave like one person trying to do five jobs at the same time.

This is where multi-agent orchestration earns its keep. You split the workload into specialists, then coordinate them so the overall flow stays clear and repeatable. Typical roles look like:

• A coordinator that plans and delegates

• One or more retrieval agents that gather the right inputs

• A preprocessing agent that turns messy data into clean structure

• An analysis agent that does the heavy thinking (and sometimes generates code)

The big win isn’t “more AI”. It’s less chaos, because each agent has a clear job.

The reliability trick: deterministic workflow, flexible intelligence

Here’s the part I keep coming back to: LLMs are non-deterministic. Ask the same thing twice and you may not get the exact same output. That’s normal, but it’s awkward when you’re trying to run operations.

A strong approach is to put the agent inside a deterministic workflow:

• The workflow is predictable: step 1, step 2, step 3

• The agents are flexible: they can reason and adapt inside each step

That combination gives you something that’s far easier to trust. You get the creativity and problem-solving of the model, without sacrificing the structure you need for production.

Microsoft Agent Framework: a single direction for building agents

Microsoft Agent Framework is the recommended path for building new pro-code agents. It’s also the result of converging the SDK work that previously lived across Semantic Kernel and AutoGen.

From reading the first page, this is geared around,

• Building agents with reasoning, tools, and memory

• Building orchestrated workflows that keep outcomes consistent

Agent Framework is in public preview. Use the link to take a read.

No-code AI development platforms

No-code AI platforms let you build and tailor AI agents without writing code. They usually come with a conversational interface and drag-and-drop building blocks. You can create an agent from scratch using agentic workflows, or start from a ready-made template designed for common scenarios.

To shape what the agent can do, you visually connect different blocks — for example natural language understanding, decision logic, and data integrations. This makes it easier to prototype and iterate quickly.

Templates go one step further for clearly defined tasks. In most cases you pick a template, provide your training data, and deploy the agent into the ecosystem you want, all without needing to code.

Pro-code AI agent development platforms

Pro-code platforms follow a traditional development approach, where developers handle the full build process in code. It’s more hands-on, but it gives you complete flexibility and control over how the agent behaves.

You typically use mainstream languages like C++, Python, or JavaScript (along with their libraries) to build agents from the ground up. The platform’s role is mainly to bring the tools, frameworks, and deployment resources together in one place.

Foundry Agent Service: where agents become something you can actually run

Can we call this a new acronym, FASAAS? Building an agent is one thing. Running it like a service is another.

Hosted Agents in Foundry Agent Service is positioned as the “run and operate” layer — aimed at deploying pro-code agents and managing them with the kind of controls you’d expect in an enterprise environment.

The capabilities are the sort of things ops teams ask for immediately:

• Managed runtime with serverless auto-scale and dedicated execution environments

• Context management via a Responses API

• Versioning and lifecycle management

• Integrated tools and data, including managed authentication for remote MCP servers

• Observability: traces, metrics, debug logs, and cost analysis

• Evaluation and governance: continuous evaluations and guardrails via the Foundry control plane

• Interoperability: paths into broader Microsoft ecosystems (including activity protocol support)

• Enterprise security and data sovereignty, including bring-your-own virtual network and state storage options

If you’ve ever had to explain to leadership why a “quick AI pilot” needs controls, this is the part of the story that helps.

Seeing the workflow matters more than most people expect

One of the most practical pieces of the agent experience is simply being able to see what happened.

A developer UI that visualises workflows — showing the agent map, the step timeline, and when human input is required — turns an “AI black box” into something you can reason about. It’s also much easier to troubleshoot, because you can trace:

• Which step ran

• Which tool was called

• Which model was used

• What succeeded, what failed, and where it got stuck

That’s not a “nice to have”. It’s how multi-agent systems become operable.

A simple example: planning work without drowning in details

A good way to picture multi-agent orchestration is a planning workflow.

You might have a coordinator agent that breaks a task into streams like venue, budget, catering, logistics — then delegates each stream to a specialist agent. The system can pause when it needs a human decision (like choosing a city), then continue once that input arrives.

Now imagine this for a SOC analyst!

It’s a small example, but it mirrors real work: most operational tasks aren’t hard because they’re complex — they’re hard because they’re multi-step and interdependent.

Resilience: durable agents that don’t lose their place

Multi-step work breaks. Services restart. Humans take time to reply.

That’s why the durable task extension matters. The idea is to create checkpoints as the workflow runs, so if something fails you restart from the last checkpoint rather than starting from scratch.

This becomes even more valuable when the workflow includes human-in-the-loop steps that might pause for minutes… or days.

Governance: bringing policy into the agent loop with Purview

If you’re serious about running agents at scale, you need to be serious about data.

A practical approach shown here is injecting Microsoft Purview policy middleware into agents so requests and responses can be inspected, logged, and blocked when sensitive data is involved. That activity can then surface in Purview’s Activity Explorer, including detections for sensitive information.

A blog post coming on this when i understand exactly how it’s possible!

Seven practical considerations before you go anywhere near production with any sort of multi-agent flow!

1. Design agent roles first
   Split work into retrieval, preprocessing, analysis, and orchestration before you write prompts.

2. Keep the workflow predictable
   Let agents reason inside steps, but keep the step order consistent so outcomes stay steady.

3. Make it observable from day one
   If you can’t trace steps, tool calls, and decisions, you’ll struggle to support it under pressure.

4. Treat data prep as a first-class problem
   Raw inputs are rarely ready. Plan for preprocessing as its own responsibility.

5. Bake policy into the flow
   If sensitive data matters (and it does), use middleware and auditing early, not as an afterthought.

6. Design for failure and restart
   Checkpoints and durable orchestration turn outages into recoverable interruptions.

7. Own versioning and lifecycle
   If you can’t compare versions, roll forward safely, and manage deployments cleanly, you don’t really have a platform.

Wow that was alot!

Agents are moving past “chat that sounds clever” and into “systems that do work”.

You probably don’t need this level of platform thinking yet — and that’s fine. But architecturally, it’s genuinely fascinating.

Foundry’s real value isn’t in flashy prompts or clever demos. It’s in the unglamorous stuff: making agent-driven work deployable, observable, governable, and repeatable. Those “boring bits” are exactly what turns AI from something you try once into something you can run every day without holding your breath.

Unless you’re already deep in this world, you’ll usually get further, faster by starting low-code or no-code. It’s the quickest way to prove value, learn what’s possible, and spot what actually matters in your environment. That said, it never hurts to understand what the pro-code experts can do — because sooner or later, you’ll hit a point where flexibility, control, or scale becomes the real requirement.

My takeaway

If you’re exploring this space, here’s the question I’d sit with: where is your team losing time turning messy inputs into something usable — and what would change if a multi-agent workflow handled that reliably, with clear visibility and the right controls built in? Do you need an agent or just a Logic App?

The Hype is real. Hopefully, some real problems will be solved with some of this new tech!

More thoughts soon,

Marcus

Tags #

#MicrosoftSecurity

#MicrosoftLearn

#CyberSecurity

#MicrosoftSecurityCopilot

#Microsoft

#MSPartnerUK

#msftadvocate

WordCloud #

Secure AI Foundry

Secure AI Agent Foundry

AI Security Foundry

Secure Agentic AI

Enterprise AI Agent Security

Secure AI Operations

Secure AI at Scale

AI Safety by Design

AI-SecOps

AI-native SecOps

Microsoft Defender for AI agents

Microsoft Defender for AI security

Microsoft Agent 365 security

Secure Microsoft AI agents

Microsoft AI agent posture management

Defender AI agents Ignite

Microsoft secure AI development

Azure AI Foundry security

Secure Azure AI Foundry patterns

Azure AI agent security best practices

So yes, I’m late to the party. But this is one of those “better late than never, and definitely before 1.3 billion agents land in your estate” moments.

Let’s unpack what this actually is, and more importantly, what it means if you enable it in a real, messy, sprawling enterprise with multiple teams building agents all over the place. (Any large company now!

Helpful Microsoft Content - Here

Wait, what did Microsoft actually announce?

In the session “From risk to resilience: Secure your AI agents with Microsoft Defender” (BRK264), Microsoft essentially introduced AI agents as a first-class security asset in Defender, with capabilities that cover:

• Visibility & posture – inventory of AI agents, misconfigurations, attack paths.

• Runtime protection – jailbreak detection, blocking risky tool invocations in real time.

• Hunting & investigations – new AI agent–specific tables in Advanced Hunting, with pre-built community queries.

This is all part of a broader story with Microsoft Agent 365 as the control plane for agents, plus Entra for identity and Purview for data security – but Defender is the bit that really matters to your SOC and security engineering teams.

The headline stat they anchored this on: IDC estimates 1.3 billion AI agents will be created by 2028. That’s effectively like dropping the population of India or China into your workforce, but made of bots.

And those agents aren’t just “chatbots.” They’re:

• Customer service agents triaging tickets

• Sales agents updating CRM

• Agents reading mailboxes and firing workflows

• Code-focused agents using tools and repositories

All of them are sitting on top of sensitive data and powerful tools.

Why agents change the threat model (and why this isn’t just another dashboard)

The session does a good job of making one point very clear: agentic AI introduces new attack surfaces that don’t look like traditional malware or “bad IP” events.

A few of the real-world examples they called out:

• ShadowLeak – an email-reading AI agent that exfiltrated data, not because of a phishing click, but because it misinterpreted hidden instructions in the content it was reading.

• Salesforce AgentForce data exposure – CRM agents leaking confidential customer data via prompt abuse.

• Anthropic / Claude “code manipulation” case – where attackers effectively hacked the agent’s “brain” via crafted instructions rather than the infrastructure.

The big takeaway:

Attackers don’t need to compromise servers if they can just convince your agent to misuse its tools.

That’s why Defender’s approach here is split into two big buckets:

1. Start secure (posture) – make sure agents are built and configured safely in the first place.

2. Stay secure (runtime) – watch what agents are actually doing and block them when they go off the rails.

   

So what happens if you enable this in a sprawling environment?

Let’s get practical. Say you’ve got:

• Copilot Studio agents built by business teams

• “Code-first” agents built on Foundry by devs

• A mix of clouds (Azure, maybe some AWS/GCP for data or tools)

• A bunch of shadow agents you probably don’t know about yet

What actually changes when you turn on these new Defender capabilities?

1. Admins finally get “one pane of glass” for agents

Defender introduces a unified AI agent inventory alongside your existing assets (identities, endpoints, etc.). You can:

• See all agents across Copilot Studio, Foundry and other integrated platforms in one place.

• Sort and prioritize agents by risk, not just by name or owner.

• Drill into an agent and see:

  • Which tools it can invoke (e.g., data access MCP servers, email senders)

  • What data it’s grounded on

  • Which other agents it calls

  • Whether Exposure Management has flagged it as a critical asset

In a large estate, that’s huge. It turns “random AI projects” into discoverable, classifiable, governable assets.

2. Posture becomes a shared responsibility between builders and security

Defender surfaces agent-specific security recommendations – things like:

• “This agent invokes another agent but has no explicit instruction on how to use it”

• “This agent is grounded on sensitive data but is missing guardrails”

• “This MCP server has broader permissions (read/write/modify) than the agent realistically needs”

The clever bit: those same recommendations turn up in the builder platforms (e.g., Foundry), not just inside Defender. So instead of security sending a giant PDF, the dev/creator sees issues where they work, and the SOC sees them in their world.

This pushes you towards an agent DevSecOps model by default.

3. Attack paths now include agents – not just VM → DB

Defender’s attack path analysis pulls agents into the graph:

• Agents

• Their identities

• The containers/pods they run in

• The repos and images that define them

• The cloud resources and data they touch

You end up with attack paths like:

Internet-exposed container → managed identity → AI agent → sensitive data tool → exfiltration

That’s very different from a classic “compromised user → mailbox” storyline, and it’s exactly the kind of thing you’re going to need to reason about as agents get closer to business-critical workflows.

What changes for the SOC?

From a SOC perspective, this isn’t a “nice to have”: it’s a new class of signals you’ll need to own.

1. New alerts and incidents tied to agents

Defender can now:

• Detect jailbreak attempts against agents (e.g., hidden instructions in emails or CRM fields)

• Block malicious tool invocations in real time (e.g., stopping an agent from sending external emails or writing to a datastore)

• Correlate multiple agent-related alerts into a single incident graph that:

  • Shows the attacker’s sequence of attempts

  • Highlights the affected agents

  • Surfaces the tool invocations that were blocked

So your incident queue stops being “just endpoints and identities” and starts including agent-centric incidents with rich context.

2. New hunting tables and AI agent queries

They’ve added agent-focused tables into Advanced Hunting – for example, agent info and activity – plus a set of community queries to help you:

• Find agents with excessive permissions

• Identify agents grounded on sensitive data without adequate controls

• Spot misconfigured or “risky” agents by pattern

This is where your hunters and SIEM engineers will start to build patterns and baselines for AI behaviour, not just user behaviour.

3. Runbooks need to include “what if the agent is the problem?”

Traditionally, the playbook ends with:

• Block user

• Isolate device

• Kill process

With agents, you now have additional actions like:

• Unpublish or disable the agent

• Revoke or reduce MCP tool permissions

• Quarantine the agent in Defender (this is something they’ve hinted at in future capabilities, aligned to how they do automated attack disruption for non-human identities).

Your SOC capability is going to need to catch up – fast.

Do we need to think about Sentinel telemetry and custom rules now?

Short answer: yes – if you’re a Sentinel shop, this should already be on your roadmap.

Defender is adding AI agent events into its own Advanced Hunting and incident pipeline. From there, you’ve got a few patterns to think about:

1. Incidents into Sentinel

   • Many orgs already use the Defender → Sentinel incident connector.

   • Agent incidents (jailbreak attempts, blocked tool invocations, misconfigurations leading to risk) become just another incident type you can correlate with everything else – identity, endpoint, OT, etc.

2. Raw telemetry into Sentinel

   • As agent-centric tables become available through Defender’s data export or native connectors, you should treat them like any other critical log source:

     • Map them into your data schema strategy

     • Plan retention based on risk/value, not “log everything forever”

     • Decide which events are high-signal enough to justify analytics rules

3. Custom analytics rules for AI agents
   Here are a few I’d be looking at designing early:

   • Repeated jailbreak attempts against a single agent

     • If one agent is constantly being probed, it’s a canary – or a high-value target.

   • Agents invoking sensitive tools outside normal behaviour

     • E.g., customer support agent suddenly bulk-reading “VIP customers” or exporting unusual datasets.

   • Agents with powerful MCP tools but no clear business owner

     • Shadow IT, but for agents.

   • Cross-signal correlation

     • Agent alert + unusual user sign-in + data exfil signal = much higher priority than any of those alone.

This isn’t about flooding Sentinel with yet more tables. It’s about deciding which AI events actually matter for detection engineering – and treating them with the same discipline you (hopefully) apply to your other high-value logs. This is a tough call

How I’d roll this out without creating chaos

If you’re thinking “this sounds great but my environment is already wild,” here’s a pragmatic way to approach it.

1. Start with a discovery sprint

• Turn on the AI agent inventory in Defender.

• Pull a list of:

  • Agents

  • Owners

  • Tool permissions

  • Data sources

• Sit down with platform / app owners and ask the simple question:

“Which of these are business-critical, and which are ‘experiments that got out of hand’?”

2. Define your “tier 0” agents

Not all agents are equal. Decide which ones are:

• Exposed to external input (email, web forms, support tickets)

• Connected to sensitive data or powerful tools

• In production workflows (not just POCs)

Those become your Tier 0 / crown jewel agents, and they get:

• Stricter posture requirements

• Tighter MCP permissions (least privilege, genuinely enforced)

• Dedicated monitoring and response playbooks

3. Wire agents into your SOC workflows

• Enable the Defender agent protections and incident integration.

• Update your triage process to recognise:

  • “AI jailbreak attempt”

  • “Malicious tool invocation blocked”

• Build or import the hunting queries that surface risky agents.

• Design 1–2 Sentinel analytics rules specifically around high-risk agent scenarios (start small – don’t try to boil the ocean).

4. Add agents to your security reviews and change processes

• Make sure new agent projects can’t go live without:

  • An Entra identity / registry entry (via Agent 365 as it matures)

  • A risk assessment and owner

  • A Defender posture review (just like you’d do for a new critical app)

• Include agents in your regular exposure management reviews and threat modelling.

Wrapping up

I definitely missed this announcement in the noise of Ignite week, but having gone back through the session, I’d put this firmly in the “quietly massive” category.

We’re about to live in a world where agents are everywhere – reading mailboxes, updating CRMs, calling APIs, dropping tickets into queues. If we keep treating them as “just another Copilot experiment,” we’re going to get caught out.

Defender’s new AI agent capabilities don’t magically solve everything, but they give us three things we’ve badly needed:

• A proper inventory of agents

• Posture and attack path analysis that actually understands agent risk

• Runtime detections and hunting that treat agents as first-class citizens in our SOC

If you’re running Sentinel and Defender today, this is the moment to start threading AI agent telemetry into your logging strategy, detection engineering, and incident handling, not bolt it on later as an afterthought.

If you’ve already turned this on, or you’re piloting it:

• What have you found in your environment?

• Any surprises, false positives, or “wow, that agent really shouldn’t have had that permission” moments?

Hit reply or share your experiences – this is an area where we’re all going to be learning fast, and I suspect the community war stories will be as valuable as the product docs.

Catch you soon!

Tags #

#MicrosoftSecurity

#MicrosoftLearn

#CyberSecurity

#MicrosoftSecurityCopilot

#Microsoft

#MSPartnerUK

#msftadvocate

WordCloud #

Secure AI Foundry

Secure AI Agent Foundry

AI Security Foundry

Secure Agentic AI

Enterprise AI Agent Security

Secure AI Operations

Secure AI at Scale

AI Safety by Design

AI-SecOps

AI-native SecOps

Microsoft Defender for AI agents

Microsoft Defender for AI security

Microsoft Agent 365 security

Secure Microsoft AI agents

Microsoft AI agent posture management

Defender AI agents Ignite

Microsoft secure AI development

Azure AI Foundry security

Secure Azure AI Foundry patterns

Azure AI agent security best practices

You do not really pay “per connector”.
You pay per table, per gigabyte, per day.

Connectors are just the taps. Log Analytics tables are the meter.

The challenge has always been getting a clean, reliable answer to a deceptively simple question:

“For this Sentinel solution or connector, exactly which Log Analytics tables will light up, and which content depends on them?”

That is the gap the Sentinel Solutions MCP Server (sentinel-solutions-mcp) closes. Full credit to noodlemctwoodle (noodlemctwoodle) !

It acts as an MCP (Model Context Protocol) server that crawls Microsoft Sentinel solutions from any GitHub repository and maps data connectors → Log Analytics tables → content (detections, workbooks, hunting queries, parsers, playbooks, and more). It ships with a pre-built index of the entire Microsoft Sentinel Content Hub and can also target your own private/custom Sentinel solution repos. LobeHub+1

This post looks at why that matters so much for cost, design, and operations.

The core problem: Sentinel cost is driven by tables, not marketing labels

Most Sentinel conversations still begin with features and connectors:

• “We’ll onboard Defender XDR, Office 365, Identity, etc.”

• “We’ll deploy these out-of-the-box solutions from Content Hub.”

But Sentinel billing never heard of “solutions”. It only knows:

• Which tables are receiving data

• How much data per table

• What retention, archive, and search you apply

That means any serious cost and design conversation has to be grounded in:

Connector → table → content mapping

Without that mapping, you are effectively guessing: (You can manually map!)

• You switch on connectors because they “look useful”

• Tables start ingesting large volumes of data

• Only a portion of that data is referenced by any of your rules, hunting queries, workbooks, dashboards, or compliance reporting

The result is familiar:
Sentinel is perceived as “expensive”, but nobody can clearly say which data is worth it and which is not.

What the Sentinel Solutions MCP Server actually does

At a high level, the Sentinel Solutions MCP Server:

• Reads Sentinel solutions from any GitHub repository (not just the official Azure/Azure-Sentinel)

• Applies multiple resolution strategies (KQL parsing, ARM template analysis, connector metadata, parser resolution, and more) to identify which tables each connector writes to

• Builds and ships a pre-built LLM-friendly index of the entire Microsoft Sentinel Content Hub, covering thousands of:

  • Solutions

  • Detections

  • Workbooks

  • Hunting queries

  • Playbooks

  • Parsers

  • Watchlists

  • Functions / ASIM content / summary rules / tools

Because it is implemented as an MCP server, an AI agent (or your Copilot-style workflow) can query it through well-defined tools such as:

• analyze_solutions – full analysis with connector–table mappings

• get_connector_tables – for a single connector, list all associated tables

• list_data_connectors, list_detections, list_workbooks, list_parsers, etc. – to explore the content landscape

All of this can be done against:

• The official Content Hub

• Your forked Content Hub (e.g., for testing changes)

• Your own internal Sentinel solutions repo (customer-specific, industry packs, MSSP content) LobeHub+1

In other words, it gives you a machine-readable map of how your content relates to your data.

Why this matters for cost optimisation

1. Stop paying for unused or underused data

With connector–table mapping in place, you can finally answer:

• Which tables have high ingestion volume but no active detections using them?

• Which connectors are feeding tables that only support legacy or rarely used content?

• Where are we keeping data hot in Analytics that is only ever needed for long-term investigations or compliance?

From there, you can:

• Decommission or down-scope connectors that do not justify their cost

• Move certain tables to Basic or Archive where appropriate

• Standardise on a smaller number of strategic connectors for each domain (identity, email, endpoint, SaaS, etc.)

This is not “optimisation by guesswork” – it is optimisation driven by a clear dependency map.

2. Make cost decisions as risk decisions

The dangerous way to cut Sentinel cost is to blindly disable connectors or reduce retention.

The safer way is:

1. Use the MCP server to map:
   Connector → tables → detections / hunting / workbooks / ASIM content

2. For each proposed change, produce a clear impact statement:

   • “We will lose N detections of severity X–Y”

   • “We will drop visibility on these specific threat scenarios”

   • “These workbooks/dashboards will have gaps”

Now cost tuning becomes a risk trade-off that can be explained, reviewed, and signed off by security and risk owners, rather than quietly flipping switches in the portal.

Why it matters for service design and productisation

For an MSSP, central platform team, or security architecture function, this mapping is fundamental.

1. Designing Sentinel-based service tiers with real numbers

If you want to build repeatable Sentinel offerings (Core XDR, Premium MDR, OT Add-on, etc.), you need to know:

• Which solutions you include in each tier

• Which connectors those solutions require

• Which tables those connectors populate

• What the approximate ingestion footprint is likely to be

By querying the MCP server against the official Content Hub plus your custom solutions repository, you can design your packages based on actual mappings, not assumption:

• “Our Core package requires these connectors and these tables. Here is what we monitor and what it roughly costs.”

• “Our Advanced package adds these additional solutions and tables, with a predictable increase in ingestion.”

That directly improves:

• Pricing accuracy

• Margin predictability

• The quality of your sales narratives (“Here is exactly what we turn on for you and why it costs what it does”).

2. Repeatable onboarding and migration

Connector–table mapping also underpins repeatable onboarding:

• For each new client, you can have standardised blueprints:

  • “For this industry pattern, we enable these solutions → these connectors → these tables.”

• You can more easily compare tenants:

  • “Customer A and B are on the same service tier, but B is ingesting 40% more data from the same tables – why?”

When you integrate this MCP server into your internal toolchain or AI assistants, those comparisons become trivial queries instead of days of manual KQL and JSON spelunking.

Why exposing this via MCP is a step-change

The choice to implement this as an MCP server is not just a packaging detail. It is strategic. Any MSSP or engineering team should be building some sort of industrialised cross-tenant way to analyse all client environments.

MCP gives you:

• Standardised tools that any compliant AI agent can call

• The ability to embed this knowledge into:

  • Copilot-like assistants for your SOC

  • Internal automation that checks whether a proposed tuning change will break content

  • Design assistants that help architects explore solution impact

You move from:

Humans manually grepping GitHub and YAML files

to:

“Show me all Sentinel solutions in our repo that rely on tables from the Office 365 connector, and list the detections that would be impacted if we reduced retention on those tables.”

That is a very different operating model.

Practical uses you can try immediately

Once you have the Sentinel Solutions MCP Server wired into your environment, there are some immediate, high-value use cases:

1. Build a Connector–Table–Content Catalogue
   Generate an internal catalogue that shows, per connector:

   • Tables produced

   • Linked detections (with MITRE mappings)

   • Linked workbooks and hunting queries
     Use it as a reference in architecture reviews and cost boards.

2. Pre-flight checks before enabling new solutions
   Before you deploy a new Content Hub solution:

   • Query which tables will be used

   • Estimate ingest impact

   • Confirm there is a clear detection and reporting benefit

3. Cost optimisation sprints
   Run targeted campaigns to identify:

   • High-volume tables with low or no content usage

   • Legacy connectors that can be retired or replaced

   • Opportunities to move data to cheaper tiers without losing essential coverage

4. Service tier definitions for an MSSP
   Use the mapping to:

   • Define exactly which solutions and connectors belong in each service SKU

   • Attach estimated ingestion ranges per SKU

   • Create transparent, repeatable designs instead of one-off, hand-crafted deployments

Closing thoughts

Sentinel has always promised rich, integrated security telemetry across Microsoft and beyond. The downside is that without discipline, it is easy to end up with a sprawl of connectors, overlapping data, and unpredictable bills.

The Sentinel Solutions MCP Server gives you something that has been missing for a long time:

• A programmatic, up-to-date map of how Sentinel solutions and connectors translate into tables and content.

• A way to put that map in front of AI agents and architects so they can make informed decisions about coverage, cost, and design.

If you are serious about standardising on Microsoft Sentinel—whether as an enterprise or an MSSP—this kind of connector–table insight is no longer a nice-to-have. It is the foundation for:

• Sustainable cost optimisation

• Credible service design

• Safe, explainable tuning decisions

In short, it is the difference between “we turned on some connectors” and “we know exactly what we are collecting, why it matters, and what it costs.”

#MicrosoftSecurity

#MicrosoftLearn

#CyberSecurity

#MicrosoftSecurityCopilot

#Microsoft

#MSPartnerUK

#msftadvocate

Whether you’ve been meaning to finally conquer Microsoft Sentinel, level up your Defender XDR game, or get hands-on with Security Copilot, the Ninja series gives you structured, real-world learning paths you can work through at your own pace.

And don’t keep it to yourself! Share this with your team and network so you can all hit 2026 on the way to being fully fledged Microsoft Security Ninjas. 🥷🚀

*All the trainings I know about! Please comment if you notice anything missing!

Become a Microsoft Security Ninja 2026

• Security Copilot – How to Become a Microsoft Security Copilot Ninja

• Microsoft Defender XDR - Become a Microsoft Defender XDR Ninja

• Microsoft Security Exposure Management Ninja Training

• Defender for Office 365 – Microsoft Defender for Office 365 Ninja Training

• Defender for Endpoint – Microsoft Defender for Endpoint Ninja Training

• Defender for Cloud Apps – Microsoft Defender for Cloud Apps Ninja Training

• Azure Network Security Ninja Training

• Defender for Identity – Microsoft Defender for Identity Ninja Training

• Microsoft Sentinel – Microsoft Sentinel Ninja Training

  • Become a Microsoft Sentinel Automation Ninja!

  • Becoming a Microsoft Sentinel Notebooks Ninja!

• Defender for IoT – Microsoft Defender for IoT Ninja Training

• Microsoft Defender Threat Intelligence (MDTI) Ninja Training

• Defender for Cloud – Become a Microsoft Defender for Cloud Ninja

• Defender Vulnerability Management - Become a Microsoft Defender Vulnerability Management Ninja

• Microsoft Purview eDiscovery Ninja

• Insider Risk Management Ninja

• Microsoft Priva Ninja Training

• Microsoft Purview Information Protection and Data Loss Prevention Ninja

Bonus for those looking to learn even more - Microsoft Incident Response Ninja Hub

So grab a coffee, pick a Ninja path, and start ticking a few off before the year resets. Your future self will thank you. And if this helped, pass it on so the rest of the team can level up with you. 🥷✨

Subscribe now

#MicrosoftSecurity

#MicrosoftLearn

#CyberSecurity

#MicrosoftSecurityCopilot

#Microsoft

#MSPartnerUK

#msftadvocate

Enterprise management and External Access have never been more important to secure!

Modern enterprises rely on increasingly interconnected ecosystems — federated Teams domains (hopefully your blocking by default) shared Power BI workspaces, and delegated admin relationships across Entra ID and Lighthouse into Azure. Each connection extends your perimeter into another organisation’s security posture.

While most organisations continue to prioritise penetration tests, few measure or rehearse their relationship resilience, “the ability to detect, contain, and coordinate a response when a partner’s tenant becomes the initial compromise vector.”

Rethinking Third-Party Risk

Traditional supplier assessments and periodic pen tests provide static assurance. But cross-tenant external risks evolve dynamically through identity federation, token replay, and delegated administration. Attackers now exploit the weakest link across trust boundaries, not just within a single configuration.

Thinking in a “Microsoft” mindset, I would imagine most cross-tenant incidents (from a “Trusted” external party) originate from:

• Compromised partner accounts with legitimate access routes.

• Over-privileged B2B or GDAP relationships left active beyond contract expiry.

• Lack of joint incident response readiness between partner organisations.

To manage this, enterprises must start thinking about operational readiness at the point of onboarding, not just compliance — through preemptive domain screening, simulation, verification, and proactive lifecycle governance.

Overview of external collaboration options in Microsoft 365

10 Practical Steps to Strengthen Third-Party Access Security

1. Map and Classify Every Cross-Tenant Connection

Start by identifying all integrations: Teams federations, Entra B2B trusts, and GDAP links. Classify each as Collaboration, Application, or Administrative to define required controls and review frequency.

2. Adopt a “Deny-by-Default” Collaboration Policy

Enable Microsoft 365 external collaboration only with approved domains. Maintain an allow-list enforced via Teams and Entra ID. Unlisted domains should be automatically blocked at both chat and file-sharing layers.

3. Implement Conditional Access for Guests and Partners

Extend Conditional Access policies to cover guest users:

• Require MFA for every external login (unless explicitly trusting partner MFA).

• Restrict file downloads from unmanaged devices.

• Block high-risk sign-ins identified by Entra ID Identity Protection.

4. Run Joint Tabletop Exercises with Key Partners

Treat cross-tenant incident simulations as mandatory. Rehearse scenarios such as:

• A compromised partner admin with GDAP privileges.

• Malicious activity through federated Teams channels.

• Revocation of tokens or roles mid-incident.
  Tabletop playbooks should mirror live SOC escalation paths and decision ownership.

5. Require Evidence of Security Hygiene Before Granting Access

Before onboarding a partner, perform due diligence:

• Review their Microsoft Secure Score or equivalent assessment.

• Validate SPF/DKIM/DMARC alignment for email domains.

• Confirm MFA and Conditional Access are enforced across their tenant.

No access should proceed without verified identity security.

6. Use Entitlement Management for Lifecycle Control

Leverage Microsoft Entra Entitlement Management to automate onboarding, approval, and expiry of external users. Access Packages ensure every guest account has a business sponsor, a defined duration, and automatic removal.

7. Monitor Partner and Guest Activity in Sentinel

Integrate guest and cross-tenant activity into Microsoft Sentinel or XDR analytics.
Alert on:

• Unusual download volumes.

• Administrative role elevation attempts.

• Sign-ins from unexpected geolocations or partner tenants.

Operational telemetry should be continuously validated through detections and analytics rules.

8. Harden and Periodically Test GDAP Relationships

Review every Granular Delegated Admin Privilege (GDAP) assignment:

• Scope roles to the minimum necessary (e.g. Security Reader instead of Global Admin).

• Set time-bound durations (no longer than 180–365 days).

• Re-approve via change control before renewal.

• Log all partner admin actions and validate through audit trails. Ensure the Partner maps PIM to groups.

9. Automate Recertification and Offboarding

Schedule bi-annual access recertifications across all external tenants.
Remove or suspend unused domains and inactive guest accounts.
For example, an unused Teams federation or expired GDAP link should automatically trigger a removal workflow through ITSM or Power Automate.

10. Codify and Version Your Third-Party Playbooks

Document your third-party response procedures as version-controlled playbooks:

• Define containment ownership when incidents cross tenant boundaries. Have security contacts logged against each connected domain! Test them!

• Include Graph API automations to disable roles or tokens.

• Ensure SOC, Legal, and Partner teams share consistent information and escalation routes.

Version control of these playbooks ensures they evolve alongside your environment and partner relationships.

Bonus Tip.

Finally - Make the most of Microsoft Defender for Office 365 which offers lots of Teams-specific protection, such as “Near real-time URL protection in Teams messages” & “Time of click protection for URLs and files in Teams”

From Static Compliance to Dynamic Assurance

Third-party incidents are not edge cases, they are the new normal.

As the ecosystem expands with AI connectors, Copilot extensions, and API-driven integrations, every connection becomes both a productivity enabler and a potential threat vector.

Organisations that treat partner collaboration as part of their security surface, simulating incidents, enforcing lifecycle controls, and measuring readiness, will be those that sustain trust under scrutiny.

When identity is the perimeter, collaboration is the attack surface.

Make tabletop exercises and proactive access reviews as standard as penetration testing, because your next breach may start in someone else’s tenant.

I hope you have enjoyed this post, and I look forward to offering more tips in my next blog. For now, please consider giving me a quick Like & Share on your networking channels or chats with colleagues!

Stay safe, & Start the conversation around Auditing & Hardening against your trusted 3rd party connections!

#MicrosoftSecurity

#MicrosoftLearn

#CyberSecurity

#MicrosoftSecurityCopilot

#Microsoft

#MSPartnerUK

#msftadvocate

One last thing that really matters to us:
We are committing all of our royalties over the next 12 months from this book to Great Ormond Street Hospital Charity.

Every day, over 600 children from across the UK arrive at GOSH, and the work done there is nothing short of extraordinary. If this book can help improve security outcomes and also make a small difference there, that means everything to us.

Also, a big thank you to Rod Trent, Ru Campbell, Sami M'Barek and Sami Lamppu for reviewing the book and supporting along the way.

Microsoft Security, the way to go!

📘 You can get the book here: https://lnkd.in/eFYVcyy5

José Lázaro thank you for the initial invite to take part, and for pushing me outside my comfort zone to grow!

Sami M’Barek Sami Lamppu Ru Campbell Rod Trent thank you for giving your time & thoughts! Jose and I really appreciate the efforts.

Coming soon to Amazon. More blog posts on the way!

#MicrosoftSecurity

#MicrosoftLearn

#CyberSecurity

#MicrosoftSecurityCopilot

#Microsoft

#MSPartnerUK

#msftadvocate

It’s been a minute! Actually, exactly four months today since my last blog post. Life has certainly kept me on my toes: a young family, summer holidays, a busy security practice, four fantastic meet-ups, and to top it all off, I've been deep into writing a brand-new Sentinel Technical Publication with ! Keep your eyes peeled, it’s coming your way very soon.

I’m excited to be back! If you enjoy my blogs, insights, and tips, please do share and subscribe. We're closing in on 1,000 followers!

Subscribe now

Big things have been happening in the Sentinel space, actually, even bigger than that, in the entire Microsoft Security Data landscape. While this Security Datalake development carries "Sentinel" in its name, it's about far more than just Sentinel itself. This innovation/change is set to power a whole new generation of Microsoft security capabilities, reaching across the entire ecosystem.

I first “officially” encountered this shift in data architecture during Microsoft Ignite in November 2024. A Product Manager at the time shared an early vision of what would eventually become Sentinel Data Lake. The moment it was confirmed as a serious direction being explored, it immediately sparked a wave of ideas. For one, it signaled Microsoft's intent to reach parity with approaches already adopted by competitors like GCP. More importantly, it acknowledged what many of us had long seen as a fundamental gap in the platform.

Since then, I’ve been envisioning the endless possibilities this architecture unlocks, from new extensibility options to entirely new classes of features within the Microsoft Security ecosystem. Of course, it’s been both exciting and frustrating, exciting to explore the potential, frustrating to keep those thoughts under wraps due to MVP and Partner NDA constraints. But now, with the official launch, the conversation can finally begin.

Effective security fundamentally relies on knowing exactly what you’re protecting. This is going to become very apparent with the new Exposure Management modules in Defender, especially since Defender transforms every endpoint device into an intelligent sensor that continuously monitors and collects security signals across your entire ecosystem, and even beyond. This will only improve and gather more data over time.

This is a crucial concept to grasp. Exposure management is just as important as identity management, yet, up until now, it’s something Microsoft hasn’t handled particularly well. The data layer was I imagine a key blocker.

Jumping ahead slightly, since this topic clearly deserves its own detailed blog post or video, the new Security Data Lake provides the underlying foundation for collecting this type of high-volume, lower-fidelity log data at scale. This foundation will unlock powerful features down the line, such as Smart Device Isolation and trend-based investigations spanning 12 to 24 months.

Based on the volume of data, it will also allow and enable new types of Graph and vector-based data modelling.

One area I’m particularly keen to understand better is whether Microsoft will continue to recommend separating operational performance data from security data, which has long been considered a best practice to reduce noise and control costs in traditional SIEM architectures. Given the scale, flexibility, and managed nature of the new Sentinel Data Lake, it raises an important question: will there be updated guidance around collecting non-security telemetry, especially at enterprise scale? It would be interesting to see whether Microsoft introduces new ingestion strategies or reference architectures that allow performance and operational data to benefit from the same efficiencies. If anyone has come across details on this, I’d love to hear more.

Traditional Security Information and Event Management (SIEM) platforms often require difficult compromises: retain all logs and absorb high costs, or limit retention and risk losing crucial investigative data.

In response to this long-standing challenge, Microsoft announced the public preview of Sentinel Data Lake in July 2025—a new, scalable, cloud-native approach to security data storage and analysis within Microsoft Sentinel.

A Paradigm Shift in Data Architecture

Redefining Low-Level Design Decisions around retention

Sentinel Data Lake is purpose-built to centralise and optimise security data retention. By separating storage from compute, it enables:

• Affordable, long-term storage (up to 12 years)

• Scalable ingestion across Microsoft and third-party platforms

• Continuous access to historical data for analytics and investigations

The solution unifies telemetry from:

• Microsoft Defender XDR

• Microsoft 365

• Azure, Entra ID, Purview, and Intune

• Over 350 third-party integrations (e.g., AWS, GCP)

This consolidation eliminates data silos and empowers a more contextual, AI-ready foundation for threat detection and response.

Cost Optimisation and Efficiency Gains

Sentinel Data Lake addresses the rising cost of SIEM operations by introducing flexible data retention strategies:

• Hefty savings by offloading high-volume logs (e.g., firewall, DNS, proxy) to the Data Lake

• A reduction in overall SIEM spend through tier consolidation and removal of third-party storage solutions

• Additional savings by shifting lower-priority logs from the Analytics tier to the Data Lake

Storage Tiers Explained

Analytics Tier

• Designed for real-time detection, alerting, and rapid querying

• Suited for high-fidelity data such as Defender alerts and EDR logs

• Retention: 90 days std

Data Lake Tier

• Optimised for long-term retention at scale

• Ideal for logs supporting compliance, forensics, and retrospective threat hunting

• Ingested Analytics-tier data is automatically mirrored into the Data Lake without added cost

For teams currently relying on Azure Data Explorer (ADX) or exporting logs to Blob Storage for long-term retention or advanced analytics, Sentinel Data Lake represents a major shift. It potentially eliminates the need for custom export pipelines, external data transformations, and manual storage management by offering an integrated, cloud-native solution within Microsoft Sentinel.

Or dose it?

With automatic mirroring from the Analytics tier, cost-effective retention up to 12 years, and built-in querying via KQL and notebooks, security teams can now centralize log storage and analysis without sacrificing performance or context streamlining operations and reducing both complexity and cost.

Advanced Analytics and AI Integration

Sentinel Data Lake supports next-generation analysis capabilities:

• Kusto Query Language (KQL): Enables in-depth, cross-timeframe investigations directly within the Defender portal

• Jupyter Notebooks & Spark: Allows advanced pattern recognition, behavioural analytics, and AI model training using Python and Apache Spark

• AI-Optimised Foundation: Microsoft Security Copilot and other AI solutions benefit from the broader context provided by long-term data availability

Strategic Use Cases

Sentinel Data Lake enables a wide range of operational and strategic capabilities that empower security teams to conduct more effective investigations, meet compliance obligations, and adapt to emerging threats.

• Retrospective Threat Hunting: Correlate new threat intelligence with historical logs to identify previously undetected indicators of compromise.

• Cost-Efficient Investigations: Conduct deep forensic analysis without incurring high compute costs by querying archived logs directly in the Data Lake.

• Audit and Compliance: Meet regulatory and governance requirements by retaining data for up to 12 years in a secure and accessible format.

• Behavioural Analysis: Use long-term telemetry to model normal activity and detect behavioural anomalies across users, devices, or applications.

• Insider Risk Monitoring: Detect subtle insider threats that manifest over long periods, such as slow data exfiltration or privilege misuse.

• Threat Actor Attribution: Compare activity patterns across timeframes to identify repeat behaviours tied to specific adversaries or campaigns.

• Security Control Validation: Validate the effectiveness of controls over time by examining pre- and post-implementation behaviour or coverage.

Example Scenario: Delayed Detection with Retrospective Hunting

A zero-day vulnerability exploited by a nation-state actor is disclosed 10 months after its use in the wild. Using Sentinel Data Lake, the SOC team can run retrospective queries across historical logs to identify whether the vulnerability was exploited in their environment—even if it was not known at the time. Because the data is retained cost-effectively and accessible via KQL or Jupyter notebooks, the investigation can proceed without impacting operational SIEM performance or requiring third-party data recovery.

Adoption Prerequisites and Considerations

To use Sentinel Data Lake, ensure the following:

• Access via the Microsoft Defender portal - Have you enabled unified RBAC yet?

• Appropriate roles: Azure Subscription Owner, Microsoft Entra Global Administrator or Security Administrator, Log Analytics Contributor, Security Reader, and Security Operator

• Workspaces must align with the Entra tenant’s region

• Understand that new billing meters will apply

• Be aware that historical data migration is not automatic—mirroring begins only after activation

Benefits for Existing Sentinel Users

If you are already using Microsoft Sentinel:

• Data in the Analytics tier is automatically mirrored to the Data Lake tier at no additional charge

• Improved table management and tier configuration are available via the Defender portal

• Auxiliary logs can be consolidated within the Data Lake, reducing reliance on external tools

Platform Limitations

While highly capable, Sentinel Data Lake has defined constraints:

• It does not replace the real-time detection capabilities of the Analytics tier

• Historical data prior to activation is not migrated

• Certain logs (e.g., EDR) must remain in the Analytics tier for immediate visibility

• It is not designed for real-time dashboards or interactive visualisations

5-Step Guide to Assessing Data and Starting with Sentinel Data Lake

Before activating Sentinel Data Lake, it’s essential to assess your current data strategy against compliance, threat detection, and operational requirements. Follow this five-step guide to ensure a successful transition:

Step 1: Map Your Data Sources

Inventory all data sources currently ingested into your Microsoft Sentinel environment. Categorise them by purpose (e.g., security detection, compliance reporting, operational metrics) and determine their current retention period.

Step 2: Align with Detection and Compliance Needs

Review your analytics rules, threat detection use cases, and regulatory obligations. Identify which logs are:

• Required for real-time alerting (keep in the Analytics tier)

• Needed for long-term compliance or investigation (move to or retain in the Data Lake tier)

Step 3: Identify High-Volume, Low-Frequency Logs

Flag logs that contribute to high storage costs but are rarely queried in real-time (e.g., DNS, proxy, firewall). These are prime candidates for long-term retention in the Data Lake tier.

Step 4: Plan Activation and Communication

Understand that historical data will not be backfilled—only new data will be mirrored from the moment Data Lake is enabled. Prepare your team by updating documentation, alerting logic (where needed), and communication plans.

Step 5: Monitor, Review, and Optimise

After activation, regularly assess retention settings, billing impacts, and Data Lake usage. Adjust DCRs (Data Collection Rules) and table-level settings as needed to ensure cost efficiency and coverage.

Wow, that was a lot of information! A step-by-step getting started video will be published in the next few weeks, alongside upcoming content covering:

• Design considerations and deployment patterns

• Data tiering strategies based on table types

• Automation, transformations, and retention scripting

Are you planning to enable Sentinel Data Lake in your environment?

Are you planning to enable Sentinel Data Lake in your environment, or are you waiting for additional features or use cases to mature? What’s holding you back, or accelerating your move?

Let us know how you intend to get started, or why you’re not ready just yet.

Best

Marcus

#MicrosoftSecurity

#MicrosoftLearn

#CyberSecurity

#MicrosoftSecurityCopilot

#Microsoft

#MSPartnerUK

#msftadvocate

But here’s the thing no one talks about enough:
Your results are only as good as the prompts you give it. Bad Google = Bad Prompt.

Let’s Talk About Prompting

In the world of Generative AI security, the way you ask for information really matters. A vague question can leave you with half-baked answers. But a well-structured, thoughtful prompt? That’s where the magic happens.

And when you’re juggling tools like Microsoft Defender XDR, Sentinel, Intune, or Purview, being clear and intentional with your prompt is key to getting the insights you need.

Think of it like this: Security Copilot is your co-pilot — but you’re still the one steering the plane.

So, What Makes a Good Prompt?

You don’t need to be a prompt engineer or AI expert. But there are a few tricks to getting better results, such as:

• Being super clear on what you want: "Summarise this incident using Defender data from the last 24 hours" beats "Tell me about this alert."

• Framing it with context: What’s the goal? Are you trying to investigate, report, escalate, or prioritise?

• Tailoring your prompt to your role: A SOC analyst will ask very different questions than a CISO or a privacy officer.

• Iterating: Don’t be afraid to tweak and re-ask. Often, that’s where the gold is.

This kind of prompting can unlock smarter responses, better summaries, and even help align your strategy to Zero Trust principles. It’s genuinely game-changing.

🎉 New GPT Alert: Your Prompting Sidekick for Security Copilot

We know this can be a bit overwhelming, especially when you’re just getting started with Security Copilot. That’s why I’ve built something to help:

A brand-new Prompt Crafting GPT designed specifically for Microsoft security professionals.

This GPT helps you build better prompts based on:

✅ Your role (SOC Analyst, CISO, Compliance Lead, etc.)
✅ The tools you’re using (Defender, Sentinel, Intune, Purview, etc.)
✅ The outcome you want (investigate, summarise, respond, escalate)

Whether you're looking to get started with Security Copilot, run smarter incident summarisation with AI, or manage Security Copilot capacity in Azure, this GPT walks you through it.

👋 Want the Link? Just Drop Me a Message

I’m making early access available to security pros who want to level up their prompt game.

👉 Message me directly on LinkedIn and I’ll send you the link to try it out.

No sales pitch. No fuss. Just something genuinely useful to help you get more out of AI cybersecurity tools — especially if you’re already deep into your Security Copilot onboarding or managing SCU provisioning in Azure.

Final Thought

Prompting isn’t about using fancy language or long questions. It’s about clarity, context, and knowing what you need from the AI.

So if you’re tired of guesswork and want to start getting better answers, faster — this GPT is for you. It’s like having a prompt coach in your pocket.

👀 Keep an eye out for updates, and don’t forget to reach out on LinkedIn for early access!

#MicrosoftSecurity

#MicrosoftLearn

#CyberSecurity

#MicrosoftSecurityCopilot

#Microsoft

#MSPartnerUK

#msftadvocate

As we move further into 2025, artificial intelligence will play an increasingly central role in managing workflows, improving efficiency, and making better decisions across industries. One of the biggest developments will be the rise of AI agents, intelligent systems that can manage complex processes, adjust their actions based on real-time information, and continuously improve their performance.

Unlike traditional automation, which follows fixed rules and pre-defined steps, these AI-driven agents will be capable of adapting to new information, optimising processes, and making independent decisions based on the best possible outcome. This shift will have a significant impact on areas such as security operations, IT management, and business strategy.

How AI Agents Will Change the Way We Work

Instead of relying on manual intervention or static rules, AI agents will act as intelligent coordinators, capable of adjusting workflows in real-time. They will analyse data, predict likely outcomes, and fine-tune their responses to ensure the most effective decisions are made.

For example, in the field of cybersecurity, AI-driven security agents will not simply alert human analysts to potential threats. Instead, they will be able to:

• Automatically adjust security settings and policies based on the latest threat intelligence.

• Identify patterns and predict potential attacks before they occur.

• Manage incident response, allocating resources where they are needed most.

• Simulate or advise on simulation with different security strategies and choose the most effective approach.

This level of autonomous decision-making will allow organisations to respond to risks more quickly, reduce the workload on IT and security teams, and ensure that policies remain up to date without requiring constant manual adjustments.

AI-Driven Optimisation of Logic and Decision-Making

One of the most important aspects of AI-driven agents will be their ability to optimise logic flows. This means they will:

• Adapt processes dynamically based on real-time data, ensuring the most efficient outcome.

• Improve accuracy by continuously learning from past actions and refining their decision-making.

• Break down silos by coordinating information across different teams and systems.

• Support human decision-makers, providing recommendations that help organisations respond to challenges more effectively.

This capability will not only transform security operations but will also have a wide-ranging impact on business processes, customer service, and IT management. Instead of relying on static workflows that need to be manually updated, AI agents will ensure that systems are always optimised for the best possible result.

Specialist Agents vs. General AI Agents: Tailored Solutions and Broad Intelligence

AI agents will not be one-size-fits-all. Some will be specialists, designed to tackle specific tasks, while others will be generalists, capable of managing broader, more complex scenarios.

Specialist AI Agents: Experts in Their Field

Think of specialist AI agents like highly trained professionals. A locksmith can fix your door lock, a doctor can diagnose an illness, and a chef can prepare a gourmet meal. Each has deep knowledge in their area but does not step outside their expertise.

In the world of AI, specialist agents will focus on specific tasks with high accuracy and efficiency. For example:

• Threat Detection Agents will constantly scan networks, spotting unusual activity and blocking cyber threats before they cause harm.

• Compliance Agents will monitor policies and regulations, ensuring that companies follow security and legal guidelines.

• Incident Response Agents will investigate security breaches, gather evidence, and recommend the best course of action.

• Automation Agents will handle routine IT tasks, such as resetting passwords, patching software, and monitoring system health.

These agents will be fast, precise, and reliable in their areas, making security teams and IT departments more efficient.

Generalist AI Agents: The Versatile Problem Solvers

While specialist agents focus on a single task, generalist AI agents are more like trusted managers. They can handle multiple challenges, adapt to different situations, and make decisions across a broad range of topics.

Imagine a security operations centre (SOC). Instead of relying on humans to coordinate different security tools, analyse threats, and decide on the best response, a generalist AI security agent could take charge by:

• Bringing together data from different security tools like Defender XDR, Sentinel, and Entra.

• Understanding the bigger picture by analysing alerts, prioritising threats, and deciding which ones need urgent action.

• Coordinating multiple specialist AI agents, just like a team leader assigning tasks to experts.

The Future: AI Agents Working Together

As AI technology develops, we will see a mix of specialist and generalist AI agents working side by side.

A cybersecurity team, for example, might have:

• A Threat Detection Agent watching for dangers.

• A Compliance Agent checking policies.

• An Incident Response Agent investigating breaches.

• A Generalist AI Security Agent overseeing the whole operation, making high-level decisions, and ensuring all the specialist agents work together effectively.

This mix of specialist expertise and general oversight will create a more intelligent, responsive, and proactive AI ecosystem, capable of handling both routine tasks and unexpected challenges. The organisations that embrace this approach will have the strongest security, the most efficient operations, and the smartest decision-making systems.

The Future of AI Agents: A Shift Towards Intelligent Decision-Making

By the end of 2025, AI agents will no longer be simple automation tools that execute basic tasks. Instead, they will be capable of making complex, informed decisions based on a deep understanding of data, risks, and objectives. While human oversight will still be essential, AI will take on more responsibility for managing day-to-day operations, reducing manual effort, and allowing organisations to focus on higher-level strategy.

This shift marks the beginning of a new era in technology—one where AI is not just assisting humans but actively shaping the way businesses and security teams operate. The future will belong to those who embrace these intelligent systems and use them to enhance decision-making, improve efficiency, and stay ahead of evolving challenges.

Looking to get started? Start by learning the current capability of Microsoft Security Copilot!

#MicrosoftSecurity

#MicrosoftLearn

#CyberSecurity

#MicrosoftSecurityCopilot

#Microsoft

#MSPartnerUK

#msftadvocate

Since Microsoft Security Copilot is a cloud-based service running in Azure, it must adhere to the same governance, security, and compliance frameworks as other cloud-native workloads. Well almost. In enterprise environments following Azure Landing Zone best practices, Security Copilot should be deployed in a way that aligns with established subscription models, resource segregation policies, and governance controls.

Consistency with Azure Landing Zone Design

Organizations that have implemented an Azure Landing Zone typically follow a structured subscription and management group hierarchy, ensuring:

• Segregation of workloads based on function (e.g., security, networking, applications).

• Controlled access and governance policies across different business units.

• Enforcement of compliance and security baselines using Azure Policy and Microsoft Defender for Cloud.

Although some of this is not relevant, Security Copilot, as a critical security platform should align with this design and reside within a dedicated SEPARATE security subscription,

For context, see the examples below relating to Microsoft Sentinel.

When deploying Microsoft Security Copilot, one of the key architectural decisions is whether to provision it in its own dedicated Azure subscription or integrate it into an existing security-focused subscription. The answer depends on multiple factors, including security, operational efficiency and cost management requirements. However if in doubt, create a new Subscription!

Key Considerations for Separate Subscription Design

Let’s first understand the 3 components of RBAC relating to Security Copilot.

“Security Copilot RBAC roles are not Microsoft Entra roles. Security Copilot roles are defined and managed within Copilot and only grant access to Security Copilot features.”

This fact is important. It emphasizes the separation and standalone nature of the platform.

“Microsoft Entra RBAC grants access across the Microsoft portfolio of products including services that contain security data. These roles are managed through the Microsoft Entra admin center. For more information, see Assign Microsoft Entra roles to users.”

This item is key, as the “On Behalf Of” design means, you (The user or app orchestrating the prompt) must have access to run prompts against data and platforms connected to the tool.

“Azure RBAC controls access to Azure resources like Security Capacity Units (SCU) in a resource group, or Microsoft Sentinel-enabled workspaces. For more information, see Assign Azure roles.”

Potentially the most important item is “Azure RBAC” access to provision or de-provision the Security Copilot Capacity.

Security Copilot Stand-Alone Platform

Microsoft Security Copilot should be viewed as a standalone security platform, not just an extension of existing Microsoft Security tooling. While its native integration with Microsoft Defender XDR, Sentinel, and other security solutions is a key strength, its true power lies in its flexibility and extensibility.

By treating Security Copilot as an independent platform rather than just another Microsoft security feature, organisations can strategically architect their security operations in a way that aligns with Zero Trust principles. This means:

• You could use Security Copilot with third-party integrations only – it does not require the full Microsoft security stack.

• It should be secured and managed like any other cloud-hosted security solution, rather than assuming inherent security from the Microsoft ecosystem.

• It supports a modular security strategy, allowing organisations to use AI-driven insights across a multi-vendor security environment.

Why This Perspective Matters

Taking this approach ensures that Security Copilot is deployed, managed, and secured with the same rigour as any other cloud-based security solution. This reinforces the Zero Trust model, where:

• Every component is validated, authenticated, and monitored regardless of its origin.

• Access is restricted based on least privilege rather than assumed trust.

• Security Copilot is seen as a critical asset that requires dedicated security governance.

This approach forces security teams to ask:

• Would we trust Security Copilot if it was developed by a third-party vendor?

• Are we applying the same security governance and controls as we do for any other SaaS security tool?

By stepping back and recognising Security Copilot as an independent AI-powered security platform, organisations can fully harness its capabilities while ensuring it is deployed and managed with the level of security it demands.

So back to our architectural decision

Security & Access Control

One of the biggest advantages of placing Security Copilot in a dedicated subscription is enhanced Role-Based Access Control (RBAC) and segmentation of duties:

• Security teams can enforce a least-privilege model, ensuring only specific users can access and manage Security Copilot Capacity Units (SCU).

If the tool is deeply embedded in your real-time cybersecurity operations, especially in scenarios where it supports non-human operators (e.g., automated security workflows, SOAR integrations) or is a key assistant to Level 1 (L1) analysts during night shifts, losing access, whether by accident or intent, could have devastating consequences.

Cost Management & Billing Transparency

A dedicated subscription for Security Copilot Capacity Units can significantly enhance cost tracking and visibility, making it easier to:

• Attribute costs specifically to security functions rather than blending them with general IT or cloud consumption costs.

• Optimize and forecast Security Copilot’s usage costs, particularly in organizations with strict budgeting and chargeback models.

• Prevent unexpected cost spikes from being buried in broader cloud spending, making it easier to justify Security Copilot’s ROI to leadership.

Operational Efficiency & Governance

Managing Security Copilot Capacity Units separately allows organizations to:

• Implement clear governance policies and ensure security tool management is handled by the appropriate teams.

• Minimize cross-team conflicts, where non-security teams might have unintended impacts on Security Copilot’s deployment, configuration, or data access.

• Maintain flexibility for future security architecture changes without disrupting business-critical applications or IT services.

Security Copilot architectural decision tree

Step 1: Subscription Considerations

Do you have an existing subscription that can be used for Microsoft Security Copilot?

• Yes → Are RBAC permissions correctly configured?

  • Yes → Will you use a Specific New RG?

  • Yes → Proceed to Step 3.

  • NO → Create a New Subscription & RG. Assess and secure RBAC permissions.

Step 3: Do you have regulatory requirements to keep data in different Azure geographies?

• Yes: Ensure your TENANT geo region is correct. Why? Understand the difference between customer and System Generated.

• Understand the difference between Platform location & Prompt Evaluation!

• No preference on the above: Proceed to provisioning.

Best Practices: When to Use a Dedicated Subscription for Security Copilot Capacity Units

A separate subscription is recommended if:
✔ Your organization has strict regulatory requirements for security tools and must ensure auditability and isolation.
✔ You need enhanced cost visibility and tracking for security operations.
✔ Your security team operates independently from IT and cloud engineering teams, reducing interdepartmental conflicts.
✔ You are deploying Security Copilot in a highly sensitive or regulated environment.
✔ You want strong RBAC controls to limit access and ensure least privilege access is enforced.

❌ When It’s Acceptable to Use an Existing Subscription

It may be sufficient to use an existing security-focused subscription (e.g., Microsoft Sentinel, Defender XDR) if:
✔ You already have a dedicated security subscription for all Microsoft security tools and wish to maintain a centralized approach.
✔ Your IT and security teams are aligned, and there is no risk of cross-team conflicts.
✔ Your organization prioritizes simplicity over strict subscription segmentation, and cost tracking isn’t a major concern.
✔ You have strong governance policies in place to prevent accidental misconfigurations by non-security teams.

Final Thought: Security Copilot Capacity Unit deployment as Part of a Well-Architected Security Landing Zone

Since Security Copilot operates in Azure, it should be governed closely to the same security, compliance, and operational best practices as any other cloud security tool.

Deploying Capacity Units within a dedicated security subscription, aligned with your Azure Landing Zone architecture, ensures that it remains secure, and operationally efficient while minimizing risk exposure.

#MicrosoftSecurity

#MicrosoftLearn

#CyberSecurity

#MicrosoftSecurityCopilot

#Microsoft

#MSPartnerUK

#msftadvocate

At the time, I was navigating new challenges, setting ambitious goals, and laying the groundwork for what I hoped would be a year of growth and contribution.

It’s also a great reminder of the importance of documenting those moments of inspiration or clarity. You never know when revisiting them might reignite a spark or give you a new perspective.

It’s funny, back then, I probably saw it as just another quick recording to be used in a bigger project. Now, it feels like a checkpoint, a moment frozen in time that shows how much progress is possible when you stay focused and committed.

Where has the year gone already?

So, here we are, already nearing the end of January 2025! Where has the month gone? It feels like a whirlwind, but for me, it’s been full of the usual challenges and rewards, working with large enterprise clients to deliver actionable insights that enhance their security posture. Ultimately, it’s all about making a tangible difference in their cyber safety, which, let’s be honest, is more critical than ever in today’s evolving threat landscape.

On a personal note, receiving my MVP recognition from Microsoft recently has been an incredible milestone. It’s made me pause and reflect—not just on my contributions to the community but also on how I approach my work and the industry as a whole. The MVP honour isn’t just a badge, it’s a reminder that what we do matters, and it’s driven me to think deeply about the best ways to make meaningful contributions moving forward.

If there’s one thing I’ve learned, it’s the importance of focus.

Microsoft Security is vast, truly vast. It can feel overwhelming to navigate the endless options, tools, and solutions, all while striving to excel. But through the guidance of some incredible mentors, I’ve come to understand that the key is honing in on specific vectors. Whether it’s studying a particular technology, sharing knowledge, or developing new skills, choosing the areas that align with my strengths, interests, and professional goals has been transformative.

After all, there are only so many hours in a day, and balancing work, family, and community commitments is a challenge we all share.

For me, this focus has crystallized around deepening my expertise in SIEM, Microsoft Defender, and Security Copilot. These areas are not only where my passion lies but also where I believe I can make the most impact. I’ve been channelling this energy into sharing insights through blog posts and speaking engagements, both of which are incredibly rewarding. There’s something special about helping others understand the nuances of these tools and seeing them apply that knowledge to secure their environments.

My Advice

If there’s one piece of advice I’d give to anyone looking to advocate for their passion or expertise, it’s this: be intentional and selective about where you invest your time and knowledge. It’s so easy to get caught up in the endless demands on our attention, but focusing on the areas where you can truly make an impact—that’s where the magic happens.

And if you’re sharing your journey through a medium like a video, blog post, or even a private journal, I’d encourage you to take a moment every now and then to reflect on it. Ask yourself: What’s driving my passion right now? What interests are sparking joy or curiosity? What’s fueling my growth and progression? Do I need a break?

And let’s be honest, a break is absolutely needed! So look after yourself!

Having something recorded—whether it’s public or private—can be a powerful way to track your evolution. It gives you the chance to revisit those pivotal moments, to see how your perspective has changed, and to reignite the fire behind your goals. It’s not just about documenting your journey for others; it’s about creating a resource for yourself, a reminder of where you’ve been and where you want to go.

So, advocate with intention, invest in what matters, and give yourself the space to reflect. You’d be surprised how much clarity and inspiration you can gain from revisiting those snapshots of your growth.

My personal reflection

Finding that video was such a great moment—it was a reminder to step back and reflect. Sometimes, in the rush of day-to-day life, it’s easy to lose sight of how far we’ve come or how our goals have evolved. That one video felt like a nudge to pause, reassess, and celebrate the journey so far.

Inspired by this, I’ve decided to make it a yearly tradition. In the next couple of months, I’m going to record a new video for 2025 and start building a collection of these reflections. It’s something I’m excited about—not just for tracking my own growth but also as a way to stay grounded in what truly matters.

On a personal level, this experience has sparked a new idea: I want to explore opportunities to connect with the education space and contribute to meaningful engagements that empower others. Whether it’s helping a student find their path or supporting someone just starting their career in IT, there’s so much potential to make an impact.

For me, this feels like the next step—not just sharing knowledge but using it to uplift and inspire others at the start of their own journeys. Who knows? Maybe one of these videos or initiatives will be the spark someone needs to find their passion or take that next big step.

A technical blog up next, for now, have a great week!

#MicrosoftSecurity

#MicrosoftLearn

#CyberSecurity

#MicrosoftSecurityCopilot

#Microsoft

#MSPartnerUK

#msftadvocate

The secret to mastering KQL lies in focusing on the foundational 20% of concepts that enable you to solve 80% of practical problems. These core principles, when applied effectively, can help you analyse failed logins, identify suspicious activities, and correlate alerts with sign-ins—all essential tasks for both the SC-200 and using MS security tooling in the future!

This guide is my response to that question. It’s designed to help those preparing for the SC-200 focus on the inital most impactful parts of KQL, providing the skills and confidence to not only pass the exam but also apply KQL effectively in real-world scenarios.

The simplest way I explain KQL is by comparing it to working with multiple Excel spreadsheets. Imagine you have thousands of rows of data spread across different sheets. KQL acts like a powerful filter and processing tool that helps you sift through that data, table by table, row by row and column by column, in a logical, step-by-step way.

Think of each pipe (|) in a KQL query as a command that refines or transforms the data before passing it along to the next step. It's like saying, “Filter this data,” then “Pick these columns,” and finally “Sort the results”—all in one fluid motion. Each step produces a result, which is then fed into the next operation, much like how you’d manipulate data in PowerShell commands or use Excel formulas to break down and analyze your data iteratively.

Here’s an example to illustrate this process:

Most Basic Example:

Imagine you’re investigating failed login attempts. Here’s how KQL processes the data:

1. Step 1: Start with your dataset. You begin with a table, like the SecurityEvent table, which contains raw data about logon events.

SecurityEvent

1. This is your starting point—like opening a spreadsheet with thousands of rows of raw logon data.

2. Step 2: Filter the data. Use the where clause to narrow it down to failed logon attempts, equivalent to applying a filter in Excel.

SecurityEvent | where EventID == 4625

1. Now, instead of sifting through irrelevant rows, you’re only looking at rows related to failed logons.

2. Step 3: Select specific columns. Use the project operator to focus on just the columns you need, like TimeGenerated, AccountName, and Computer.

SecurityEvent 

| where EventID == 4625 
| project TimeGenerated, AccountName, Computer

1. This is like hiding all the other columns in Excel to make the data easier to analyze.

2. Step 4: Sort the data. Finally, you can use the order by operator to sort the results, such as ordering the failed logons by the time they occurred.

SecurityEvent 
| where EventID == 4625 
| project TimeGenerated, AccountName, Computer 
| order by TimeGenerated desc

1. At this point, you have a neat, organized view of the data that’s ready for further analysis.

Why this analogy works:

• Pipes (|): Each pipe acts like a new formula or filter in Excel that processes and refines the data step by step.

• Logical flow: KQL queries are sequential and build on each other, just like a well-organized series of Excel actions.

• Dynamic results: You can iteratively refine your query by adding more steps, similar to tweaking Excel formulas to get the exact output you need.

• Automation: Unlike Excel, which often requires manual adjustments, KQL allows you to automate these operations on massive datasets with ease.

This step-by-step, modular approach makes KQL intuitive once you grasp the basics, allowing you to quickly derive actionable insights from complex datasets.

Now lets look at a 10 step guide to some other key functions to know!

1. Understanding KQL Syntax Basics

The Foundation:

• Query Structure: KQL queries are a series of statements connected by pipes (|). Each statement processes data and passes it to the next step.

• Case Sensitivity:

  • Keywords and operators are case-insensitive (e.g., where, WHERE).

  • Field names and string values are case-sensitive.

• Best Practice: Write clean, readable queries by formatting them with line breaks after each pipe (|).

Example Query:

SecurityEvent
| where EventID == 4625
| project TimeGenerated, AccountName, Computer
| order by TimeGenerated desc

This query retrieves failed logon events, selects key columns, and orders the results by time.

2. Core Operators and Their Use Cases

Filtering Data with where

• Purpose: Extract rows that meet specific conditions.

• Syntax:

TableName 
| where Condition

• Examples:

  • | where EventID == 4625: Filter for failed logon events.

  • | where AccountName startswith "admin": Retrieve accounts starting with "admin".

Selecting Columns with project

• Purpose: Limit the output to specific columns for clarity and performance.

• Example:

SecurityEvent 
| project TimeGenerated, AccountName

Adding New Columns with extend

• Purpose: Create calculated columns for better analysis.

• Example:

| extend AccountNameLength = strlen(AccountName)

Aggregating Data with summarize

• Purpose: Group and calculate summary statistics.

• Example:

| summarize TotalEvents = count() by EventID

Sorting Data with order by

• Purpose: Arrange data in ascending or descending order.

• Example:

| order by TimeGenerated desc

3. Advanced Filters and Expressions

Logical Operators

• Combine multiple conditions using and, or, and not.

• Example:

| where EventID == 4625 and AccountName contains "admin"

String Operations

• Use functions like startswith, contains, has, and endswith to filter textual data.

• Examples:

  • | where Computer has "server"

  • | where AccountName endswith "123"

4. Transforming Data

Parsing Fields

• Purpose: Extract or manipulate structured fields within logs.

• Examples:

  • Using parse: | parse Message with "User=" Username ";"

  • Using extract: | extend ExtractedField = extract("User=(\w+)", 1, RawData)

Time Functions

• Group events into time intervals with bin.

• Example:

| summarize count() by bin(TimeGenerated, 1h)

5. Aggregations

Common Functions

• count(): Total number of rows.

• sum(): Total of a numerical column.

• avg(): Average of a numerical column.

• min() / max(): Minimum or maximum value.

Grouping Data

• Use summarize with by to group and calculate statistics.

• Example:

| summarize TotalLogons = count() by AccountName

6. Joining and Enriching Data

Joins

• Combine datasets using join.

• Syntax:

Table1 | join kind=inner (Table2) on KeyField

• Example: Enrich failed logons with account details:

SecurityEvent
| where EventID == 4625
| join kind=inner (UserDetails) on AccountName

Lookup

• Simplify enrichment for small datasets.

• Example:

| lookup kind=leftouter UserDetails on AccountName

7. Visualization

Adding Visualizations

• Use render to display data as charts.

• Examples:

  • Time chart:

| summarize count() by bin(TimeGenerated, 1h)
| render timechart

• • Bar chart:

| summarize count() by AccountName
| render barchart

8. Practical SC-200 Scenarios

Detecting Failed Logons

SecurityEvent
| where EventID == 4625
| summarize FailedAttempts = count() by AccountName, bin(TimeGenerated, 1h)
| order by FailedAttempts desc

Monitoring Suspicious Activity

AzureDiagnostics
| where OperationName contains "Delete"
| summarize DeleteCount = count() by CallerIpAddress, bin(TimeGenerated, 1d)

Correlating Alerts with Sign-Ins

SecurityAlert
| join kind=inner (SignInLogs) on AccountName
| where AlertSeverity == "High"
| project TimeGenerated, AccountName, AlertName, IPAddress

9. Performance Optimization

Best Practices:

• Filter Early: Use where as early as possible to reduce the dataset size.

• Project Columns: Limit output fields with project.

• Indexed Fields: Use indexed fields (like TimeGenerated) for filtering.

• Avoid Complex Joins: Simplify joins by pre-filtering datasets.

10. Learning by Practice

MUST WATCH

Learn KQL with Kusto Detective Agency

Recommended Tools:

• Kusto Detective Agency

By mastering these core principles, you’ll be well-equipped to pass the SC-200 exam and apply KQL effectively in real-world scenarios. Let me know if you need further clarification or additional practice exercises!

• Pluralsight: KQL from scratch

• Kusto Detective Agency

• Tutorial: Learn common operators

• Tutorial: Use aggregation functions

• Tutorial: Join data from multiple tables

• Cloud Academy: Introduction to Kusto Query Language

Some more advanced resources -

• Learn KQL with the Must Learn KQL series and book

• KQLQuery.com - Blog posts about KQL and different use cases

• KQLSearch.com - Search Engine for KQL Queries

• Log Analytics Demo Lab: aka.ms/LADemo

Hands-On Learning with Microsoft Interactive Labs SC-200

👉 Apply Microsoft Defender for Office 365 preset security policies
🧪 https://lnkd.in/d6BqZJtv

👉 Deploy Microsoft Defender for Endpoint
🧪 https://lnkd.in/dd_Vj9VT

👉 Mitigate Attacks with Microsoft Defender for Endpoint
🧪 https://lnkd.in/d273kEnd

👉 Enable Microsoft Defender for Cloud
🧪 https://lnkd.in/d_nGMapG

👉 Mitigate threats using Microsoft Defender for Cloud
🧪 https://lnkd.in/drJmedgr

👉 Create queries for Microsoft Sentinel using Kusto Query Language (KQL)
🧪 https://lnkd.in/dQnQ_iEZ

👉 Configure your Microsoft Sentinel environment
🧪 https://lnkd.in/dr4akkUX

👉 Connect data to Microsoft Sentinel using data connectors
🧪 https://lnkd.in/dtRmAwFa

👉 Connect Windows devices to Microsoft Sentinel using data connectors
🧪 https://lnkd.in/dpxmvabA

👉 Connect Linux hosts to Microsoft Sentinel using data connectors
🧪 https://lnkd.in/dua8fHNm

👉 Create workbooks
🧪 https://lnkd.in/dnawKhcP

👉 Use Repositories in Microsoft Sentinel
🧪 https://lnkd.in/daQkDy9N



Check out the full set of SC-200 labs on the blog: https://lnkd.in/dqjrWG-k

#MicrosoftSecurity

#MicrosoftLearn

#CyberSecurity

#MicrosoftSecurityCopilot

#Microsoft

#MSPartnerUK

#msftadvocate

On the 1st of January, I was officially accepted into the Microsoft Most Valuable Professional (MVP) programme for SIEM+XDR and Security Copilot—a tremendous honour that still feels a bit unbelievable as I write this. To be recognised as only the 11th person in the world in the Security Copilot category at the time of writing, just 12 months after gaining early access, is incredible.

This recognition isn’t just about expertise but mainly about contributions to the wider security community—something I have become deeply passionate about. It reinforces my commitment to advancing security practices and sharing knowledge to empower others in this field.

Over the years, I’ve had the privilege of working alongside some of the brightest minds in cybersecurity, contributing in my small ways to pioneering advancements in Microsoft’s security ecosystem. My goal has always been to demystify security, make it actionable, and lead organisations to build resilience in an increasingly complex threat landscape. GSD—Get Security DONE!. Empower and lead others to do so!

Reflections on the Past Year

2024 was a year of significant growth and collaboration. From hosting hands-on Security Roundtables with industry experts and MVPs to launching the new blog, Copilot for Security Unleashed, many public speaking sessions and mentoring rising talents, each experience has been another step towards this milestone.

The highlight has been exploring the potential of Security Copilot and how AI-driven tools can augment human expertise. This area holds immense promise for the future of cybersecurity, and I’m excited to continue driving innovation & thought in this space.

A Community Effort

The MVP award isn’t just about individual contributions—it’s also a reflection of the strength of the community. I’m grateful to be part of a vibrant, supportive network of professionals who inspire, challenge, and collaborate to make cybersecurity more effective and inclusive. #MVPBuzz (I can officially say that now!)

Recently sitting in Luton Airport, travelling to the Scottish summit (UK MS Community Event) I by chance met another random attendee (Never met them) (Working on his session in the coffee shop), I hesitantly asked the question, “Are you off to Scottish Summit?” we chatted about the event and the conversation naturally turned into like-minded common ground Microsoft Product based. Ended up travelling the rest of the way together & catching breakfast.

At the same event, I was waiting for a friend in the hotel bar and got chatting by chance with another MVP, by noticing the CCP Defender Stickers on his laptop. (Shout to the CCP team and MS Product Managers / Teams, you rock! ) Turns out we had mutual connections and had a great chat about all the latest Preview features for over an hour!

Sat on a plane at 30,000 feet, on route to present the MISA booth at Ignite, (Shout to Maria Thompson & the amazing MISA team) and politely said hey to the person sitting next to me. Jokingly asks, “Are you off to Ignite to?” Absolutely he was, a fellow MVP from Finland, 30 minutes later, 7 of us now crammed in the extra legroom space, his colleagues joined us chatting about MS security things with a beverage to weather the 8-hour flight! (Lesson learned, don’t drink with the Fins!)

The point I am trying to make is that the Microsoft community is welcoming, and strong, and if you haven’t been to any events yet, give it a go, be seen, be heard, network & learn! There are some amazingly friendly people, who share the same values and will be willing to talk tech longer than your partner puts up with at home. Haha.

If you're reading this blog post - Some recommendations of events below, lets connect and meet up at one!

Secondly - Sticker up those laptops. They are the BEST conversation starter/icebreaker in my opinion! Get collecting! (And send me any you make!)

To the MS team, community members, event attendees, customers, peers, and mentors who have shared their insights and trusted me with their challenges—thank you. This recognition is a reflection of our collective efforts.

My Sincere Thanks

I can’t possibly tag everyone who has supported me on this journey over the last few years, but here are a few special mentions:

• Jon Jarvis for nominating me to the MVP programme along with Luke Evans, for affording me the opportunity to step in to present workshops alongside them, and for great support and advice along the way!

• for your incredible mentorship and inspiration. Your guidance has been instrumental in helping me get involved and discover the value of the community. I’m truly grateful for your encouragement and the example you’ve set.

• James Key and the entire Security Copilot Product team for your collaboration and insights. Allowing me to actively understand, contribute and support the Security Copilot product journey!

• - For recommending this blog to his community of readers from the early days! Truly kept me motivated to share as much as possible and try to keep up with all the latest things!

• Scottish Summit & South Coast Summit - These amazing platforms in the UK are run by and for the Community! Check out the 25/26 dates now!

• Experts Live UK - Again a community group that’s just starting out. Kind enough to have me at their second evening event! Take a look at their next dates!

• Performanta Team - My current employer, leadership team & peers have been supportive in keeping me at the forefront of the Microsoft Technical Relationship. Very much appreciated being encouraged and empowered to use the latest tech and the most modern way to work, even if it is not always the easiest!

Looking Ahead

As we step into 2025, I’m energised by the opportunities ahead. My plans include:

• Expanding Community Initiatives: I aim to launch a new blog sub-series to provide practical, real-world insights into Microsoft security technologies. And try to get some video content up on YouTube!

• Deepening Expertise in Security Copilot: I’ll continue exploring new use cases and best practices for integrating AI into security operations. (It’s unfortunately super hard to release most of the detail in this type of content, due to NDAs)

• Mentoring and Inspiring: I’m committed to guiding emerging professionals in the field, helping them unlock their potential and drive innovation. If you're looking for someone to bounce off, or start your community journey reach out!

I’m looking forward to more collaborations, learning opportunities, and perhaps even more roundtable discussions with the incredible people in this field.

Final Thoughts

Being recognised as a Microsoft MVP is not just an honour—it’s a responsibility to give back, to lead, and to continue striving for excellence. On this New Year’s Day, I am filled with gratitude and excitement for what’s to come.

Here’s to a 2025 filled with mode Copilots, growth, learning, and a more secure future. Thank you Microsoft. Thanks to the community, and thank you for reading, subscribing & being part of this journey. Wishing you a Happy New Year and a healthy 2025!

#MVP

#MicrosoftSecurity

#MicrosoftLearn

#CyberSecurity

#MicrosoftSecurityCopilot

#Microsoft

#MSPartnerUK

#msftadvocate

Transitioning from a deep technical role to a Principal Microsoft Security Consultant taught me something powerful: our impact multiplies when we share what we learn. Whether hosting the Microsoft Intelligent Security Association demo station at Ignite or diving into Security Copilot's potential, 2024 was about turning expertise into community opportunity.

Key milestones that redefined my journey:

• Became Principal Microsoft Security Consultant at Performanta, focusing on holistic security integration

https://www.linkedin.com/feed/update/urn:li:activity:7186470084494733312/

• Earned Microsoft Certified Trainer (MCT) certification, transforming technical knowledge into community learning

https://www.linkedin.com/feed/update/urn:li:activity:7272251625048576001/

• Hosted MISA demo station at Microsoft Ignite, connecting with security professionals and exploring next-gen solutions

https://www.linkedin.com/feed/update/urn:li:activity:7265489284579639297/

Bonus achievements that kept the momentum high:

• Microsoft Community Contributor for 2024

• Microsoft Sentinel - Applied Skills certification

• Presented cutting-edge security insights at Scottish Summit

Looking ahead to 2025: My mission remains crystal clear. Expand Security Copilot expertise, develop innovative training programs, and continue pushing the boundaries of Microsoft Sentinel and XDR implementation.

To every security professional feeling overwhelmed by technological complexity: Your curiosity is your greatest asset. Keep learning, keep sharing, keep transforming.

Want more insights? Subscribe to my blog for continuous security technology exploration!

#MicrosoftSecurity #CyberSecurity #SecurityCopilot #LinkedInRewind #Coauthor #2024wrapped

--

Get your 2024 LinkedIn Rewind! Go to coauthor.studio

#MicrosoftSecurity

#MicrosoftLearn

#CyberSecurity

#MicrosoftSecurityCopilot

#Microsoft

#MSPartnerUK

#msftadvocate

Disclaimer

This feature is a new and evolving capability. While it offers significant potential surface benefits, it is essential to seek expert advice to ensure proper implementation and alignment with your organization's unique requirements.

Additionally, it’s important to remember that all aspects of your Sentinel Instances should be regularly reviewed, maintained, and updated as part of standard best practices.

Why SOC Optimisation Matters

COST! SOC teams often face challenges balancing comprehensive threat detection with operational efficiency. The increasing volume of data ingested from various sources can lead to skyrocketing costs and wasted resources if not carefully managed. Microsoft Sentinel starts to address these pain points by providing first step specific recommendations that streamline data usage, identify coverage gaps, and leverage insights from similar organisations.

1. Data Value Optimisation Recommendations

Data value optimisation focuses on the cost-security balance by highlighting underutilised or unnecessary data ingestion. Sentinel identifies billable tables from the past 30 days and categorises their value to your security operations.

Key Observations and Actions:

• Unused Tables:

  • Observation: A table hasn’t been used in analytics, detections, or hunting in the last 30 days.

  • Action: Consider turning on relevant analytics rule templates, archiving the table, or stopping ingestion entirely.

*If your data is being used by an external service or MSP / MSSP its key to ensure its not being used in another way.

• Partially Used Tables:

  • Observation: A table is only used by Azure Monitor or similar tools.

  • Action: Move the table to a non-security Log Analytics workspace or enable relevant analytics templates.

Rule of thumb. The log is not security related ? = Don’t ingest it.

Pro Tip: Always ensure compliance requirements are met before modifying ingestion plans. Some tables may hold regulatory significance even if they lack immediate security value.

2. Threat-Based Optimisation Recommendations

Threat-based optimisation uses a proactive approach to close gaps in threat detection by aligning your SOC’s capabilities with industry-standard threats and attack scenarios.

Key Observations and Actions:

• Missing Detections for Existing Data Sources:

  • Action: Turn on analytics rule templates for identified threats. Tailor the rules to your environment for maximum effectiveness.

• Missing Data Sources for Existing Detections:

  • Action: Connect relevant data sources that enhance coverage against known threats.

• No Data Sources or Detections:

  • Action: Deploy new detections and connect data sources, or install comprehensive solutions to address gaps.

Pro Tip: Regularly review and update detection rules to ensure they reflect evolving threat landscapes and organisational needs.

3. Similar Organisations Recommendations *

Microsoft Sentinel leverages advanced machine learning to compare your organisation’s SOC setup with others of similar size, industry, or operational trends. This unique feature provides recommendations tailored to your environment, ensuring relevance and actionable insights.

Key Observations and Actions:

• Missing Log Sources:

  • Action: Ingest suggested data sources based on trends observed in similar organisations. Or risk accept the fact you chose not to for X reason.

Considerations:

• Recommendations are only available if sufficient similarities are identified.

• Early-stage SOCs benefit most, as mature SOCs tend to have fewer significant gaps.

Pro Tip: Use these recommendations to fast-track SOC maturity and benchmark against industry peers without exposing sensitive data.

Cant find this one ?

** Not all workspaces get similar organizations recommendations. A workspace receives these recommendations only if our machine learning model identifies significant similarities with other organizations and discovers tables that they have but you don't. SOCs in their early or onboarding stages are generally more likely to receive these recommendations than SOCs with a higher level of maturity.

Key Takeaways

SOC optimisation with Microsoft Sentinel empowers organisations to:

• Start to reduce costs by identifying underutilised data and aligning ingestion with security value.

• Close coverage gaps by implementing relevant threat-based analytics and data sources.

• Learn from industry peers using machine learning-powered insights.

By implementing these recommendations, organisations can elevate their SOC efficiency, improve threat response times, and ensure their investments in security are cost-effective.

Next Steps
Take advantage of Microsoft Sentinel’s optimisation capabilities:

1. Evaluate your current setup: Review your data ingestion and analytics rules.

2. Implement recommendations: Use Sentinel’s insights to make informed decisions on resource allocation and security improvements.

3. Continuously optimise: Regularly revisit your SOC configuration to adapt to evolving threats and organisational growth.

For more detailed guidance, visit the Microsoft Sentinel documentation.

With a strategic approach to SOC optimisation, your organisation can stay secure, agile, and resilient in the face of growing cyber threats.

#MicrosoftSecurity

#MicrosoftLearn

#CyberSecurity

#MicrosoftSecurityCopilot

#Microsoft

#MSPartnerUK

#msftadvocate