A risk register for Copilot Studio agents that consume MCP servers: twenty-four risks across supply chain, tool integrity, identity, data protection, governance, operations and compliance, each with its mitigating controls, the platform feature that delivers them, and the residual rating that survives. This is the implementation guide, in 11 steps.

Originally published at https://beyondtheprompt.dev/posts/mcp-copilot-studio-threat-model on 17 August 2026.

1. 1. Purpose

This document enumerates the security, privacy, governance and operational risks introduced by allowing Copilot Studio agents to consume MCP servers, and states the mitigating controls, the platform feature that delivers each control, and the residual risk after mitigation.

It is intended to be consumed alongside the existing Copilot Studio agent threat model, not to replace it. Risks that apply to any Copilot Studio agent (knowledge oversharing, channel exposure, authentication mode selection) are referenced but not restated in full.

2. 2. Architecture context and trust boundaries

Understanding the plumbing matters, because most mitigations are inherited rather than MCP-specific.

Key architectural fact: MCP servers reach Copilot Studio through the Power Platform connector infrastructure. An MCP server is, mechanically, a connector endpoint. This means MCP integrations inherit the Power Platform governance surface - data policies, advanced connector policies, virtual network integration, connection management, and the connection-sharing model - whether or not that surface was deliberately configured for MCP.

Runtime flow:

Trust boundaries:

Critical property of TB-2: every tool description, parameter schema and tool result from every connected MCP server enters the same model context. A malicious or compromised server can therefore influence the agent’s handling of a different server’s data. Multi-server agents are not isolated from one another.

3. 3. Assumptions

1. Agents are built and published through governed DTAP environments; the default environment is treated as untrusted for MCP.
2. All MCP endpoints are HTTPS with TLS 1.2+.
3. Generative orchestration is enabled (required for MCP tool selection).
4. Tenant has Power Platform Managed Environments and Purview licensing available.
5. Entra Agent ID / Agent 365 capabilities are assumed partially available; risks that depend on them are flagged as roadmap-dependent.

Out of scope: MCP clients outside Copilot Studio (VS Code, Foundry, Claude Desktop, etc.); the security of the LLM itself; physical and datacentre security.

4. 4. Risk scoring

Likelihood (L) and Impact (I) on a 1–5 scale. Rating = L × I.

5. 5. Risk summary

6. 6. Risk detail and mitigations

Domain A - Supply chain and server trust

MCP-01 · Unvetted third-party MCP server introduced by a maker

STRIDE: Spoofing, Information disclosure, Elevation of privilege · Inherent 4×5 = 20 · Residual 2×3 = 6

A maker adds an arbitrary HTTPS MCP endpoint through the onboarding wizard. Empirical analysis of open-source MCP servers has found a material proportion exhibiting tool-poisoning characteristics - altered descriptions, injected responses, or redirection of data to unauthorised endpoints. The server may be attacker-controlled, tunnelled from a developer laptop, or a legitimate service with poor security posture.

Mitigations

• Preventive: Operate an MCP allowlist. Configure Advanced Connector Policies (ACP) as a strict allowlist so that new connectors and MCP servers default to blocked; scope via environment groups.
• Preventive: Restrict MCP server addition rights to a defined maker role in D/T environments only. Production agents receive MCP servers via solution deployment through the ALM pipeline, never by direct authoring.
• Preventive: Prefer Microsoft first-party MCP servers and servers that have passed Microsoft MCP server certification (Partner Center, currently preview). Treat certification as a floor, not an assurance.
• Detective: Weekly reconciliation of connectors and MCP servers present in each environment against the approved register (CoE Starter Kit inventory or Power Platform API).
• Corrective: Documented takedown path - block server at ACP, which suspends dependent agents at runtime.

Onboarding gate: named service owner, security review, data classification declaration, hosting location, and responsible-AI assessment recorded before allowlisting.

Residual: A certified or first-party server could still be compromised upstream. Accepted, monitored via MCP-03 and MCP-22 controls.

