Microsoft Copilot Studio Governance and Security

Track outline from the bookPractitioner, platform-specific15 modules · 5 parts

The 15 modules below follow the book's chapters. Every module ends with a reusable artifact such as a checklist, worksheet, test set, or playbook. Production has not started, and platform features change quickly, so each module will carry a verification date.

Who it is for. Copilot Studio makers and AI engineers, AI security engineers and red teamers, cloud and enterprise security architects, Power Platform administrators, Microsoft 365 and identity engineers, SOC and detection engineers, GRC teams, and federal and regulated-industry architects.

Part I: Foundations of the Agentic Enterprise

Module 1: The Foundations of the Agentic Enterprise

What the module covers. Copilot Studio lets a business analyst assemble, in an afternoon, a system that reads enterprise documents, reasons over untrusted text, and acts on enterprise systems with someone's credentials. This chapter explains why that moves the security question from "what can the model say?" to "what authority does the agent hold?" It defines the platform's building blocks, introduces the Agent Capability Spectrum and the Agent Authority Security Model, positions NIST, OWASP and MITRE ATLAS guidance against them, and closes with the Agent Security Discovery Questionnaire applied to Company A.

Chapter artifact: Agent Security Discovery Questionnaire

Module 2: Security and Governance Fundamentals

What the module covers. Chapter 1 argued that securing an enterprise agent is fundamentally about governing authority. This chapter turns that argument into a governance architecture: the five governance questions, Power Platform environments as the primary governance boundary, Microsoft's documented zoned-governance guidance with the author's Green / Yellow / Red model mapped onto it, and how threat modeling, shift-left security, risk classification, evidence and ownership fit together under Secure / Control / Track and Verify. The practitioner artifact is the Copilot Studio Agent Risk Classification Worksheet, applied to Company A agents.

Chapter artifact: Copilot Studio Agent Risk Classification Worksheet

Part II: Secure Architecture and Lifecycle

Module 3: Environment Governance and Secure ALM

What the module covers. Every Copilot Studio agent lives inside a Power Platform environment, which inherits policy from the tenant and, optionally, from an environment group. That hierarchy answers the governance question "where can they build?" and decides most of an agent's inherited authority before a maker writes the first instruction. This chapter covers environment types, Managed Environments, security roles, environment groups and rules, routing, and the solution-based application lifecycle management (ALM) chain: pipelines, connection references, and environment variables. It shows how to configure, verify, and test each control, where environments stop being a defense, and closes with Company A's Production Deployment Gate.

Chapter artifact: Production Deployment Gate

Module 4: Agent Identity, Authentication, and Authorization

What the module covers. Every Copilot Studio agent operates at the intersection of at least three identities: the user who talks to it, the maker who built it, and the identity that holds the credentials its tools actually use. Since May 2026 a fourth -- the agent's own Microsoft Entra Agent ID -- sits on top of that stack. This chapter shows which identity authorizes each downstream transaction and how to configure authentication, connections, Conditional Access, RBAC, and lifecycle so that authority stays bounded and attributable. It ends with an identity review checklist and Company A's identity decisions for three agents.

Chapter artifact: Agent Identity Review Checklist

Module 5: Data Security, Knowledge, Grounding, and DLP

What the module covers. An agent answers from what it can retrieve, and it retrieves under some identity, from some source, inside some policy boundary. This chapter examines the Knowledge element of the Agent Authority Security Model and the data-protection plane around it: data policies (DLP) and the Copilot Studio virtual connectors, the per-source retrieval identity model, SharePoint oversharing controls, sensitivity labels and Microsoft Purview, and the residency, encryption, and channel decisions that determine who can read an answer. It states what DLP does not do and gives the practitioner a Knowledge Source Security Review to run before any source is approved.

Chapter artifact: Knowledge Source Security Review

Module 6: Tools, Actions, Connectors, Power Automate, and MCP

What the module covers. Tools are where an agent stops describing the world and starts changing it. This chapter treats every connector action, agent flow, prompt, REST API endpoint, HTTP request, and Model Context Protocol (MCP) tool as a privileged execution path whose authority must be deliberately granted, bounded, and evidenced. It explains which identity executes a tool call, how data policies, advanced connector policies, Microsoft Entra Agent ID scopes, per- tool settings, and the Microsoft 365 Agent Tools registry fit together, and where the gaps remain. It closes with the Tool and MCP Security Assessment applied to Company A's DeskFlow and ProcureAssist agents; prompt injection is Chapter 7, autonomy Chapter 8, runtime protection Chapter 9.

Chapter artifact: Tool and MCP Security Assessment

Part III: Adversarial Security and Runtime Defense

Module 7: Prompt Injection, Jailbreaking, and Agent Manipulation

What the module covers. A language model cannot tell the difference between the text it was told to obey and the text it was told to read. In a chatbot that weakness produces embarrassing output; in a Copilot Studio agent with SharePoint knowledge, ticket access, and connectors, it produces unauthorized actions under someone's credentials. This chapter dissects direct, indirect, cross-domain (XPIA), triggered, and multi-turn manipulation, prompt leakage, and exfiltration paths; states what Microsoft documents about Copilot Studio's built-in protections and what they do not guarantee; and shows how to bound impact through instruction design, tool scoping, confirmation topics, untrusted-content handling, and a reusable Prompt Injection Test Set. Prompt injection cannot be eliminated, only bounded, and the bound is set by authority, not by filters.

Chapter artifact: Prompt Injection Test Set

