Multiple AI agents delegating work to each other and calling outside tools sounds risky. Here's how Copilot Studio keeps it governed. Multi-agent AI is moving fast from research demo to production pattern but "agents talking to agents and calling out to arbitrary tools" is exactly the kind of architecture that makes security and compliance teams nervous. This session is for the room that has to say yes or no to that architecture. We'll cover Copilot Studio's Agent-to-Agent (A2A) communication (now GA) and its new orchestration layer, then focus on Model Context Protocol (MCP) the standardized integration layer that lets agents reach external tools without bespoke connectors. MCP support means Copilot agents now share the same tool-connection surface as Claude and Gemini agents, which raises real governance questions for organizations running mixed AI-provider estates: whose permissions apply, what gets logged, and where compliance boundaries actually live. A live build will show an orchestrator agent delegating to a specialist agent grounded via a remote MCP server (currently preview), followed by a walkthrough of the permission scoping and content moderation controls that keep this pattern inside enterprise guardrails not just what's possible, but what's actually governable today. You'll leave with a practical framework for evaluating multi-agent AI proposals from a security and compliance lens, not just an architecture diagram. Takeaways: - Architecture patterns for multi-agent orchestration (A2A, connected vs. embedded agents) - How MCP creates a vendor-neutral tool layer — and what that means for governance across mixed AI-provider environments - Practical guardrails: permission scoping and content moderation when agents call external tools autonomously

The conversation in most organizations right now sounds something like this: "We need to start using Copilot." "Great. Who's setting it up?" "...good question." Copilot is exciting. The demos are impressive. The productivity gains are real. But there's a version of this rollout that goes smoothly - and a version that creates security gaps, confused users, uncontrolled data access, and a governance mess that takes months to untangle. The difference between those two versions isn't budget or timing. It's preparation. Before your organization turns Copilot on, there are conversations that need to happen, decisions that need to be made, and foundations that need to be in place. Not because Microsoft says so - but because we've seen what happens when they're skipped. In this session, we walk you through exactly what to set up before you flip the switch. Who needs access and who doesn't - and why that decision matters more than you think. How your data landscape needs to look before Copilot starts reading it. What policies, guardrails, and logging to have in place from day one. How to bring your developers, admins, and leadership into the same conversation before you're all speaking different languages. This isn't about slowing down your Copilot journey. It's about making sure that when you start, you start right - with clarity, confidence, and a foundation built to grow. Because turning Copilot on is easy. Cleaning up what happens when you weren't ready? That's the hard part. Let's make sure you never find out.