MCP-22 · Abandoned or unmaintained MCP server

STRIDE: Denial of service, Tampering · Inherent 3×4 = 12 · Residual 2×2 = 4

Internally built MCP servers outlive their owning team. Dependencies rot, certificates lapse, and nobody notices that a production agent depends on a server nobody maintains.

Mitigations

• Mandatory named service owner and a review date on every register entry; automatic expiry of the allowlist entry after 12 months without recertification.
• Remove unused MCP servers from agents - periodic review of tools with zero invocations over 90 days.
• Certificate and endpoint health monitoring with alerting into the platform operations queue.

Domain B - Tool integrity and orchestration

MCP-02 · Tool poisoning via malicious tool descriptions

STRIDE: Tampering, Elevation of privilege · Inherent 4×5 = 20 · Residual 3×3 = 9

Tool names, descriptions and parameter schemas are loaded directly into the orchestrator’s context. The protocol treats them as benign metadata; in practice they are an injection vector. Instructions concealed there can direct the agent to invoke other tools, read data it should not, or exfiltrate context. Concealment techniques including Unicode tag-block sequences have been demonstrated to render payloads invisible in approval and review UIs while remaining fully legible to the model.

Mitigations

• Preventive: Review tool names and descriptions at onboarding - but review the raw bytes, not the rendered UI. Normalise and strip non-printing Unicode (tag blocks U+E0000–U+E007F, bidi controls, zero-width characters) before human review.
• Preventive: Capture a hash of the full tool manifest at approval time and store it in the register.
• Preventive: Keep agent instructions explicit that tool descriptions and results are data, never instructions. This reduces, but does not eliminate, susceptibility.
• Detective: Diff tool manifests on a schedule (see MCP-03).
• Architectural: Constrain blast radius - an agent that has no high-privilege tool and no exfiltration channel is a poor target even if poisoned.

Residual is high by design. There is no reliable technical defence against prompt injection today. The board should treat containment (least privilege, no toxic combination of private data + untrusted content + egress) as the primary control, not detection.

MCP-03 · Rug pull / silent tool surface drift

STRIDE: Tampering, Elevation of privilege · Inherent 4×4 = 16 · Residual 2×4 = 8

MCP servers publish tools dynamically. A server approved as read-only can later add a write or delete tool, and Copilot Studio reflects the change. A maintainer who adds delete_user has effectively added it to every agent that mounted the server. Governance processes that gate connector addition but not tool surface change miss this entirely.

Mitigations

• Preventive (primary): In the agent’s MCP server settings, turn off the Allow all toggle and enable individual tools explicitly. When Allow all is off, tools newly added by the server are disabled by default. This is the single most effective control against rug pull and should be mandatory policy for every production agent.
• Preventive: Version-pin where the server supports it; require internal servers to expose a version identifier and to follow semantic versioning with change notification.
• Detective: Scheduled job that enumerates tool manifests per environment, compares against the approved hash, and raises an incident on drift.
• Process: Tool surface change is a change-management event requiring re-review, not a routine server update.

MCP-04 · Indirect prompt injection via tool return values

STRIDE: Tampering, Information disclosure, Elevation of privilege · Inherent 4×5 = 20 · Residual 2.5×4 = 10

The highest-severity pattern in production. The attacker never talks to the agent. They poison a data source the agent reads - a ticket body, a document, an email, a CRM note - and the malicious instruction arrives inside a legitimate tool’s return value. The agent, trusting its own tools, acts on it.

Mitigations

• Architectural (primary): Avoid the toxic combination. Do not give a single agent simultaneous access to (a) sensitive data, (b) content that untrusted parties can write to, and (c) an egress channel (outbound email, HTTP tool, write-capable connector). Split into separate agents with separate tool sets where the combination is unavoidable.
• Preventive: Return references, not payloads. Design internal MCP tools to return IDs and redacted views; resolve to the full record in downstream UI under the user’s own permissions.
• Preventive: Human-in-the-loop confirmation on any tool call that writes, sends, deletes or spends. See MCP-19.
• Preventive: Content fencing - wrap tool output in explicit delimiters in the tool contract and instruct the orchestrator that fenced content is untrusted data.
• Detective: Activity trace review and anomaly detection on tool-call sequences (unexpected chaining, calls to egress tools immediately following a read of externally-writable content).

