MODULE 8 — Copilot Ecosystem & Skills Architecture¶
8.1 Why This Module Exists¶
Microsoft 365 Copilot is present in most enterprise environments. Unlike custom-built AI systems, Copilot arrives pre-integrated with the tools your organization already uses — Outlook, Teams, Word, Excel, SharePoint — and operates inside your existing Microsoft 365 tenant with access to everything those tools contain.
This creates a fundamentally different architectural challenge from building an AI system from scratch. You are not designing the AI. You are governing an AI that has already been deployed, that users are already using, and that has access to your entire Microsoft 365 data estate by default.
The architect's job in the Copilot context is not primarily technical design — it is permission governance, extension design, security architecture, and organizational change management. Getting Copilot wrong is not a technical failure. It is a governance failure.
This module covers: how Copilot works architecturally, how to extend it safely, what the security risks are and how to mitigate them, and how the broader Copilot ecosystem (Copilot Studio, declarative agents, MCP integration, the Agent Store) fits together.
8.2 How Microsoft 365 Copilot Works Architecturally¶
The Foundation: Microsoft Graph¶
Copilot is not a standalone AI — it is an AI layer over Microsoft Graph. Microsoft Graph is the unified API that provides access to all Microsoft 365 data: emails, calendar events, Teams messages, SharePoint documents, OneDrive files, user profiles, meeting recordings, and more. Copilot queries Microsoft Graph on behalf of the user to retrieve relevant context before generating responses.
M365 COPILOT ARCHITECTURE
User prompt: "Summarize what happened with the Acme deal this week"
│
▼
[Copilot Orchestration Layer]
├── Semantic understanding of the prompt
├── Microsoft Graph query: email + Teams + SharePoint search
│ with user's effective permissions applied
├── Retrieval: relevant emails, chats, documents from this week
├── Context assembly: retrieved content + user profile
└── LLM generation: OpenAI model (hosted on Azure)
│
▼
Response grounded in the user's actual M365 content
The critical architectural fact: Copilot operates entirely within the user's existing permissions. It can see everything the user can see — and nothing more. It does not bypass permissions. But it dramatically increases the speed and efficiency with which a user (or an attacker with a user's credentials) can access and synthesize everything they have permission to see.
This distinction — "Copilot doesn't create new access, it amplifies existing access" — is the foundation of Copilot security architecture. If your permission structure is clean, Copilot amplifies legitimate productivity. If your permission structure has sprawl (which most organizations' M365 environments do), Copilot amplifies that sprawl.
The Oversharing Reality¶
Over 15% of all business-critical files are at risk from oversharing, erroneous access permissions, and inappropriate classification. Concentric AI's Data Risk Report found that 16% of business-critical data is overshared, with an average of 802,000 files at risk per organization.
In most enterprises, this oversharing predates Copilot by years. SharePoint sites were set to "everyone in the organization." Documents were shared via "anyone with the link." Old project folders were never cleaned up. HR spreadsheets were inadvertently accessible to broader groups. These were low-risk issues when access required actively navigating to the content. Copilot makes this content semantically searchable and synthesizable with a natural language prompt.
The assistant does not create new access; it exposes whatever files, emails, chats, and sites users already have, turning long-standing permission sprawl into immediate risk.
The architectural principle: Before deploying Copilot broadly, audit and remediate permissions. Copilot deployment without permission hygiene is the same as giving every user a highly capable research assistant with access to everything they shouldn't have access to, not just everything they should.
8.3 The Two Types of Copilot Agents¶
Microsoft's extensibility model for Copilot produces two distinct agent types with different architectural characteristics:
Type 1: Declarative Agents¶
Built in Copilot Studio or with the Microsoft 365 Agents Toolkit. They use Copilot's underlying LLM (OpenAI models hosted on Azure) and operate within Microsoft's security and compliance framework.
DECLARATIVE AGENT ARCHITECTURE
Declarative Agent = Copilot's LLM + Custom Instructions + Custom Knowledge + Custom Actions
Custom Instructions:
- Agent persona: "You are a procurement assistant"
- Scope constraints: "Only help with purchase order questions"
- Behavior rules: "Always cite the source document"
- Escalation rules: "For orders over $50,000, escalate to procurement manager"
Custom Knowledge Sources:
- SharePoint sites and document libraries
- OneDrive folders
- External URLs (with crawling)
- People directory (live org chart and profile data)
- Copilot Connectors (external data sources via Microsoft Graph connectors)
Custom Actions (via plugins):
- API plugins (call external REST APIs)
- Power Automate flows
- MCP servers (December 2025 addition)
- MCP Apps (April 2026 addition — interactive UI in Copilot chat)
Deployment surface:
- Microsoft 365 Copilot Chat
- Microsoft Teams
- SharePoint pages
- Specific M365 apps
What declarative agents inherit from Copilot: - All of Microsoft's compliance and security controls (Purview, DLP, audit logging) - The user's effective permissions — the agent cannot access data the user cannot access - Microsoft's responsible AI policies and content filtering
What declarative agents do NOT provide: - Model choice — you use Microsoft's hosted OpenAI models; you cannot substitute your own - Infrastructure control — compute and data processing is on Microsoft's infrastructure - Custom evaluation pipelines — you get Microsoft's quality controls, not your own
When declarative agents are the right choice: - The use case is M365-centric (the knowledge lives in SharePoint, Teams, Outlook) - The organization is Microsoft-first and has Copilot licenses - The compliance requirement is Microsoft's M365 trust boundary - The team lacks the infrastructure to build and operate a custom AI system
Type 2: Custom Engine Agents¶
Agents where you bring your own LLM, your own orchestration, and your own data infrastructure. Copilot is the interface (the Teams or M365 chat surface), but the AI logic is yours.
CUSTOM ENGINE AGENT ARCHITECTURE
User in Teams/M365 Chat
│
▼
[Copilot Chat Interface] ──────► [Your Agent Backend]
│
Your LLM (OpenAI, Claude, etc.)
Your orchestration (LangGraph, etc.)
Your knowledge base (your RAG system)
Your tools (your MCP servers)
Your security controls
Your evaluation pipeline
When custom engine agents are the right choice: - The use case requires a specific model (regulatory compliance requiring explainability, domain-specific fine-tuning) - Data cannot reside in Microsoft's infrastructure - You need custom evaluation, custom monitoring, or custom security controls - The knowledge base is not in M365 (it's in your own systems, databases, or vector stores)
The architectural trade-off: Declarative agents are faster to build and inherit Microsoft's compliance infrastructure. Custom engine agents give you full control but require you to build, operate, and govern everything. The decision is not "which is better" — it is "which matches our capability and compliance requirements."
8.4 Copilot Studio: Architecture and Governance¶
Copilot Studio is Microsoft's no-code/low-code platform for building declarative agents and extending Copilot. Understanding what it can and cannot do architecturally prevents both under-use and dangerous misuse.
What Copilot Studio Can Do¶
Agent definition. Define the agent's instructions, knowledge sources, and available actions through a visual interface. Non-developers can create functional agents.
Knowledge source management. Add SharePoint sites, document libraries, URLs, and connectors as knowledge sources. The agent retrieves from these at query time (RAG-style). Important: the content must be accessible to the user asking the question — the agent cannot surface content the user does not have permission to see.
Action definition via plugins. Connect the agent to external systems via API plugins or Power Automate. An agent can create tickets in ServiceNow, update records in Dynamics 365, or trigger workflows — subject to the permissions of the user or a service account.
Publishing and access control. Publish agents to specific Teams channels, SharePoint pages, or the entire organization. Control which users or groups can interact with each agent.
The Agent Store. Microsoft's Agent Store provides a catalog of pre-built agents from Microsoft and partners (ServiceNow, Workday, SAP, and others). These can be adopted and extended within your Copilot environment without building from scratch. The governance implication: third-party agents from the Agent Store require the same security review as any connector or plugin — "available in the Microsoft ecosystem" does not mean "reviewed for your organization's data access patterns."
Licensing tiers and their architectural implications. Different Copilot capabilities require different licenses: - Microsoft 365 Copilot (full license): Full Copilot in all M365 apps, agent creation in Copilot Studio, all data access - Copilot Chat (free tier): Web-grounded only, no M365 data access — significantly lower security risk as the oversharing problem does not apply - Copilot Studio (standalone): Build agents for non-M365 surfaces without full M365 Copilot license
The practical implication: organizations can tier their deployment, starting with Copilot Chat (web only, lower risk) before enabling full M365 data access. This staged approach reduces the permission hygiene requirement for the initial rollout.
What Copilot Studio Cannot Do¶
Override Microsoft's content policies. Copilot Studio agents operate within Microsoft's responsible AI guardrails. You cannot configure an agent to bypass Microsoft's safety filters.
Access data the user cannot access. The agent's knowledge retrieval is bounded by the user's effective permissions. An agent configured to use a SharePoint site the user cannot access will not surface that content for that user.
Use non-Microsoft LLMs for declarative agents. Declarative agents use Microsoft's hosted models. If you need GPT-5.x, Claude, or Gemini, you must build a custom engine agent.
Provide model-level observability. You cannot access token counts, latency breakdowns, or quality metrics at the LLM call level. You get Microsoft's telemetry, not your own eval pipeline.
The Governance Architecture for Copilot Studio¶
Without governance, Copilot Studio becomes a proliferation problem. Any Microsoft 365 user with the right license can create agents and publish them to the organization. The result: dozens of ungoverned agents, inconsistent behavior, unknown data access patterns, and no accountability.
COPILOT STUDIO GOVERNANCE MODEL
TIER 1: ADMIN CONTROLS (Microsoft Admin Center)
├── Who can create agents: restrict to specific security groups
├── Who can publish organization-wide: restrict to IT-approved creators
├── Which knowledge sources are permitted: block external URLs not on allowlist
├── Which connectors are enabled: audit and approve each connector
└── DLP policies applied to all agents: enforced by Purview
TIER 2: AGENT APPROVAL PROCESS (organizational process)
├── Agent registry: every production agent documented with owner,
│ purpose, data sources accessed, and action scope
├── Security review gate: any agent accessing sensitive data reviewed
│ by security team before organization-wide publish
├── Quarterly agent audit: review all active agents, retire unused ones
└── Change process: modifications to production agents require review
TIER 3: RUNTIME MONITORING (Microsoft Purview + custom)
├── Copilot interaction audit logs: what was asked, what was retrieved,
│ what was generated — all available in Purview
├── DLP alerts: when sensitive information types detected in prompts
└── Usage analytics: which agents are used, by whom, how often
8.5 The Oversharing Problem: The Architect's Pre-Deployment Checklist¶
The primary Microsoft Copilot security risk involves overpermissioning scenarios. If a user has access to sensitive information (such as salary spreadsheets), Copilot gains identical access. This can lead to sensitive information exposure, as AI models might include confidential data in their outputs.
This is not a Copilot bug. It is a permissions debt problem that Copilot makes consequential. The architect's job before Copilot deployment:
Phase 1: Data Access Audit¶
What Copilot can reach. For each target user group (executives, HR, finance, engineering, customer-facing staff), map what content they have permission to access in M365. Use Microsoft's built-in tools (SharePoint permissions reports, Purview Data Map) or third-party tools (Opsins, Varonis, Concentric AI) to get a complete picture.
Oversharing hotspots. Identify the highest-risk oversharing patterns: - "Everyone" or "All employees" SharePoint permissions on sensitive content - Salary data, HR records, M&A documents accessible to broader groups than intended - "Anyone with the link" sharing on sensitive documents - Stale site collections with broad permissions from old projects - External sharing enabled on sensitive sites
The Copilot amplification assessment. For each oversharing pattern identified: what could a user with access to this content now retrieve with a natural language Copilot query? The answer to this question is the business risk. "How much does our CEO make?" was previously an effort-intensive question to answer through SharePoint. With Copilot, it is a one-sentence prompt if the data is accessible.
Phase 2: Sensitivity Labeling¶
Copilot outputs don't consistently inherit security labels from source files. This means sensitive data generated or surfaced by Copilot can end up unclassified and improperly shared, putting the burden on employees to catch and fix classification gaps.
Microsoft Purview Information Protection sensitivity labels control what Copilot can do with labeled content:
SENSITIVITY LABEL CONFIGURATION FOR COPILOT
Label: CONFIDENTIAL
├── Copilot can summarize within the tenant: YES
├── Copilot can include in external-facing responses: NO
├── Copilot-generated output inherits label: YES (manually configure)
└── DLP policy: block export of CONFIDENTIAL content in Copilot responses
Label: HIGHLY CONFIDENTIAL (e.g., salary data, M&A)
├── Copilot can summarize for the document owner: YES
├── Copilot can include in responses to others: NO (permission-bounded)
├── Copilot-generated output inherits label: YES
└── Audit every Copilot interaction with HIGHLY CONFIDENTIAL content
Label: RESTRICTED (legal hold, litigation)
├── Exclude from Copilot knowledge sources entirely
└── Configure restricted SharePoint sites as excluded from Copilot
Phase 3: DLP for Copilot¶
Microsoft Purview Data Loss Prevention for Microsoft 365 Copilot prevents Copilot and agents from using sensitive data for external web searches. If a sensitive information type is detected in a user prompt, Copilot can still leverage your enterprise data to form a response without sending the sensitive data to external search engines.
This is now generally available and should be enabled before organization-wide Copilot deployment. Configure DLP policies to: - Block Copilot prompts containing credit card numbers, SSNs, and other sensitive information types from reaching external grounding (web search) - Alert on prompts containing certain sensitive patterns (project code names, M&A terminology) - Block Copilot from generating responses that would expose certain data categories to users without appropriate roles
8.6 Copilot Security Risks: The Architect's Threat Model¶
Risk 1: Data Oversharing Through Permission Sprawl (Highest Impact)¶
Already covered in 8.5. This is consistently the highest-impact Copilot risk identified by Gartner, Microsoft, and security researchers.
Mitigation: Pre-deployment permission audit and remediation. Sensitivity labeling. DLP policies. Ongoing permission drift monitoring.
Risk 2: Prompt Injection in Copilot¶
In January 2026, a prompt injection flaw turned Copilot into a data-stealing tool with a single click. In October 2025, a now-patched flaw enabled data exfiltration through crafted diagrams.
Prompt injection attacks against Copilot are active and being discovered regularly. The attack pattern: malicious instructions are embedded in a document, email, or Teams message that the user (or Copilot) reads. Copilot interprets these instructions and takes actions it should not — exfiltrating data, sending unauthorized emails, modifying content.
Researchers discovered CVE-2026-26133, a cross-prompt injection vulnerability in Copilot's email summarization feature.
Mitigation: Keep Copilot updated (Microsoft patches these vulnerabilities). Follow Microsoft's guidance on restricting Copilot's access to likely sources of malicious prompts, particularly email inboxes from external senders. Enable instruction filters. For agents built in Copilot Studio, scope the agent's knowledge sources to controlled content, not open email inboxes. Monitor Copilot audit logs for anomalous patterns (an agent accessing data far outside a user's normal patterns).
Risk 3: Plugin and Connector Data Leakage¶
Every plugin and connector added to a Copilot agent expands the data access surface. A misconfigured connector can give Copilot access to external systems with overly broad credentials, or can expose data from those external systems to users who should not have access to it.
The connector trust model:
CONNECTOR SECURITY ANALYSIS
For every Copilot connector or plugin, answer:
1. What credentials does this connector use?
- User-delegated (user's own permissions apply): Safer
- Service account (fixed permissions regardless of user): Riskier
2. What data does this connector expose?
- If service account: can any user query ANY data the service account can see?
- Map the effective data access for the connector
3. Are the exposed data types classified?
- Does this connector expose PII? Financial data? HR data?
- Are DLP policies configured for this connector?
4. Is the connector's data usage audited?
- Every query to the connector should be logged
- Anomalous query patterns should alert
Service account connectors are the highest risk. If a Copilot connector uses a service account with read access to your entire CRM, any user who has access to the Copilot agent with that connector can effectively query your entire CRM through natural language. Scope service account permissions to the minimum necessary for the connector's declared purpose.
Risk 4: Insider Threat Amplification¶
Privileged users become high-impact vectors: executives, IT, HR, and finance users often have broad access, and AI makes it faster to pull and combine sensitive information across domains without intent.
A malicious insider with broad M365 permissions can use Copilot to research and exfiltrate data far more efficiently than manual browsing. An HR manager who could previously access salary data for their division can now query salary patterns across the organization if permissions were not properly scoped.
Mitigation: Privileged access monitoring for Copilot interactions. Alert on users querying data patterns significantly outside their normal activity. Enable Microsoft Purview Insider Risk Management with Copilot integration — it can detect anomalous Copilot behavior patterns.
Risk 5: Sensitivity Label Inheritance Gap¶
When Copilot generates a response that synthesizes content from multiple labeled documents, the generated output may not inherit the appropriate sensitivity label. A user copies the response into an email and sends it externally — the label that would have blocked external sharing was never applied to the synthesized output.
Mitigation: Configure Copilot to apply the highest sensitivity label from any source document to the generated output. Enable this in Purview Information Protection settings. Train users: Copilot-generated summaries that reference sensitive source material inherit the classification of that source.
8.7 Copilot Connectors and Plugins: Architecture¶
Copilot Connectors (Graph Connectors)¶
Copilot Connectors (formerly Microsoft Graph Connectors) bring external content into Microsoft Graph, making it searchable and retrievable by Copilot alongside native M365 content.
COPILOT CONNECTOR ARCHITECTURE
External System (ServiceNow, Salesforce, Confluence, custom DB)
│
▼
[Graph Connector]
├── Crawls external content on a schedule
├── Indexes content into Microsoft Graph
├── Maps external permissions to M365 identities
└── Makes content available for Copilot retrieval
│
▼
[Microsoft Graph] — unified content index
│
▼
[Copilot] — can now retrieve from external systems
alongside native M365 content
The permission mapping problem. External systems have their own permission models. Mapping them accurately to M365 user identities is non-trivial and often imperfect. A connector that maps "everyone in the external system" to "everyone in M365" effectively grants all M365 users access to all external content. Audit every connector's permission mapping before enabling it in production.
Content freshness. Connectors crawl on schedules (not real-time). A policy document updated in Confluence may take hours to appear in Copilot. For time-sensitive content, this staleness is a quality and compliance risk.
API Plugins¶
API plugins let Copilot agents call external REST APIs directly. Unlike connectors (which index content), plugins enable actions — querying live data, updating records, triggering workflows.
API PLUGIN SECURITY MODEL
Plugin manifest declares:
├── Authentication method (OAuth, API key, managed identity)
├── Available operations (list of API endpoints)
├── Data handling attestation (what data the plugin processes)
└── Permissions required
At runtime:
├── User authenticates to the external system via the plugin
├── Copilot can only call operations the user is authorized for
└── All plugin calls are logged in Purview audit
Risk: Over-declared permissions in the manifest
If the manifest declares more operations than needed,
Copilot may call operations that should be out of scope.
Apply minimum-necessary operations in the plugin manifest.
MCP Integration (December 2025 Addition)¶
Microsoft added MCP support to M365 Copilot declarative agents in December 2025. This is architecturally significant: it means the MCP ecosystem (covered in Module 7) is now directly accessible within the Copilot environment.
MCP Apps let Microsoft 365 Copilot declarative agents render interactive UI — expense approval forms, project dashboards, document comparisons — directly inside the Copilot chat experience.
Architectural implications: - Any MCP server in your enterprise portfolio can now be connected to a Copilot declarative agent - This dramatically expands what declarative agents can do without requiring custom engine agents - The MCP governance registry (Module 7) must include Copilot-connected MCP servers - The same supply chain risks that apply to standalone MCP servers apply here — an unreviewed MCP server connected to Copilot inherits Copilot's data access
8.8 GitHub Copilot: Architecture and Enterprise Governance¶
GitHub Copilot is architecturally distinct from M365 Copilot but shares the same governance principles. It is the AI coding assistant embedded in development environments.
What GitHub Copilot Can Access¶
GITHUB COPILOT CONTEXT WINDOW (what the model sees)
Current file content:
├── Current file being edited
├── Open tabs in the editor
└── Recently viewed files
Repository context (with GitHub Copilot Enterprise):
├── Full repository codebase (semantic search)
├── Pull request history
├── Issue discussions
└── Wiki content
External knowledge (GitHub Copilot Chat):
├── Public code repositories (training data)
└── Documentation from @docs references
The Secret Leakage Risk¶
The most consequential security risk in GitHub Copilot is credentials and secrets appearing in context. A developer with .env files, config.yaml files containing API keys, or hardcoded credentials in nearby open tabs sends that content to the Copilot API as context.
What happens: 1. Developer opens a file containing an API key 2. Developer asks Copilot to help debug a related file 3. The context window includes the file with the API key 4. That content is transmitted to GitHub's (Microsoft's/OpenAI's) API 5. The key has crossed your perimeter
Mitigation architecture:
- Configure .gitignore to exclude secret-containing files
- Use .copilotignore (GitHub Copilot's equivalent) to exclude sensitive files from context
- Enforce pre-commit hooks that scan for secrets before they reach any repository
- Use a secrets management system (HashiCorp Vault, AWS Secrets Manager) — never hardcode credentials in files that developers edit
- GitHub Copilot for Business includes "code referencing" controls — configure whether Copilot can suggest code matching public repositories (IP risk)
The IP and Code Ownership Risk¶
Code generated by GitHub Copilot may be substantially similar to code in its training data (public GitHub repositories). This creates intellectual property risk: generated code may inadvertently reproduce GPL-licensed or otherwise encumbered code.
Mitigation: GitHub Copilot for Business includes duplicate detection — filtering suggestions that closely match public repository code. Enable this. Establish a policy on Copilot-generated code review: all Copilot-suggested code that becomes part of a production codebase should be reviewed by a human developer, not just accepted.
8.9 The Copilot Deployment Architecture Sequence¶
The sequence in which Copilot capabilities are deployed matters as much as the configuration. A common failure pattern: deploy Copilot broadly, discover the oversharing problem, attempt remediation with Copilot already in use.
RECOMMENDED COPILOT DEPLOYMENT SEQUENCE
Phase 1: Foundation (before any user access)
├── Permission audit: identify oversharing hotspots
├── Remediate highest-risk oversharing (salary, HR, M&A, legal)
├── Sensitivity labeling: classify business-critical data
├── DLP policies: configure for Copilot scenarios
└── Purview audit logging: enable Copilot audit before deployment
Phase 2: Pilot (controlled user group, ~100 users)
├── Select pilot users across diverse roles and data access profiles
├── Monitor audit logs: what content is being retrieved? By whom?
├── Identify unexpected content surfacing (oversharing that was missed)
├── Collect quality feedback: is Copilot finding the right content?
└── Refine permission remediation based on pilot findings
Phase 3: Expansion (department by department)
├── Remediate department-specific oversharing before enabling per dept
├── Enable department by department, not organization-wide at once
├── Monitor for anomalous access patterns per department
└── Train users: what Copilot can and cannot be trusted to do
Phase 4: Agent Deployment (after Copilot is stable)
├── Establish Copilot Studio governance (Section 8.4)
├── Deploy agents through approval process
├── Connector permission audits before each connector goes live
└── Plugin security reviews before each plugin is enabled
Phase 5: Advanced Capability (MCP, custom engine agents)
├── MCP server integration after MCP governance registry is in place
├── Custom engine agents for use cases that need model flexibility
└── Continuous monitoring: usage, cost, security anomalies
8.10 The Copilot Readiness Assessment¶
Before any Copilot deployment milestone, answer these questions:
Data governance readiness - [ ] Permission audit completed for target user groups? - [ ] High-risk oversharing remediated (salary, HR, M&A, legal, PII)? - [ ] Sensitivity labeling applied to business-critical data? - [ ] DLP policies configured and tested for Copilot scenarios? - [ ] Purview audit logging enabled for Copilot?
Agent and extension readiness - [ ] Copilot Studio governance policy defined (who can create, who can publish)? - [ ] Agent registry established? - [ ] Connector permission mapping audited for each connector? - [ ] Plugin manifests reviewed for minimum-necessary operations? - [ ] MCP servers in the enterprise governance registry?
Security readiness - [ ] Threat model documented for Copilot deployment? - [ ] Insider risk monitoring configured for Copilot? - [ ] Prompt injection mitigation in place for email-connected agents? - [ ] Incident response procedure for Copilot security events defined?
GitHub Copilot readiness (if applicable)
- [ ] .copilotignore configured to exclude secrets-containing paths?
- [ ] Secret scanning pre-commit hooks enforced?
- [ ] Duplicate detection (code referencing) enabled?
- [ ] Policy on human review of Copilot-generated code established?
EXERCISE — Oversharing Impact Assessment: For a user population in your organization (choose a high-risk group: executives, HR, finance, or IT), map the M365 content they currently have permission to access that they regularly use. Then map the content they have permission to access that they would not normally navigate to manually. The second category is Copilot's amplification risk. Quantify: how many documents, how sensitive, what would the business impact be if this content were synthesized and shared inappropriately?
PONDER — The Permission Audit Question: If Copilot were deployed to your entire organization today, what is the single most sensitive piece of information that could be surfaced to a user who should not see it? How does it currently have broad permission? What would it take to fix the permission? How long would the fix take vs. how quickly Copilot could be deployed?
WORKSHOP — Copilot Agent Design: Design a declarative agent for a specific business use case (employee onboarding assistant, procurement policy advisor, IT helpdesk assistant). Define: instructions, knowledge sources, actions/plugins, permission requirements, governance process for changes, sensitivity label configuration, and the DLP policies that apply. Identify the two highest security risks and the specific mitigation for each.
WORKSHOP — GitHub Copilot Security Audit: For your development environment: map every file type that developers regularly have open alongside code they are editing. Which of those files could contain secrets, credentials, or sensitive business information? Design the
.copilotignoreconfiguration and pre-commit hook policy that prevents secrets from reaching Copilot's context. Define the code review policy for Copilot-generated code.
Next: Module 9 — AI Security Architecture