Skip to content

Control 2.17: Multi-Agent Orchestration Limits

Control ID: 2.17 Pillar: Management Regulatory Reference: FINRA 2026 Annual Regulatory Oversight Report, OCC 2011-12, Fed SR 11-7, SOX 302/404 Last UI Verified: February 2026 Governance Levels: Baseline / Recommended / Regulated Last Verified: 2026-02-03

Objective

Establish governance limits and monitoring for multi-agent orchestration scenarios where agents call other agents, delegate tasks, or operate in coordinated workflows, ensuring proper oversight and reducing the risk of cascade failures.

Why This Matters for FSI

  • FINRA 2026 Annual Regulatory Oversight Report: AI governance includes oversight of agentic systems
  • OCC 2011-12: Combined model risk assessment required for interacting systems
  • Fed SR 11-7: Multi-agent systems must be validated as composite models
  • SOX 302/404: Financial controls must address automated decision chains

Control Description

This control establishes orchestration governance through design practices and custom implementation. Copilot Studio does not provide built-in platform-enforced orchestration limits; organizations must implement these governance patterns.

Expanded Multi-Agent Connectivity (as of February 2026)

Copilot Studio now supports expanded connectivity protocols for multi-agent and multi-tool orchestration:

  • Agent-to-Agent (A2A) — Google's open protocol for inter-agent communication and task delegation
  • Model Context Protocol (MCP) — Open protocol for standardized tool discovery and invocation
  • Microsoft Foundry — Native integration for orchestrating agents built in Microsoft Foundry
  • Microsoft Fabric — Direct connectivity to Fabric data agents and analytics workloads
  • 128 tool limit — Each Copilot Studio agent supports up to 128 tools (actions, connectors, plugins) per agent; plan multi-agent architectures with this constraint in mind
  • Tool Groups and Component Collections: Copilot Studio now supports Tool Groups (GA) for organizing agent capabilities and Component Collections for reusable agent building blocks, enabling standardized governance patterns across agent deployments

Feature GA Status Tracking:

Feature Status GA Date Governance Impact
Multi-Agent Orchestration GA November 2025 Full platform support for agent-to-agent delegation
MCP Server Support GA October 2025 Standardized tool discovery and invocation
Code Interpreter GA August 2025 Agent code execution requires sandbox governance

These expanded connectivity options increase the attack surface and complexity of multi-agent systems. Update orchestration governance policies to account for cross-protocol delegation chains.

Design Patterns, Not Platform Enforcement

The capabilities below are governance design patterns that organizations implement through custom logic, not built-in platform constraints. Copilot Studio does not enforce delegation depth limits, circuit breakers, or financial stop-loss controls natively.

  1. Delegation Depth Limits - Maximum levels of agent-to-agent calls (2-3 recommended) - custom orchestration logic
  2. Circuit Breaker Patterns - Automatic failsafe when cascading errors occur - custom error handling
  3. Human-in-the-Loop Triggers - Conditions requiring human review in chains - custom workflow logic
  4. Financial Stop-Loss Controls - Cumulative transaction limits across agent chains - custom business logic
  5. Orchestration Monitoring - Track multi-agent interactions for audit - Application Insights custom telemetry
  6. Combined Risk Assessment - Evaluate multi-agent systems as single models - organizational process

Key Configuration Points

Governance Policy Decisions (Organization-Defined)

  • Define maximum delegation depth per zone (Zone 1: 1, Zone 2: 2, Zone 3: 3)
  • Define circuit breaker thresholds (e.g., 3 consecutive failures)
  • Define cumulative financial limits across agent chains
  • Define HITL trigger conditions for critical actions in delegation chains
  • Schedule quarterly review of orchestration patterns

Custom Implementation Required

  • Implement delegation depth tracking in orchestration logic (custom code)
  • Implement circuit breaker pattern in agent error handling (custom Power Automate or code)
  • Implement financial stop-loss validation in transaction processing (custom business logic)
  • Enable comprehensive logging via Application Insights custom events (custom instrumentation)
  • Create combined Agent Card for multi-agent systems (documentation artifact)

Implementation Approach

These controls are enforced through custom orchestration logic (Power Automate, custom connectors, or code plugins) rather than platform configuration settings. The platform provides the capability to build agents that call other agents, but does not enforce limits on that capability.

Zone-Specific Requirements

Zone Requirement Implementation Rationale
Zone 1 (Personal) Single-agent only; no delegation allowed Design restriction (not platform-enforced) Simplicity reduces complexity risks
Zone 2 (Team) Max depth 2; circuit breaker required; logged interactions Custom orchestration logic Controlled orchestration for team use
Zone 3 (Enterprise) Max depth 3; full monitoring; HITL triggers; financial controls; combined validation Custom orchestration logic with comprehensive telemetry Customer-facing requires maximum orchestration controls

Enforcement Mechanism