MCP-05 · Cross-server context contamination and tool shadowing

STRIDE: Spoofing, Tampering · Inherent 3×4 = 12 · Residual 2×3 = 6

With multiple servers mounted on one agent, a malicious server can register a tool whose name and description closely mirror a legitimate internal tool. If the orchestrator selects the shadowed tool, sensitive input parameters go straight to the attacker’s endpoint. A malicious server can also emit descriptions that alter how the agent uses a trusted server.

Mitigations

• Limit the number of MCP servers per agent; justify each one. Multi-server agents require explicit architecture review.
• Enforce distinctive, namespaced tool naming for internal servers; reject onboarding of external servers whose tool names collide with internal ones.
• Never co-mount an unvetted external server with a server that has access to confidential data.
• Detective: alert on tool-name collisions across the approved register.

Domain C - Identity, authentication and authorisation

MCP-06 · Token passthrough anti-pattern

STRIDE: Spoofing, Elevation of privilege, Repudiation · Inherent 4×4 = 16 · Residual 2×2 = 4

An MCP server that accepts a token it was not the audience for, and forwards it to a downstream API, collapses two trust boundaries into one. Audience validation is bypassed, accountability is lost, and a credential minted for one service reaches systems it was never scoped to.

Mitigations

• Mandatory standard: internal MCP servers must validate the aud claim and reject any token not issued to them.
• Use OAuth 2.0 On-Behalf-Of / token exchange (RFC 8693) to obtain a new token scoped to the specific downstream service and user. Do not forward the inbound token.
• Configure the connector with OAuth 2.0, service principal support and Enable on-behalf-of login where the pattern supports it; prefer federated credentials (workload identity) over client secrets so no secret is persisted in the connector.
• Reject any MCP server design that requires the agent to hand over a raw PAT or bearer token belonging to another system.

Note: this is the same constraint identified in the Work IQ integration work - application-only auth being unsupported and delegated auth (Auth Code + PKCE, then OBO) being required. Treat that as the reference pattern.

MCP-07 · Confused deputy via over-privileged server identity

STRIDE: Elevation of privilege · Inherent 4×5 = 20 · Residual 2×4 = 8

The MCP server holds ambient authority - a service principal or managed identity with broad downstream scopes - and is manipulated into using it on the attacker’s behalf. A single broad service credential is a “god token” with access to every user’s downstream data. Requests appear to originate from an authenticated agent, so network defences do not fire.

There is also a specific OAuth variant: an MCP proxy using a static client ID with a third-party authorisation server, combined with dynamic client registration, can allow an attacker to reuse an existing consent cookie and receive an authorisation code with no consent screen shown.

Mitigations

• Enforce user-context authorisation end to end. The user’s token authorises the call to the MCP server; the server exchanges it for a downstream token scoped to that service and that user. Downstream systems must enforce their own permissions.
• Least privilege on the app registration: grant only the specific scopes the tools require. Avoid wildcard scopes.
• Assign only the directory roles matching the agent’s specific operations; grant admin consent narrowly at the app-registration level so consent dialogs do not silently break at runtime.
• Restrict data-layer access explicitly - e.g. define queryable columns and roles at the data access layer rather than granting table-wide reads.
• Validate on each request that the session or token belongs to the current requester; use non-deterministic session identifiers.
• Route agent traffic through a governed endpoint (APIM or equivalent) rather than exposing the MCP server directly; this also provides a policy enforcement and logging chokepoint.

MCP-08 · Shared connection identity

