Microsoft Ignite 2026: Five Key Sessions on AI Agent Governance, Zero Trust and Runtime Security

Ignite is scheduled for November 17–20, 2026, in San Francisco, with online participation also available. One important planning detail: Microsoft’s Security Blog places the opening keynote at Chase Center on November 17, from 10 a.m. to noon Pacific Time—a venue distinction worth noting alongside Redmondmag’s description of the wider event at Moscone Center.

These five sessions suggest a practical question to carry through the conference: when an agent can act, what evidence makes that action trustworthy?

1. Opening keynote: strategy before implementation​

Microsoft’s official catalog names Satya Nadella and Judson Althoff as the opening keynote speakers. It lists the session, KEY01, for both in-person and online attendance and says it will be recorded.

Treat this as the strategic overview. Redmondmag identifies Copilot, Azure, Microsoft Foundry and agents as areas to watch, but those are expectations—not a confirmed announcement list.

For IT decision-makers, the useful exercise is to separate three things while watching:

• What Microsoft demonstrates.
• What Microsoft says customers can deploy.
• What remains a roadmap commitment.

A compelling demonstration can justify further investigation. It should not, by itself, become a production rollout plan.

2. Govern AI everywhere: look for enforceable controls​

“Govern AI everywhere: From open frameworks to enterprise control” focuses attention on evaluating and governing AI systems. Microsoft’s session page describes speaker Mehrnoosh Sameki’s work on agentic evaluations, AI safety, red-teaming agents, Microsoft Foundry Govern, and agent-control specifications and runtimes. It also emphasizes open-source development integrated with Foundry and Microsoft’s broader ecosystem.

That open-frameworks framing matters. The session page identifies Sameki as a leader in Microsoft CoreAI’s Responsible AI organization and names projects she co-founded, including ASSERT and Agent Control Specification. Those credentials establish relevant background; they do not establish that every project will appear in the presentation.

The questions to bring are operational:

• Where is a governance decision enforced?
• How is a failed evaluation handled?
• Can a control be tested before an agent gains production access?
• What evidence can an administrator retain for review?

The practical takeaway: look for the connection between written requirements, measurable evaluations and actual runtime restrictions. A policy that never reaches execution is still just paperwork.

3. One policy for humans and agents: examine the boundaries​

“A Single Policy for Humans and AI Agents? Here’s How to Make It Work” addresses policy complexity through a unified engine combining identity, network, device and risk signals. Microsoft lists BRK331 as an advanced, level-300 breakout, available online and in person, with a recording planned.

The promising idea is more coherent access decisions. The unresolved question is how that coherence handles different actors.

An employee approving a task and an agent carrying it out are not necessarily the same authorization problem. As an architectural review exercise, ask the presenters to distinguish:

• The person initiating the work.
• The identity used during execution.
• The permissions attached to that identity.
• The conditions that block or revoke access.

Those are questions for evaluating the proposed approach, not confirmed implementation details. The catalog does not establish that one engine already covers every human-and-agent scenario.

4. Defender runtime security: watch what happens after access​

“A Zero Trust approach to securing AI runtime with Microsoft Defender” covers prompt injection, tool misuse and identity abuse, with guidance Microsoft says is mapped to OWASP and MITRE. BRK340 is listed as an intermediate, level-200 breakout, offered online and in person and scheduled for recording.

This complements the access-policy session. Authorization asks whether an action should be allowed; the runtime-security discussion asks what happens while the agent is operating.

For a useful technical assessment, seek answers about detection, investigation and containment. Which actions are visible? What evidence explains an alert? Can an administrator interrupt the workflow without disabling unrelated services?

The listing establishes the session’s intended threat coverage. It does not establish specific Defender components, licensing requirements, supported frameworks or configuration procedures. Those details must come from the presentation and corresponding product documentation—not from reading capabilities into the title.

5. Hill climbing: measure improvement, not applause​

“Hill climbing for agents: From 60% to 90% with Open Source and Foundry” is the hands-on selection. Microsoft describes improving an underperforming agent through one measured change at a time, using ASSERT for evaluations and test data, Rubrics for scoring criteria, Agent Control Specification for controls, and Foundry observability, tracing and evaluation signals.

Crucially, the catalog identifies this as LAB661, an expert, level-400 lab—not LAB680, which belongs to a different identity-security exercise. It is listed as in-person only and not recorded.

The percentage in the title describes the exercise’s ambition, not a universal performance guarantee. Microsoft’s description speaks of iterating toward better quality, lower cost and safer outcomes.

Before applying its lessons elsewhere, ask what the score measures. Task completion, answer quality and safe tool use are different targets; a useful evaluation needs an explicit definition of success.

The bigger lesson: judge the operating model​

Taken together, these selections support a narrower—and more useful—interpretation than “agents are ready for everything”: Microsoft’s agenda is connecting agent development with evaluation, access control, runtime defense and iterative improvement. That is an inference from the session topics, not independent proof of product effectiveness.

For attendance planning, prioritize the non-recorded lab if its expert-level material fits your role. Microsoft’s Security Blog also says hands-on labs require an RSVP, so registration alone should not be treated as a reserved seat.

The strongest outcome from this shortlist would not be five pages of announcement notes. It would be a clearer deployment checklist: who owns the agent, what it may access, how its behavior is observed, how failure is contained, and what test results justify putting it to work.