Module 8: Excessive Agency, Autonomy, and Workflow Integrity

What the module covers. Earlier chapters asked whose identity an agent uses, what it can know and reach, and how it can be manipulated. This chapter asks the question that turns those properties into damage: how much can the agent do, how far, and without whom noticing? It defines excessive agency in Copilot Studio terms, explains how event-triggered agents execute unattended under the maker's credentials, and shows how chained actions, connected agents and approval bypass turn one manipulated input into a business-process failure. It then gives the controls that bound that authority -- human-in-the-loop design, transaction limits, reversibility, tested kill switches -- and the Autonomy and Excessive Agency Review artifact.

Chapter artifact: Autonomy and Excessive Agency Review

Module 9: Runtime Security and Threat Protection

What the module covers. The controls in Chapters 3 through 8 are applied before an agent runs. This chapter is about the moment they are tested: a generative orchestrator has decided to call a specific tool with specific parameters, and the only remaining question is whether that call should happen. It explains what Copilot Studio protects by default and what Microsoft does not guarantee, how the preview external threat detection mechanism inserts a decision point between reasoning and action, how Microsoft Defender's real-time protection rides on that mechanism, and why the fail-open default and per-environment scoping make the design decisions yours. Runtime detection is a detection and decision layer that reduces risk, not an authorization boundary.

Chapter artifact: Runtime Protection Configuration Checklist

Part IV: Security Operations and Assurance

Module 10: Inventory, Monitoring, Audit, and Detection

What the module covers. Every control in Chapters 3 through 9 assumes that someone knows which agents exist, who owns them, what they can reach, and what they did last night. This chapter builds that knowledge: the documented enumeration paths for Copilot Studio agents, the telemetry that Microsoft Purview, Microsoft Defender XDR, the Power Platform admin center, Microsoft Entra ID and Microsoft Sentinel provide, a starter set of detections with their queries and tests, and the Company A SOC's first real agent alert. Incident handling belongs to Chapter 11; Agent 365 governance to Chapter 12.

Chapter artifact: Agent Detection Engineering Starter Matrix

Module 11: AI Incident Response and Forensics

What the module covers. An agent incident is an authority event: an identity the agent used, a tool it invoked, a record it changed, or data it surfaced to someone who should not have seen it. This chapter defines the agent incident, walks the nine-stage lifecycle from detection to review, and shows which Copilot Studio, Power Platform, Microsoft Entra, Microsoft Purview and Microsoft Defender actions contain an agent, who may perform them, and what evidence they leave. The gaps are real: the audit log has no message text, no PowerShell cmdlet quarantines an agent, and Customer Lockbox does not cover security-audit egress. The practitioner artifact is the Copilot Studio Agent Incident Playbook.

Chapter artifact: Copilot Studio Agent Incident Playbook

Part V: Enterprise Governance at Scale

Module 12: Enterprise Agent Governance and Microsoft Agent 365

What the module covers. Chapters 3 through 11 secured one agent at a time. This chapter secures the population: can the organization enumerate every agent, name an accountable owner for each, approve what deserves approval, notice when authority drifts, and retire what should no longer run? Microsoft Agent 365 provides a cross-platform registry and lifecycle actions; the Power Platform admin center retains environment, sharing and quarantine controls; Microsoft Entra, Purview and Defender feed risk signals into both. The chapter runs those planes as one cycle -- Approve Monitor Review Remediate Reapprove -- staffed, measured and automated by a Center of Enablement.

Chapter artifact: Enterprise Agent Governance Operating Model

Module 13: Government, Regulated, and GCC Deployments

What the module covers. Copilot Studio in the US Government clouds is the same product with a different authority surface: fewer channels, no event triggers, fewer knowledge sources, connectors that arrive switched off, and a security-operations stack whose agent-specific pieces are largely undocumented for GCC, GCC High, and DoD. This chapter treats each difference as a design input: a dated, cited account of what is and is not available (Verified 2026-09-17), what the gaps do to the Agent Authority Security Model, how to compensate with GA controls, and the Government Cloud Feature Validation Matrix to re-run before every deployment. Regulated industries outside government get the same treatment at principle level against NIST SP 800-53, SP 800-207, ISO/IEC 42001, and the EU AI Act.

Chapter artifact: Government Cloud Feature Validation Matrix

Module 14: Secure Reference Architectures

What the module covers. This chapter assembles the controls from Chapters 3 through 13 into six deployable reference architectures for Company A's agents: knowledge, departmental business, enterprise transactional, autonomous event-triggered, MCP-enabled security operations, and regulated high-sensitivity. Each answers the same fourteen questions in the same order and closes with a control table and a test table; the chapter ends with the Architecture Review Template, which applies the Agent Authority Security Model per zone. Preview features are labelled and never the only control.

Chapter artifact: Architecture Review Template

Module 15: Implementation Roadmap for Practitioners

What the module covers. Chapters 1-14 explained what to control and why; this chapter explains in what order. It turns the book's controls into a six-phase program -- Discover, Govern, Secure, Validate, Operate, Improve -- aligned to Microsoft's documented governance guidance and to the Green / Yellow / Red zones. Each phase states objectives, activities cross-referenced to the chapter that explains them, controls with their GA or preview status, roles, entry and exit criteria, evidence, pitfalls and KPIs. The chapter closes with a 30/60/90-day roadmap, a minimum-viable-governance list, and the Company A program as it unfolded.

Chapter artifact: 30/60/90-Day Roadmap