STRIDE: Spoofing, Elevation of privilege, Repudiation · Inherent 4×5 = 20 · Residual 2×4 = 8

This is the most commonly missed risk and it is a Power Platform inheritance, not an MCP flaw. Connections store a saved credential in the environment. Depending on how the agent is configured and shared, every end user may transit the MCP server under the connection owner’s identity. The result: users see data they have no entitlement to, and the audit trail attributes every action to one service account.

Mitigations

• Configure end-user authentication on the MCP tool so users authenticate individually and connections are established per user.
• Prohibit maker-owned or personal-account connections in production; where a shared connection is genuinely required, it must use a governed service identity with a documented, least-privilege scope and a compensating authorisation check inside the MCP server.
• Verify entitlement behaviour explicitly during test: sign in as a low-privilege user and confirm the agent cannot retrieve records that user cannot retrieve directly.
• Include connection ownership and auth mode in the pre-production review checklist.

MCP-09 · API key authentication as the only auth mode

STRIDE: Spoofing, Information disclosure · Inherent 3×4 = 12 · Residual 2×3 = 6

The onboarding wizard offers None, API key (header or query), and OAuth 2.0. API keys are a shared secret with no user identity, no granular scope, and no expiry. Keys placed in a query parameter are additionally exposed in URLs, proxy logs and referrer headers.

Mitigations

• Policy: None is prohibited in all environments. API key is prohibited in Production and permitted in Dev/Test only for non-sensitive, read-only servers, with a documented exception.
• Where API key is unavoidable, mandate header placement, never query string; enforce rotation on a defined interval; scope the key to the minimum capability.
• OAuth 2.0 is the required mode for anything touching business data.
• For dynamic client registration flows, verify the identity provider restricts redirect URIs and does not permit silent consent reuse.

MCP-10 · Over-scoped OAuth consent

STRIDE: Elevation of privilege · Inherent 3×4 = 12 · Residual 2×3 = 6

Servers that request all available permissions at initial authorisation, or scopes such as .default against a broad API surface, hand the agent far more capability than the tools need. Broad-scope tokens are then exposed to log leakage and interception.

Mitigations

• Review requested scopes at onboarding against the actual tool list; reject mismatches.
• Disable tenant-wide user consent for unverified publishers; require admin consent workflow for any new MCP app registration.
• Periodic recertification of granted scopes as part of access review.
• Prefer capability-level scoping where the downstream API supports it.

Domain D - Data protection and exfiltration

MCP-11 · Data exfiltration via tool arguments

STRIDE: Information disclosure · Inherent 4×4 = 16 · Residual 2×4 = 8

Exfiltration does not need a tool that returns data - a tool that accepts data is enough. A poisoned description can instruct the orchestrator to pass conversation context, retrieved documents or credentials into a benign-looking parameter such as a search query or a callback URL.

Mitigations

• Strict input schema validation on the server side; reject free-text parameters where an enum or ID would do.
• Prohibit tools that accept a caller-supplied URL, webhook or endpoint parameter unless the value is validated against an allowlist (also mitigates SSRF).
• Network egress control: host internal MCP servers behind Virtual Network integration with restricted outbound rules.
• Detective: log full tool invocation arguments at the governed endpoint and run DLP-style pattern detection over them.

MCP-12 · DLP and sensitivity-label blind spots on tool responses

STRIDE: Information disclosure · Inherent 4×4 = 16 · Residual 3×3 = 9

Data policies operate at connector and server granularity, not on payload content. Streamable HTTP responses can be very large and DLP scanning of the response stream is best-effort. Purview sensitivity-label enforcement and encryption support in Copilot Studio is strongest for SharePoint knowledge sources - an arbitrary MCP tool result is not equivalently covered, and labels do not automatically propagate into or out of tool payloads.

Mitigations

