Multi-provider AI control planes

Research Question

Which platforms or architectural designs provide multi-provider Artificial Intelligence (AI) control planes that unify discoverability, oversight, logging, security, data-access control, Financial Operations (FinOps), and quality of service (QoS) across Microsoft (GitHub Copilot, Microsoft 365 (M365) Copilot, Azure AI Foundry), Amazon Web Services (AWS) Bedrock and AWS Agent Core, Cursor, OpenAI Codex Command Line Interface (CLI), and Anthropic Claude Code, and what capability gaps remain unaddressed?

Findings

(Populated from §6 Synthesis above.)

Executive Summary

• No reviewed product currently provides one shared management layer for discovery, governance, logging, and routing across the named Microsoft, Amazon Web Services (AWS), and developer-tool surfaces, so enterprises still need a layered architecture that combines vendor-native administration with a cross-provider gateway or Application Programming Interface (API) management layer.
• Microsoft Foundry Control Plane documents the richest native shared-management feature set in one vendor stack, but its documented reach remains centered on Foundry-era agents and connected resources rather than GitHub Copilot, Cursor, OpenAI Codex Command Line Interface (CLI), or Anthropic Claude Code as first-class managed surfaces.
• Portkey, Kong AI Gateway, Apigee AI, and LiteLLM all document shipping multi-provider routing, logging, policy, and traffic-control features, but they do so at the gateway layer rather than by administering the native seats, tenants, and content permissions of every named copilot.
• The biggest persistent gaps are unified discoverability across all assistants, cross-platform identity and data-access enforcement, and one shared cost-control and service-quality layer that can manage both software-as-a-service copilots and runtime model traffic.

Key Findings

1. [medium] Microsoft Foundry Control Plane documents shared inventory, observability, compliance, quota, and administration for a multi-platform agent fleet, while Microsoft's broader governance guidance explicitly recommends one organizational management layer above all agents.
2. [medium] GitHub Copilot Enterprise documents policy, seat, usage, and audit control for its own surface, but GitHub's own audit documentation excludes local client session data, so it governs plan state and adoption more fully than end-to-end prompt-level runtime behavior.
3. [medium] Microsoft 365 Copilot documents native coverage for data-access policy, oversharing remediation, auditability, and adoption reporting because it sits directly on the Microsoft 365 content plane and inherits Microsoft Purview and SharePoint governance surfaces.
4. [medium] Amazon Bedrock and Bedrock Agents appear to form a robust multi-model operating layer inside AWS through model access control, guardrails, traces, permissions, and evaluation, but the current documentation does not describe them as a centralized governance layer for external coding assistants or software-as-a-service copilots.
5. [medium] Cursor, Codex, and Claude Code each ship meaningful enterprise management surfaces such as identity controls, approvals, workspace scoping, analytics, and audit exports, but each one remains scoped to its own tool family rather than to a shared enterprise layer across providers.
6. [medium] LiteLLM and Portkey each document unified provider access plus budgets, routing, fallbacks, logging, and caching, which makes them plausible multi-provider gateway options for engineering teams even though their public governance story is thinner on content entitlement and enterprise-wide identity.
7. [medium] Kong AI Gateway and Apigee AI each document provider abstraction together with quotas, analytics, observability, security policy, and operational integrations, which indicates that the enterprise API-management layer is extending into multi-provider AI governance.
8. [medium] The most persistent unaddressed gaps are a global assistant registry, one cross-platform identity and data-access layer, and one shared cost-control and service-quality layer that spans both user-facing copilots and API-level model traffic.

Assumptions

• Assumption: If a capability was not documented in current primary product material, it was treated as absent for this comparison. Justification: The task asks for publicly documented capability coverage rather than private roadmap or customer-specific functionality.
• Assumption: Product-native audit logs and analytics count as legibility and oversight even when retention windows or prompt-level depth differ materially between products. Justification: A stricter threshold would exclude most current software-as-a-service copilots from any observability comparison at all.
• Assumption: Gateway-layer token and routing controls count as cost-control and service-quality coverage even when those products do not administer seats or user entitlements. Justification: Those functions operate at the traffic layer and are still part of the requested taxonomy.

Analysis

• The native vendor products are strongest where the management layer depends on ownership of identity, content, or tenant configuration, which is why Microsoft 365 Copilot and GitHub Copilot can document richer entitlement and governance controls than the cross-provider gateways can.
• The third-party products are strongest where the management layer sits close to raw model traffic, which is why routing, retries, quotas, caching, token analytics, and fallback logic are far better documented at the gateway layer than in the software-as-a-service copilots.
• A workable enterprise design currently combines native product administration for each user-facing surface, a gateway or API-management layer for shared runtime governance, and an enterprise identity and compliance backbone above both.
• The hardest unresolved problem is not logging individual products, because most products now have some audit or analytics surface, but reconciling those incompatible logs into one enterprise-wide record with consistent retention, attribution, and policy semantics.

