Add outbound MCP via Actions with Semantic Kernel plugin and admin governance for MCP server access

[paullizer]

We need to enable outbound Model Context Protocol connections through Actions using a Semantic Kernel plugin. This allows agents to call external MCP servers as tools. Because this introduces external network dependencies and potential data egress, we must include an explicit governance model so administrators can control which MCP servers are permitted.

This issue proposes adding outbound MCP support plus an admin controlled allow and deny list for MCP server fully qualified domain names.

Motivation
Agents and plugins increasingly rely on external MCP servers for tool execution. Without governance controls, this creates security and compliance risks in enterprise and regulated environments. We need a first class model that enables outbound MCP while giving admins centralized control over allowed endpoints.

Scope

• Outbound MCP connectivity initiated through Actions
• Semantic Kernel plugin that wraps MCP client functionality
• Admin governance model for MCP server FQDN control
• Configuration surfaced in admin or control plane settings

Functional Requirements

1. Outbound MCP via Actions

• Actions framework can invoke MCP servers as external tools
• Requests flow through a Semantic Kernel plugin that manages MCP client lifecycle
• Support standard MCP transports as defined in MCP spec

2. Semantic Kernel MCP plugin

• Provide a reusable SK plugin abstraction for MCP tool invocation
• Plugin supports dynamic registration of MCP servers
• Plugin integrates with existing agent execution pipeline

3. Governance model for MCP servers

• Admins can define an allow list of MCP server FQDNs
• Admins can define a deny list of MCP server FQDNs
• Deny list takes precedence over allow list
• If allow list is defined, only listed FQDNs are permitted
• If allow list is empty, default behavior must be explicitly defined
• Changes take effect without service restart

4. Enforcement

• All outbound MCP requests validate target FQDN against governance rules
• Blocked requests return a clear error message to the caller
• Governance checks occur before any network connection is attempted

5. Audit and observability

• Log MCP action create to activity log
• Log assigning MCP action to agent to activity log
• Log blocked MCP server connections to activity log
• Allowed MCP server connections are part of the conversation history, I dont think we need to log successful connections in activity log

6. Configuration surface

• UI to configure MCP action
• Admin UI or config API for managing allow and deny lists
• Support environment specific configuration
• Configuration stored in existing settings framework

Acceptance Criteria

• Agents can successfully call an approved MCP server via Actions
• Calls to non approved MCP servers are blocked
• Admin can update allow or deny lists and changes apply immediately
• Logs show governance decision for each MCP connection attempt
• No outbound MCP traffic bypasses governance layer

Open Questions

• Should default behavior allow all if allow list is empty, or deny all until explicitly allowed
• Should wildcard domains be supported
• Do we need per workspace or per tenant scoping for the governance rules