• Design principle: do not return raw PII or confidential content from a tool and assume DLP will catch it. Return references (record IDs, redacted views) and resolve to the full record downstream under the user’s own permissions.
• Perform classification and redaction inside the MCP server, before the response leaves it.
• Document the data classification in connector metadata so that governance review can answer “what data does this touch” without re-inspecting code.
• Apply Purview DLP and sensitivity labels to the underlying data estate so that protection is enforced at source rather than in transit.
• Use the Security Dashboard for AI (preview) for cross-product visibility of agents and MCP servers, including unmanaged ones.

Residual is High. This should be explicitly accepted by the data owner for each server handling confidential data.

MCP-13 · Data residency and cross-border transfer

STRIDE: Information disclosure · Inherent 3×5 = 15 · Residual 1×5 = 5

An external MCP endpoint may terminate anywhere. Copilot Studio’s own geographic data residency guarantees do not extend to a third party’s infrastructure. For EU-hosted operations this is a GDPR Chapter V question, not just a security one.

Mitigations

• Hosting region is a mandatory register field and a hard gate. Non-EU hosting requires a documented transfer mechanism and privacy sign-off before allowlisting.
• Disable data movement across geographic locations for Copilot Studio generative AI features where policy requires it.
• Prefer internally hosted MCP servers in the tenant’s own region behind VNet integration for anything touching personal data.
• Record the processing in the RoPA; confirm Customer Lockbox coverage expectations (note that Lockbox does not cover data emitted for Agent 365 security audit logging).

MCP-14 · Secrets and PII in telemetry, traces and transcripts

STRIDE: Information disclosure · Inherent 3×4 = 12 · Residual 2×2 = 4

Activity traces, Application Insights telemetry, conversation transcripts and MCP server logs capture tool arguments and results verbatim. Verbose server error handling can return stack traces and connection strings into the model context, and from there into a transcript.

Mitigations

• Sanitise MCP server error responses - generic messages to the caller, detail to the server’s own log.
• Telemetry sampling and redaction rules in Application Insights; treat agent telemetry as confidential and apply retention limits and RBAC accordingly.
• Never place secrets in connector custom parameters or agent instructions; use federated credentials or Key Vault references.
• Include transcript retention in the records-management schedule.

Domain E - Governance and administrative control

MCP-15 · Shadow MCP servers outside governed environments

STRIDE: Elevation of privilege, Repudiation · Inherent 4×5 = 20 · Residual 2×3 = 6

Makers create agents in the default environment, where tenant DLP is often looser and inventory is weakest. An MCP server added there is invisible to the architecture board.

Mitigations

• Default environment routing so new makers land in personal developer environments with a restrictive policy applied; treat the default environment as out of bounds for MCP.
• Apply ACP through environment groups so that policy follows environment provisioning automatically rather than being applied per environment by hand.
• Note the ACP retention behaviour: removing a rule from a group does not remove it from environments that already inherited it, and removing an environment from a group leaves the last-known configuration in place. This is deliberate (it prevents an enforcement gap) but it means decommissioning requires explicit per-environment removal or a Power Platform API sweep.
• Inventory: scheduled export of connectors, MCP servers and agents per environment into the governance dashboard; unregistered servers raise an exception.

MCP-16 · No tenant-level per-tool policy

STRIDE: Elevation of privilege · Inherent 3×4 = 12 · Residual 2×4 = 8

Advanced connector policies expose MCP servers alongside other connector types and support blocking an entire MCP server. Granular administrative control over individual MCP tools within a server is not currently available. Administratively, it is all-or-nothing at the server level.

Per-tool control does exist at the maker level inside the agent (the Allow all toggle plus individual tool toggles), but a maker can re-enable a tool. There is no admin enforcement of that choice.

Mitigations

• Compensate with server-level selection: prefer narrow, purpose-built MCP servers over broad multi-capability servers, so that server-level blocking is a usable granularity.
• Make the per-tool toggle configuration part of the deployed solution and enforce it through the ALM pipeline rather than trusting maker discipline; detect divergence in production by comparing enabled tools against the approved baseline.
• Treat any server exposing destructive tools that cannot be administratively suppressed as unsuitable for production until Microsoft delivers per-tool governance.

