Azure Copilot is evolving from a conversational interface into a fleet of specialised agents for investigating, troubleshooting, deploying, optimising, and operating the cloud. Modern applications generate an overwhelming volume of telemetry, configuration data, and operational context, far more than any human can absorb, correlate, and act on at the speed modern cloud operations require. Copilot does much of the heavy investigative lifting, turning a sky full of signals into a clear forecast: findings, plans, and proposed actions. Yet the captain still makes the call. This session takes a practical, demo-led look at operating with Azure Copilot, drawing on my experience as an Azure MVP providing feedback to the team building Copilot since its earliest days. We will explore the current agents, examine what each one delivers in practice (an explanation, a plan, a script, or a pull request), and see exactly where the approval gate sits before anything changes in your environment. Operating with Copilot also means understanding the control tower: who is cleared for take-off through admin controls; what Copilot can access and act on through your identity, RBAC, Azure Policy, and resource locks; and how BYOS retains every Copilot interaction in your own environment for audit and governance. Packed with the latest capabilities announced at Microsoft Ignite, this session covers where Copilot is heading as well as what you can use today. You will leave knowing what Copilot can do for you, how to roll it out safely from day one, and where the captain's seat remains yours.

Hype is a timeline error... again. Almost everything you are being told about AI right now is true. The timeline is a lie. I was in the audience at PDC in Los Angeles in October 2008 when Ray Ozzie announced "Windows Azure". I proceeded to become one of the first experts in a field that was still entirely theoretical, decorated for it sixteen years running, for a war that had not started yet. I was right about the destination. I was badly, expensively wrong about the timeline. There is a new generation of experts, this time in AI, collecting the same medals. I recognise the badge. I wore one exactly like it, and I am going to tell them what happens next, because I already lived it. This keynote puts two hype cycles side by side. What genuinely rhymes, what is genuinely different this time, and what an architect should do about it on Monday morning.

Most organisations cannot answer two questions about their own source code: what protects it, and who can reach it. Rulesets exist in some repositories and not in others, and they are never the same everywhere. Access granted to code only ever accumulates and is never revoked, and managing that is a manual task that falls to "someone". Fixing this changes how people work, and that is where the protection comes from. Every change to protection is reviewed before it applies, and every grant of access is approved by a second person. Nothing depends on anyone remembering how things are supposed to be. Mistakes and omissions are captured and corrected. No drift and no inappropriate access! This session walks through a working implementation of two engines, using IaC and GitHub Actions with a supporting act by Entra ID. The first declares rulesets as code, compares them against live configuration for drift, and realigns repositories automatically to adhere to the rules. It blocks. The second reports who has access to what code, with warnings when something is out of line. A team member can request access to a code base and a colleague approves it, with the grant applied automatically. Revoking access happens immediately, with no approval at all. Expect live configuration, real code, and the things that broke on the way. You leave with a model where protection survives the first time it is inconvenient, and where the answer to who can reach your code is a report rather than a screenshot.