Skip to content

Control 2.17: Multi-Agent Orchestration Limits

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

Objective

Establish governance limits and monitoring for multi-agent orchestration scenarios where agents call other agents, delegate tasks, or operate in coordinated workflows — supporting oversight and helping reduce the risk of cascade failures, unbounded delegation, and combined model risk.

Why This Matters for FSI

  • FINRA 25-07 Annual Regulatory Oversight Report: Identifies AI and agentic systems as a 2025–2026 supervisory priority; firms are expected to extend supervisory procedures (FINRA Rule 3110) and recordkeeping (FINRA Rule 4511) to multi-agent workflows
  • 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

No companion solution by design

Not all controls have a companion solution in FSI-AgentGov-Solutions; solution mapping is selective by design. This control is operated via native Microsoft admin surfaces and verified by the framework's assessment-engine collectors. See the Solutions Index for the catalog and coverage scope.

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 (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:

March 2026 Documentation Update

Human-in-the-loop approval boundaries

Microsoft Agent Framework now documents HITL workflows with request and response handling. In orchestration terms, this gives teams a standard way to pause a workflow, capture a human decision, and resume execution without losing the original request context.

Workflow capability Multi-agent governance use
RequestPort / request_info() Insert human approval before high-risk agent-to-agent delegation or tool execution
Response handler routing Bind the human decision to the correct agent step and approval request
Checkpoint persistence Resume long-running orchestrations without dropping outstanding approvals
Event streaming Export approval events to observability and supervision tooling for chain-of-custody evidence

For FSI use cases, treat human approval checkpoints as explicit orchestration boundaries for customer-impacting actions, regulated data access, or material financial decisions.

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)
  6. HITL approval checkpoints preserve request IDs and reviewer decisions for escalated orchestration steps
  7. If custom MCP servers are used, server-level and tool-level DLP/access controls are validated before production approval

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.

Custom MCP servers in Copilot Studio

Microsoft documents custom MCP servers in the 2026 Wave 1 release plan, with public preview in March 2026 and general availability targeted for April 2026. The release-plan text states that custom MCP servers provide enterprise-grade governance, including DLP policy enforcement and access controls at both the MCP server and individual tool level.

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 Validate DLP enforcement and tool-level access controls across MCP data flows, especially when the same server is reused outside Microsoft platforms
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: April 2026 | Version: v1.4.0 | UI Verification Status: Current