Risks, Gaps, and Uncertainties

• Microsoft Foundry Control Plane is still new enough that the public documentation describes broad multi-platform ambition more clearly than it documents exact support for every named external assistant.
• GitHub Copilot's audit limitation means any enterprise that needs prompt-level local activity records still needs custom hooks or external logging.
• Audit retention and export depth vary meaningfully between products, which makes direct comparability imperfect even when all of them expose some oversight features.
• Some third-party products may offer deeper enterprise features through paid plans or implementation services than their public docs show, but undocumented capabilities cannot raise the scored coverage in this comparison.

Open Questions

• Which enterprises have publicly documented a working production architecture that unifies native copilot administration with a separate multi-provider gateway and a single audit fabric?
• What minimum common event schema would allow prompt, model, tool, and cost events from different copilots to land in one normalized enterprise log?
• Which gateway product has the strongest documented story for integrating user-facing copilot events, not just inference traffic, into the same governance and cost-control plane?

sources

• [x] Microsoft Foundry Control Plane overview — - unified Microsoft control-plane surface for agent inventory, observability, compliance, quota, and administration
• [x] Microsoft guidance on governance and security for AI agents across the organization — - central control-plane guidance for AI agents
• [x] GitHub Copilot policies — - feature, privacy, and model policy controls
• [x] GitHub Copilot enterprise policies — - enterprise policy administration for Copilot, agents, and Model Context Protocol (MCP)
• [x] GitHub Copilot usage metrics — - enterprise adoption and activity telemetry
• [x] GitHub Copilot audit logs — - enterprise audit visibility and retention details
• [x] GitHub Copilot user management API — - seat and last-activity fields for licensed users
• [x] Microsoft 365 Copilot setup guide — - deployment, audit logging, oversharing controls, and admin prerequisites
• [x] Microsoft 365 Copilot security and governance — - oversharing remediation, Purview, SharePoint Advanced Management, and security controls
• [x] Microsoft Purview audit logs for Copilot and AI applications — - audit schema and retention details
• [x] Microsoft 365 Copilot usage report — - admin-center adoption and prompt reporting
• [x] Amazon Bedrock overview — - multi-model platform, supported models, and service scope
• [x] Amazon Bedrock model access — - access control, Marketplace permissions, and provider-specific prerequisites
• [x] Amazon Bedrock Guardrails — - content safety, privacy filters, groundedness, and reasoning checks
• [x] Amazon Bedrock Agents — - agent orchestration, memory, monitoring, traces, encryption, and permissions
• [x] Amazon Bedrock evaluations — - model and Retrieval-Augmented Generation (RAG) evaluation features
• [x] LiteLLM proxy quick start — - unified interface, spend tracking, budgets, and load balancing across many providers
• [x] Portkey feature overview — - multi-model gateway, guardrails, observability, and logs
• [x] Portkey gateway configs — - routing, fallbacks, caching, and configuration enforcement
• [x] Kong AI Gateway — - provider-agnostic routing, access control, analytics, prompt governance, and observability
• [x] Apigee AI solutions — - model abstraction, multicloud routing, developer portal, token reporting, and security
• [x] Apigee API Analytics overview — - analytics retention and operational monitoring
• [x] Apigee Quota policy — - request, token, and dynamic quota enforcement
• [x] Cursor identity and access management — - Single Sign-On (SSO), System for Cross-domain Identity Management (SCIM), Role-Based Access Control (RBAC), and Mobile Device Management (MDM)
• [x] Cursor model and integration management — - model controls, Bring Your Own Key (BYOK) restrictions, and Model Context Protocol (MCP) allowlists
• [x] Cursor dashboard — - billing, usage-based pricing, active sessions, and team-wide security settings
• [x] Cursor privacy and data governance — - data flows, embeddings, and privacy guarantees
• [x] Codex enterprise admin setup — - local and cloud enablement, granular access control, analytics, and policy management
• [x] Codex governance and observability — - analytics dashboard, Analytics Application Programming Interface (API), and Compliance API
• [x] Codex agent approvals and security — - sandboxing, approval policy, network controls, and web-search settings
• [x] Anthropic Administration API — - organization, workspace, key, cost, and analytics administration
• [x] Anthropic workspaces — - workspace-scoped keys, rate limits, spend notifications, and access control
• [x] Anthropic Usage and Cost API — - usage, cost, and rate-tier reporting
• [x] Anthropic Claude Code Analytics API — - per-user usage, productivity, model, and cost metrics
• [x] Anthropic audit logs — - enterprise audit export scope and retention
• [x] Enterprise AI platform operating models — - prior repository research on shared control planes for multi-platform estates
• [x] Enterprise AI capability model — - prior repository research on foundational capability reuse