Residual is High and is a known platform gap. Flag for re-review each release wave.

MCP-17 · Custom connector MCP servers outside ACP scope

STRIDE: Elevation of privilege · Inherent 3×4 = 12 · Residual 2×3 = 6

ACP is built on the certified connector catalogue. Custom connectors and HTTP connectors are not yet supported by ACP. An MCP server onboarded as a custom connector therefore escapes the strongest governance rule available.

Mitigations

• Continue to run classic data policies for custom connector governance, alongside ACP in mixed mode (mixed mode merges the most restrictive settings from both at runtime).
• Use connector endpoint filtering for HTTP-based governance until ACP support lands.
• Restrict custom connector creation privileges to platform team identities; makers request rather than create.
• Track ACP custom-connector support on the roadmap watch list.

MCP-18 · Loss of attribution and insufficient audit trail

STRIDE: Repudiation · Inherent 3×4 = 12 · Residual 1.5×3 = 5

When a downstream system records only “the agent” or a shared service principal, incident reconstruction becomes guesswork. MCP telemetry is frequently thin, and logs that miss tool arguments cannot support a forensic timeline.

Mitigations

• End-to-end correlation ID propagated from conversation → agent turn → tool call → downstream request; enforce as an MCP server contract requirement.
• Log at the governed endpoint: caller identity, agent ID, tool name, arguments, response size, latency, outcome.
• Adopt Entra Agent ID so agents carry distinct directory identities, with credentials held on the agent identity blueprint rather than on individual instances - this simplifies rotation and reduces credential-theft surface.
• Use the agent activity trace during build and test to verify which tool was invoked with what arguments; use Application Insights and Purview audit for production.
• Align retention with the incident-investigation window (minimum 90 days recommended).

Domain F - Operations, resilience and cost

MCP-19 · Destructive or irreversible actions executed autonomously

STRIDE: Tampering, Denial of service · Inherent 4×5 = 20 · Residual 2×4 = 8

Generative orchestration decides autonomously which tool to call. Combined with MCP-04, a single manipulated decision becomes a real operational incident - records deleted, payments issued, messages sent externally.

Mitigations

• Classify every tool at onboarding as read / write / destructive / financial. Destructive and financial tools require explicit human-in-the-loop confirmation showing the concrete action and its parameters before execution.
• Disable write and destructive tools entirely on agents that are exposed to unauthenticated or external-facing channels.
• Idempotency keys, soft delete, and reversibility windows on internal MCP write tools.
• Rate and volume limits per session and per user on write operations.
• Pre-production adversarial testing (prompt-injection red team) is a go-live gate for any agent with a write-capable tool.

MCP-20 · Availability, latency and rate limits

STRIDE: Denial of service · Inherent 3×3 = 9 · Residual 2×2 = 4

Agents inherit the availability of every mounted server. A slow or throttled MCP server degrades the whole conversation. Data policy changes also cause runtime failure by design: resources using a blocked connector or MCP server are suspended or quarantined and fail at runtime.

Mitigations

• Timeouts and graceful degradation in agent topic design - the agent should tell the user the capability is unavailable rather than hang or hallucinate.
• SLO agreed with the MCP server owner; synthetic monitoring against the endpoint.
• Change control on data policy edits, with impact analysis of which agents depend on the affected connector before the change is applied.
• Rate limits, quotas and timeouts per session or tenant on the server side.

MCP-21 · Cost and quota abuse

STRIDE: Denial of service · Inherent 3×3 = 9 · Residual 2×2 = 4

Tool-heavy agents consume messages or Copilot Credits depending on the harness, and building, testing and evaluating agents also consume them. A prompt-injection loop or a chatty tool chain can burn budget quickly.

Mitigations

• Capacity alerting and per-environment quota allocation; separate Dev/Test capacity from Production.
• Cap tool-call iterations per conversation turn.
• Cost review as part of the onboarding gate for any high-volume MCP tool.