These requirements are enforced through organizational design standards and custom implementation, not through platform configuration. Organizations should document orchestration patterns and validate compliance through code review and testing.

Roles & Responsibilities

Role Responsibility
AI Governance Lead Define orchestration limits, approve multi-agent patterns
Power Platform Admin Configure technical controls, monitor orchestration
Entra Security Admin Review circuit breaker events, validate controls
Compliance Officer Approve financial limits, validate regulatory alignment
Control Relationship
2.6 - Model Risk Management Multi-agent systems require combined MRM
2.12 - Supervision HITL requirements in delegation chains
1.7 - Audit Logging Orchestration events captured in audit logs
1.24 - AI-SPM Coordinator agent visibility and attack path analysis
3.4 - Incident Reporting Circuit breaker events trigger incident process

Implementation Playbooks

Step-by-Step Implementation

This control has detailed playbooks for implementation, automation, testing, and troubleshooting:

Verification Criteria

Confirm control effectiveness by verifying:

  1. Delegation depth limits enforced by custom orchestration logic (test exceeding limit is blocked)
  2. Circuit breaker pattern triggers on consecutive errors (custom implementation)
  3. Financial stop-loss controls prevent cumulative limit breach (custom business logic)
  4. HITL triggers function at configured conditions (custom workflow)
  5. Orchestration logs capture complete agent-to-agent interaction chain (Application Insights custom events)

Testing Note

These verification tests validate custom implementations, not built-in platform features. If your organization has not implemented custom orchestration controls, these tests will not be applicable.

MCP Server Governance

Model Context Protocol (MCP) servers enable cross-platform agent interoperability, allowing agents to access tools and resources from non-Microsoft platforms. This creates additional governance requirements for organizations using multi-vendor agent ecosystems.

MCP in Microsoft Ecosystem

Microsoft announced MCP server support for Copilot Studio agents at Ignite 2025. MCP enables agents to connect to external tool providers (databases, APIs, third-party AI services) through a standardized protocol. This extends agent capabilities but introduces new governance considerations.

MCP Governance Requirements

Requirement Zone 2 Zone 3 Implementation
MCP Server Approval IT approval required AI Governance Committee approval Maintain approved MCP server registry
Tool Access Review Quarterly Monthly Document which tools each agent can access via MCP
Data Flow Mapping Required Required + DLP validation Map data paths through MCP connections
Authentication Standards OAuth 2.0 minimum OAuth 2.0 + certificate pinning Validate MCP server authentication
Audit Logging Tool invocations logged Full request/response capture Configure MCP-aware logging

MCP Server Approval Workflow

Organizations should establish an approval process for MCP servers:

  1. Request Submission - Agent developer requests MCP server connection with business justification
  2. Security Assessment - Security team evaluates:
  3. MCP server vendor reputation and security posture
  4. Data classification of accessible resources
  5. Authentication and encryption standards
  6. Audit logging capabilities
  7. Compliance Review - Compliance validates:
  8. Regulatory implications of cross-platform data flow
  9. Vendor contract terms for AI usage
  10. Data residency requirements
  11. Approval Decision - AI Governance Committee (Zone 3) or IT (Zone 2) approves/denies
  12. Registration - Approved MCP servers added to organizational registry

MCP Server Risk Categories

Category Examples FSI Considerations
Internal MCP Servers Self-hosted database connectors, internal APIs Lower risk; standard internal controls apply
Vendor MCP Servers Salesforce, ServiceNow, Bloomberg connectors Evaluate vendor security; data residency; contract terms
Open Source MCP Servers Community-maintained tool providers Higher risk; requires security audit before use
AI Provider MCP Servers Claude MCP, OpenAI tool servers Model risk management applies; evaluate prompt injection risks

Cross-Platform Agent Governance

When agents interact with non-Microsoft AI platforms via MCP:

Concern Mitigation
Prompt injection via MCP Validate MCP responses before agent processing
Data leakage to external AI DLP policies must extend to MCP data flows
Audit trail gaps Ensure MCP interactions are captured in unified audit log
Model risk accumulation Combined risk assessment for multi-platform agent chains
Regulatory jurisdiction Validate data processing locations for MCP servers

MCP Monitoring and Telemetry

Extend observability to capture MCP interactions:

// Query MCP server interactions
customEvents
| where timestamp > ago(24h)
| where name == "MCP.ToolInvocation"
| extend
    mcpServer = tostring(customDimensions.mcpServer),
    toolName = tostring(customDimensions.toolName),
    agentId = tostring(customDimensions.agentId),
    dataClassification = tostring(customDimensions.dataClassification)
| summarize
    InvocationCount = count(),
    UniqueTools = dcount(toolName)
    by mcpServer, agentId
| order by InvocationCount desc

Additional Resources

Updated: February 2026 | Version: v1.2 | UI Verification Status: Current