Domain G - Compliance and legal

MCP-23 · Terms of use, DPA and licensing exposure

Inherent 3×4 = 12 · Residual 1×4 = 4

Third-party MCP servers carry their own terms, which may assert rights over submitted content, prohibit certain uses, disclaim availability, or lack an adequate data processing agreement.

Mitigations

• Legal review of terms of use and DPA is a mandatory gate before allowlisting any external MCP server - the same gate applied to the Work IQ API terms review.
• Record contract reference, DPA status and review date in the register.
• Re-review on terms change notification and at annual recertification.

MCP-24 · Preview-feature dependency and breaking change

STRIDE: Denial of service · Inherent 3×3 = 9 · Residual 2×3 = 6

Several relevant capabilities are in preview or actively changing: MCP server certification, the Security Dashboard for AI, per-tool governance, ACP support for custom connectors, and the newer agent authoring experience and harness model. Preview features carry no SLA and can change without notice.

Mitigations

• Maintain a roadmap watch list; review each Power Platform release wave against this threat model.
• Do not make a preview capability the sole control for a Critical or High risk - always pair with a generally available compensating control.
• Version the agent solution and pin the harness/experience in the ALM pipeline so environment drift is detectable.

7. 7. Control summary - what delivers what

8. 8. MCP server onboarding gate - checklist

An MCP server is added to the allowlist only when all of the following are recorded in the register:

1. Named service owner and business sponsor
2. Purpose and the specific agents intended to consume it
3. Hosting location and hosting party; transfer mechanism if outside the EU
4. Authentication mode (None prohibited; API key Production-prohibited)
5. Downstream systems reached and the scopes requested, reviewed against the tool list
6. Full tool inventory with each tool classified read / write / destructive / financial
7. Tool manifest hash captured; raw description bytes reviewed for concealed content
8. Data classification of request and response payloads
9. Terms of use and DPA reviewed (external servers)
10. Responsible AI assessment where the server influences user-facing decisions
11. Confirmation that Allow all is off and only required tools are enabled
12. Correlation ID and logging contract confirmed
13. Adversarial/prompt-injection test evidence for any write-capable tool
14. Recertification date set (max 12 months)

9. 9. Detection and monitoring backlog

Proposed detections to add to the existing KQL cookbook:

10. 10. Open items for the board

1. Accept or reject the residual on MCP-12 and MCP-16. Both remain High. MCP-16 is a platform gap with no published Microsoft roadmap date for per-tool administrative governance; MCP-12 is inherent to how DLP interacts with streamed tool responses.
2. Confirm the prohibition on None and Production API key authentication as binding policy rather than guidance.
3. Decide whether external (non-first-party, non-certified) MCP servers are permitted in Production at all, or whether the initial posture is first-party plus internally built only.
4. Confirm ownership of the MCP register, the manifest-drift detection, and the recertification cycle.
5. Agree the adversarial testing standard for write-capable agents and who performs it.

11. 11. References

• Microsoft Learn - Connect your agent to an existing Model Context Protocol (MCP) server
• Microsoft Learn - Add tools and resources from an MCP server to your agent (per-tool toggles; data policies)
• Microsoft Learn - Advanced connector policies (MCP server management; supported connector types)
• Microsoft Learn - Data policies / Configure data policies for agents
• Microsoft Learn - Key concepts: Copilot Studio security and governance
• Microsoft Learn - Microsoft MCP server certification overview (preview)
• Microsoft Learn - Use Microsoft Purview to manage data security and compliance for Copilot Studio
• Microsoft Learn - Use Microsoft MCP Server for Enterprise from Copilot Studio
• OWASP - MCP Security Cheat Sheet
• Microsoft Copilot Blog - Introducing Model Context Protocol in Copilot Studio
• Microsoft Inside Track - Protecting AI conversations with MCP security and governance

Prepared for architecture board review. Risk ratings are initial assessments and require validation with the security and data protection functions.