2026 04 26 multi ai provider control planes

Multi-provider AI control planes: capabilities, vendors, and coverage gaps

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?

Scope

In scope:

Shipping products and publicly documented architectural designs for multi-provider AI control planes
Capability coverage across each control-plane domain: discoverability, legibility and observability, oversight and audit, logging, security and identity, data-access policy, FinOps, and quality of service
Coverage mapping by provider: GitHub Copilot, M365 Copilot, Azure AI Foundry, AWS Bedrock, AWS Agent Core, Cursor, OpenAI Codex CLI, Claude Code
Gaps: capabilities absent in existing products or documented as roadmap-only

Out of scope:

General AI governance frameworks not tied to a concrete product or architecture
Model-level benchmarks or evaluation tooling not related to operational control planes
On-premises or air-gapped deployments unless also covered by a named multi-provider plane

Constraints:

Prioritise primary sources: vendor documentation, design documents, conference talks, or peer-reviewed papers; secondary summaries acceptable only if primary is unavailable
Sources must be no older than 24 months unless they represent a foundational architectural design still in active use
Focus on enterprise-grade capability, not consumer-tier tooling

Context

[fact; source: https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai-agents/governance-security-across-organization; https://cloud.google.com/solutions/apigee-ai; https://docs.konghq.com/gateway/latest/ai-gateway/] Enterprises running Artificial Intelligence (AI) systems across more than one platform must decide how to identify agents and models, observe runtime behavior, enforce policy, control data exposure, and route traffic when performance, cost, or availability changes. [inference; source: https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-22-enterprise-ai-platform-operating-models.md; https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai-agents/governance-security-across-organization; https://cloud.google.com/solutions/apigee-ai] The practical design question is whether one product can provide that control plane across Microsoft, AWS, and developer-centric tools, or whether enterprises must assemble a layered architecture from vendor-native surfaces plus a cross-provider gateway and governance stack.

Approach

Baseline capability taxonomy: define the canonical control-plane domains so coverage comparisons are like-for-like.
Vendor product survey: for each named provider, identify which control-plane capabilities are documented in official product or architecture material.
Third-party and open-source control planes: examine non-vendor gateways and API management planes that document multi-provider coverage.
Coverage gap analysis: compare provider-by-provider coverage and identify absent or weak domains.
Design review: distinguish vendor-native administration planes from genuinely cross-provider control planes.
Synthesis: identify the most complete current options, the weakest native surfaces, and the most persistent unaddressed gaps.

Sources

Research Skill Output

(Full output from running the research skill, retained verbatim in the completed item. Sections 0-5 are the investigation; section 6 seeds the Findings section below.)

§0 Initialise

Research question restated: identify the shipping products or documented designs that act as multi-provider AI control planes across the named Microsoft, AWS, and developer-tool surfaces, then identify the capability gaps they still leave open.
Scope confirmed: compare discoverability, observability, oversight, logging, security, data-access policy, FinOps, and quality-of-service coverage across native vendor surfaces and cross-provider gateways.
Constraints confirmed: use primary vendor documentation where available, use current public material, and treat undocumented capability as absent for this comparison.
Output format confirmed: a structured synthesis with explicit fact, inference, and assumption labels, plus an evidence map and gap analysis.
Prior completed repository work checked: Enterprise AI platform operating models and Enterprise AI capability model already argued for a shared control plane above vendor-specific product surfaces; the current investigation tests that claim against current product documentation.

§1 Question Decomposition

Branch A: capability taxonomy
- A1. What counts as discoverability, observability, oversight, logging, security, data-access policy, FinOps, and quality of service in this comparison?
- A2. Which of those domains require true cross-provider coordination rather than single-product administration?
Branch B: native vendor surfaces
- B1. What does Microsoft document across GitHub Copilot, M365 Copilot, and Azure AI Foundry?
- B2. What does AWS document across Bedrock and Bedrock Agents?
- B3. What do Cursor, Codex, and Claude Code document for enterprise control?
Branch C: third-party control planes
- C1. Which shipping gateways or Application Programming Interface (API) management products document multi-provider routing and governance?
- C2. Which of those products document identity, audit, cost, and policy control rather than only request forwarding?
Branch D: gap analysis
- D1. Which domains are strong only inside one vendor surface?
- D2. Which domains are strong only at the gateway layer?
- D3. Which domains remain weak across both layers?
Branch E: synthesis
- E1. Which current product is closest to a full control plane?
- E2. Which named providers have the weakest documented coverage?
- E3. Which capability gaps still require layered architecture or custom integration?

§2 Investigation

Source audit and access notes

Access note: .github/skills/research/SKILL.md absent in this environment; fallback process from research-prompt.md used.
Access note: https://help.anthropic.com/en/articles/1202276-access-audit-logs returned 404; replaced with the current official audit-log article at https://support.claude.com/en/articles/9970975-access-audit-logs.
Access note: the seeded Azure AI Foundry and GitHub Copilot landing pages were too broad for capability mapping; investigation used deeper product-control pages listed in ## Sources.
Metadata note: no failed primary-source paper, arXiv, or Digital Object Identifier (DOI) searches arose in this run because the evidence set was built from primary product documentation and prior completed repository research.

A. Baseline capability taxonomy

[inference; source: https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai-agents/governance-security-across-organization; https://cloud.google.com/solutions/apigee-ai; https://docs.konghq.com/gateway/latest/ai-gateway/] In this comparison, discoverability means a registry or inventory that tells an enterprise which agents, models, tools, or copilots exist, who owns them, and where they run.
[inference; source: https://learn.microsoft.com/en-us/azure/foundry/control-plane/overview; https://docs.github.com/en/copilot/concepts/copilot-usage-metrics/copilot-metrics; https://platform.claude.com/docs/en/build-with-claude/claude-code-analytics-api] Legibility and observability means usage, health, trace, evaluation, and adoption signals that let operators understand behavior over time.
[inference; source: https://docs.github.com/en/copilot/how-tos/administer-copilot/manage-for-enterprise/review-audit-logs; https://learn.microsoft.com/en-us/purview/audit-copilot; https://support.claude.com/en/articles/9970975-access-audit-logs] Oversight and audit means durable records for settings changes, access changes, and user or agent activity that support investigation and compliance review.
[inference; source: https://docs.konghq.com/gateway/latest/ai-gateway/; https://cloud.google.com/apigee/docs/api-platform/analytics/analytics-services-overview; https://docs.portkey.ai/docs/introduction/feature-overview] Logging means request, token, latency, or event records that can be exported into enterprise monitoring workflows.
[inference; source: https://learn.microsoft.com/en-us/microsoft-365/copilot/copilot-control-system/security-governance; https://docs.aws.amazon.com/bedrock/latest/userguide/model-access.html; https://developers.openai.com/codex/agent-approvals-security] Security and identity means policy over authentication, permissions, approval modes, network boundaries, and guardrails.
[inference; source: https://learn.microsoft.com/en-us/purview/audit-copilot; https://learn.microsoft.com/en-us/microsoft-365/copilot/copilot-control-system/security-governance; https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html] Data-access policy means controls over what content an agent or copilot can read, how sensitive data is handled, and how policy violations are surfaced.
[inference; source: https://docs.portkey.ai/docs/product/ai-gateway/configs; https://cloud.google.com/solutions/apigee-ai; https://platform.claude.com/docs/en/build-with-claude/usage-cost-api] FinOps means usage attribution, spend visibility, budget controls, and cost allocation.
[inference; source: https://docs.konghq.com/gateway/latest/ai-gateway/; https://cloud.google.com/apigee/docs/api-platform/reference/policies/quota-policy; https://docs.portkey.ai/docs/product/ai-gateway/configs] Quality of service means routing, retries, fallbacks, quotas, rate limits, latency management, and resilience controls.

B. Microsoft-native control surfaces

[fact; source: https://learn.microsoft.com/en-us/azure/foundry/control-plane/overview] Microsoft Foundry Control Plane documents a unified interface for inventory, observability, compliance, quota, and administration across an enterprise AI fleet.
[fact; source: https://learn.microsoft.com/en-us/azure/foundry/control-plane/overview] Foundry Control Plane explicitly claims multi-platform scope by supporting agents from Foundry, Microsoft, and non-Microsoft sources, while requiring an Artificial Intelligence (AI) gateway for advanced governance features.
[fact; source: https://learn.microsoft.com/en-us/azure/foundry/control-plane/overview] Foundry exposes fleet health, active agents, run completion, compliance posture, cost trends, token usage, alerts, recommendations, and policy enforcement from one role-aware interface.
[fact; source: https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai-agents/governance-security-across-organization] Microsoft's broader guidance says every AI agent should sit under a single control plane with centralized identity, unified inventory, policy enforcement, behavioral visibility, and cross-platform governance oversight.
[fact; source: https://docs.github.com/en/copilot/concepts/policies; https://docs.github.com/en/copilot/how-tos/administer-copilot/manage-for-enterprise/manage-enterprise-policies] GitHub Copilot provides enterprise and organization policy controls for features, privacy, and models, and the enterprise policy UI also exposes separate settings for agents and Model Context Protocol (MCP).
[fact; source: https://docs.github.com/en/copilot/concepts/copilot-usage-metrics/copilot-metrics; https://docs.github.com/en/rest/copilot/copilot-user-management] GitHub Copilot exposes usage metrics dashboards and APIs for adoption, engagement, code generation, and pull-request lifecycle, while seat management uses a separate user-management API with seat and last-activity fields.
[fact; source: https://docs.github.com/en/copilot/how-tos/administer-copilot/manage-for-enterprise/review-audit-logs] GitHub's enterprise audit log records settings changes, license events, and agent activity on the GitHub website, but explicitly does not include local client session data such as prompts sent to Copilot locally.
[fact; source: https://learn.microsoft.com/en-us/microsoft-365-copilot/microsoft-365-copilot-setup; https://learn.microsoft.com/en-us/microsoft-365/copilot/copilot-control-system/security-governance] Microsoft 365 Copilot documents strong tenant-side governance through conditional access, unified audit logging, Purview, SharePoint Advanced Management, and oversharing remediation controls.
[fact; source: https://learn.microsoft.com/en-us/purview/audit-copilot; https://learn.microsoft.com/en-us/microsoft-365/admin/activity-reports/microsoft-365-copilot-usage?view=o365-worldwide] Microsoft 365 Copilot also provides prompt-adjacent audit records, accessed-resource metadata, and admin-center usage reporting for enabled users, active users, prompt counts, and agent adoption.
[inference; source: https://learn.microsoft.com/en-us/azure/foundry/control-plane/overview; https://docs.github.com/en/copilot/concepts/policies; https://learn.microsoft.com/en-us/microsoft-365/copilot/copilot-control-system/security-governance] Microsoft is the only vendor in the named set that documents both strong product-native administration planes for multiple surfaces and a higher-order control-plane concept above those surfaces, but the documentation still stops short of first-class central management for external tools such as Cursor, Codex, or Claude Code.

C. AWS-native control surfaces

[fact; source: https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html; https://docs.aws.amazon.com/bedrock/latest/userguide/model-access.html] Amazon Bedrock provides managed access to models from multiple providers and documents explicit identity and subscription controls, including AWS Marketplace permissions and provider-specific prerequisites.
[fact; source: https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html] Bedrock Guardrails provide content filters, denied topics, custom word filters, sensitive-information masking, groundedness checks, and Automated Reasoning checks.
[fact; source: https://docs.aws.amazon.com/bedrock/latest/userguide/agents.html] Bedrock Agents document memory, monitoring, encryption, user permissions, Application Programming Interface (API) invocation, knowledge-base access, and trace-based troubleshooting.
[fact; source: https://docs.aws.amazon.com/bedrock/latest/userguide/evaluation.html] Bedrock evaluations cover automatic, human, and judge-model evaluation for models and Retrieval-Augmented Generation (RAG) sources, including assets outside Bedrock.
[inference; source: https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html; https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html; https://docs.aws.amazon.com/bedrock/latest/userguide/agents.html; https://docs.aws.amazon.com/bedrock/latest/userguide/evaluation.html] Bedrock is a strong multi-model operating surface inside AWS, but the documented control plane is scoped to workloads that run through Bedrock rather than to external software-as-a-service copilots or local coding assistants.

D. Developer-tool-native control surfaces

[fact; source: https://cursor.com/docs/enterprise/identity-and-access-management; https://cursor.com/docs/enterprise/model-and-integration-management; https://cursor.com/docs/account/teams/dashboard] Cursor documents enterprise controls for Single Sign-On (SSO), System for Cross-domain Identity Management (SCIM), Role-Based Access Control (RBAC), Mobile Device Management (MDM), allowed team identifiers, model access control, personal-key restrictions, Model Context Protocol (MCP) allowlists, usage-based pricing, active sessions, and admin Application Programming Interface (API) keys.
[fact; source: https://cursor.com/docs/enterprise/privacy-and-data-governance] Cursor also documents detailed data-flow behavior for indexing and embeddings, including that code is temporarily sent to create embeddings while semantic vectors and obfuscated file metadata are stored.
[fact; source: https://developers.openai.com/codex/enterprise/admin-setup; https://developers.openai.com/codex/agent-approvals-security; https://developers.openai.com/codex/enterprise/governance] OpenAI Codex documents role-based access control, local and cloud enablement toggles, managed requirements.toml policies, sandbox and approval controls, analytics dashboards, an Analytics API, and a Compliance API.
[fact; source: https://developers.openai.com/codex/enterprise/admin-setup; https://developers.openai.com/codex/agent-approvals-security] Codex local defaults to no network access and workspace-limited writes, while Codex cloud runs in isolated containers with internet disabled by default and can expose group-specific policy profiles for sandbox, approvals, web search, and MCP behavior.
[fact; source: https://platform.claude.com/docs/en/build-with-claude/administration-api; https://platform.claude.com/docs/en/build-with-claude/workspaces; https://platform.claude.com/docs/en/build-with-claude/usage-cost-api; https://platform.claude.com/docs/en/build-with-claude/claude-code-analytics-api; https://support.claude.com/en/articles/9970975-access-audit-logs] Anthropic documents an Administration API, workspace-scoped access, spend notifications, usage and cost APIs, a Claude Code analytics API, and exportable audit logs retained for 180 days.
[fact; source: https://platform.claude.com/docs/en/build-with-claude/claude-code-analytics-api] Anthropic's Claude Code analytics include sessions, lines of code added and removed, commits, pull requests, tool acceptance rates, token usage, and estimated cost by model.
[inference; source: https://cursor.com/docs/enterprise/identity-and-access-management; https://developers.openai.com/codex/enterprise/governance; https://platform.claude.com/docs/en/build-with-claude/administration-api] Cursor, Codex, and Claude Code have meaningful enterprise administration planes, but each one is a strong local plane for a single tool family rather than a shared enterprise plane that can govern the others.

E. Third-party and open-source multi-provider control planes

[fact; source: https://docs.litellm.ai/docs/proxy/quick_start] LiteLLM documents a unified interface for more than 100 Large Language Models (LLMs), spend tracking, budgets, authentication, and load balancing across multiple models and deployments.
[fact; source: https://docs.portkey.ai/docs/introduction/feature-overview; https://docs.portkey.ai/docs/product/ai-gateway/configs] Portkey documents a single gateway across more than 250 models with observability, logs, guardrails, routing, fallbacks, caching, default-config enforcement on API keys, and passthrough targets for provider selection.
[fact; source: https://docs.konghq.com/gateway/latest/ai-gateway/] Kong AI Gateway documents a provider-agnostic API, centralized credential management, dynamic routing, access tiers, usage analytics, visual traffic maps, audit logs, OpenTelemetry traces, retries, fallbacks, data governance, content safety, and cost-control plugins.
[fact; source: https://cloud.google.com/solutions/apigee-ai; https://cloud.google.com/apigee/docs/api-platform/analytics/analytics-services-overview; https://cloud.google.com/apigee/docs/api-platform/reference/policies/quota-policy] Apigee AI documents model abstraction, multicloud routing, request and response enrichment, developer-portal access, policy-based controls, token reporting, logging, internal cost reporting, custom dashboards, quota policies, and security controls including Model Armor integration.
[inference; source: https://docs.portkey.ai/docs/introduction/feature-overview; https://docs.konghq.com/gateway/latest/ai-gateway/; https://cloud.google.com/solutions/apigee-ai; https://docs.litellm.ai/docs/proxy/quick_start] These third-party products are the clearest documented multi-provider control planes in the evidence set because they normalize access across providers and expose routing, logging, and governance controls above any single model vendor.
[inference; source: https://docs.portkey.ai/docs/product/ai-gateway/configs; https://cloud.google.com/solutions/apigee-ai; https://docs.konghq.com/gateway/latest/ai-gateway/] Even the strongest gateway products are still traffic-plane centric: they govern inference calls and tool connectivity well, but they do not natively administer GitHub Copilot licenses, Microsoft 365 oversharing controls, or local coding-assistant user entitlements.

F. Gap analysis

[inference; source: https://learn.microsoft.com/en-us/azure/foundry/control-plane/overview; https://docs.github.com/en/copilot/how-tos/administer-copilot/manage-for-enterprise/review-audit-logs; https://docs.portkey.ai/docs/product/ai-gateway/configs; https://cloud.google.com/solutions/apigee-ai] The evidence splits cleanly into two layers: vendor-native administration planes govern seats, workspaces, content entitlements, and user behavior inside one product family, while cross-provider gateways govern runtime traffic, routing, and request policy across multiple model back ends.
[inference; source: https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai-agents/governance-security-across-organization; https://learn.microsoft.com/en-us/microsoft-365/copilot/copilot-control-system/security-governance; https://docs.github.com/en/copilot/concepts/policies] Discoverability and data-access policy remain strongest when the underlying vendor controls the content plane, which is why Microsoft 365 Copilot and GitHub Copilot document stronger registry and entitlement surfaces than the gateways do.
[inference; source: https://docs.konghq.com/gateway/latest/ai-gateway/; https://cloud.google.com/solutions/apigee-ai; https://docs.portkey.ai/docs/product/ai-gateway/configs; https://docs.litellm.ai/docs/proxy/quick_start] FinOps and quality-of-service control are strongest at the gateway layer because those products can observe token traffic directly and can route, retry, cache, or fail over across multiple models.
[inference; source: https://docs.github.com/en/copilot/how-tos/administer-copilot/manage-for-enterprise/review-audit-logs; https://developers.openai.com/codex/enterprise/governance; https://support.claude.com/en/articles/9970975-access-audit-logs] Oversight and audit remain fragmented because SaaS copilots and local coding assistants expose different audit granularity, retention, and export paths, and no reviewed product normalizes those records across all named surfaces.

§3 Reasoning

[inference; source: https://learn.microsoft.com/en-us/azure/foundry/control-plane/overview; https://cloud.google.com/solutions/apigee-ai; https://docs.konghq.com/gateway/latest/ai-gateway/] The central analytical distinction is between tools that administer users, inventories, and governed resources and tools that broker model traffic, because products that are broad at one layer are usually incomplete at the other.
[inference; source: https://docs.github.com/en/copilot/concepts/policies; https://learn.microsoft.com/en-us/microsoft-365/copilot/copilot-control-system/security-governance; https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html] Native product surfaces are the most credible source for identity, access, and content-policy claims because they own the underlying seats, tenants, and data entitlements.
[inference; source: https://docs.portkey.ai/docs/product/ai-gateway/configs; https://cloud.google.com/apigee/docs/api-platform/reference/policies/quota-policy; https://docs.konghq.com/gateway/latest/ai-gateway/] Gateway and API-management surfaces are the most credible source for routing, caching, retries, quotas, and cross-provider traffic normalization because they sit directly on inference requests.
[inference; source: https://learn.microsoft.com/en-us/azure/foundry/control-plane/overview; https://docs.github.com/en/copilot/how-tos/administer-copilot/manage-for-enterprise/review-audit-logs; https://support.claude.com/en/articles/9970975-access-audit-logs] A product should count as a full control plane only if it covers both management-plane and traffic-plane concerns across more than one provider surface; none of the reviewed products meet that bar end to end.

§4 Consistency Check

[fact; source: https://learn.microsoft.com/en-us/azure/foundry/control-plane/overview] Foundry Control Plane's "multi-platform" claim is internally consistent with its inventory, compliance, quota, and administration panes, but the currently documented scope is still agent-fleet centric rather than a general enterprise control plane for every named coding assistant.
[fact; source: https://docs.github.com/en/copilot/how-tos/administer-copilot/manage-for-enterprise/review-audit-logs] GitHub Copilot's audit story is internally consistent once split into enterprise settings and license events versus local prompt activity; the docs explicitly exclude local client session data from the audit log.
[fact; source: https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html; https://docs.aws.amazon.com/bedrock/latest/userguide/model-access.html; https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html] Bedrock's multi-provider claim is consistent at the model-runtime layer because it supports multiple model vendors, but that does not contradict the conclusion that Bedrock is not a full cross-tool enterprise control plane.
[fact; source: https://docs.portkey.ai/docs/introduction/feature-overview; https://docs.konghq.com/gateway/latest/ai-gateway/; https://cloud.google.com/solutions/apigee-ai] The gateway products all document strong runtime governance, and none of them claim to administer SaaS-copilot licensing or native content entitlements, so the gap analysis does not overstate their intended scope.
[inference; source: https://learn.microsoft.com/en-us/azure/foundry/control-plane/overview; https://docs.portkey.ai/docs/product/ai-gateway/configs; https://docs.github.com/en/copilot/concepts/policies] No material contradiction remains after separating management-plane capability from traffic-plane capability.

§5 Depth and Breadth Expansion

[inference; source: https://cloud.google.com/solutions/apigee-ai; https://docs.konghq.com/gateway/latest/ai-gateway/; https://docs.portkey.ai/docs/product/ai-gateway/configs] The market has already converged on a gateway pattern for cross-provider routing, retries, caching, and token accounting, which suggests those domains are standardizing faster than cross-product identity and content governance.
[inference; source: https://learn.microsoft.com/en-us/purview/audit-copilot; https://support.claude.com/en/articles/9970975-access-audit-logs; https://docs.github.com/en/copilot/how-tos/administer-copilot/manage-for-enterprise/review-audit-logs] Audit retention and export paths differ materially across products, so enterprises still need a separate evidence-retention strategy outside any one copilot or gateway.
[inference; source: https://docs.portkey.ai/docs/product/ai-gateway/configs; https://cloud.google.com/solutions/apigee-ai; https://platform.claude.com/docs/en/build-with-claude/usage-cost-api] The products with the strongest documented cost controls are the products closest to raw request flow, which reinforces the case for a shared runtime layer even when user-facing copilots remain vendor-specific.
[inference; source: https://cursor.com/docs/enterprise/model-and-integration-management; https://developers.openai.com/codex/enterprise/admin-setup; https://platform.claude.com/docs/en/build-with-claude/administration-api] Developer-tool admins can constrain model access, approvals, or workspaces, but those controls still depend on each tool's local trust boundary and do not give an enterprise one place to see every assistant and model interaction.
[inference; source: https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-22-enterprise-ai-platform-operating-models.md; https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai-agents/governance-security-across-organization; https://cloud.google.com/solutions/apigee-ai] The most realistic current architecture is a layered one: native product governance for content and entitlement, gateway governance for traffic and cost control, and a separate enterprise identity, compliance, and Security Information and Event Management (SIEM) stack above both.

§6 Synthesis

(This section seeds the Findings below.)

Executive summary:

[inference; source: https://learn.microsoft.com/en-us/azure/foundry/control-plane/overview; https://cloud.google.com/solutions/apigee-ai; https://docs.konghq.com/gateway/latest/ai-gateway/; https://docs.portkey.ai/docs/product/ai-gateway/configs; https://docs.github.com/en/copilot/concepts/policies; https://learn.microsoft.com/en-us/microsoft-365/copilot/copilot-control-system/security-governance] No reviewed product currently provides one shared management layer for discovery, governance, logging, and routing across the named Microsoft, AWS, and developer-tool surfaces, so enterprises still need a layered architecture that combines vendor-native administration with a cross-provider gateway or API-management layer.
[inference; source: https://learn.microsoft.com/en-us/azure/foundry/control-plane/overview; https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai-agents/governance-security-across-organization] 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, Codex, or Claude Code as first-class managed surfaces.
[fact; source: https://docs.portkey.ai/docs/product/ai-gateway/configs; https://docs.konghq.com/gateway/latest/ai-gateway/; https://cloud.google.com/solutions/apigee-ai; https://docs.litellm.ai/docs/proxy/quick_start] 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.
[inference; source: https://docs.github.com/en/copilot/how-tos/administer-copilot/manage-for-enterprise/review-audit-logs; https://support.claude.com/en/articles/9970975-access-audit-logs; https://learn.microsoft.com/en-us/purview/audit-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:

[medium] [fact; source: https://learn.microsoft.com/en-us/azure/foundry/control-plane/overview; https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai-agents/governance-security-across-organization] 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.
[medium] [fact; source: https://docs.github.com/en/copilot/concepts/policies; https://docs.github.com/en/copilot/concepts/copilot-usage-metrics/copilot-metrics; https://docs.github.com/en/copilot/how-tos/administer-copilot/manage-for-enterprise/review-audit-logs; https://docs.github.com/en/rest/copilot/copilot-user-management] 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.
[medium] [fact; source: https://learn.microsoft.com/en-us/microsoft-365-copilot/microsoft-365-copilot-setup; https://learn.microsoft.com/en-us/microsoft-365/copilot/copilot-control-system/security-governance; https://learn.microsoft.com/en-us/purview/audit-copilot; https://learn.microsoft.com/en-us/microsoft-365/admin/activity-reports/microsoft-365-copilot-usage?view=o365-worldwide] 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.
[medium] [inference; source: https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html; https://docs.aws.amazon.com/bedrock/latest/userguide/model-access.html; https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html; https://docs.aws.amazon.com/bedrock/latest/userguide/agents.html; https://docs.aws.amazon.com/bedrock/latest/userguide/evaluation.html] 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.
[medium] [fact; source: https://cursor.com/docs/enterprise/identity-and-access-management; https://cursor.com/docs/enterprise/model-and-integration-management; https://cursor.com/docs/account/teams/dashboard; https://developers.openai.com/codex/enterprise/admin-setup; https://developers.openai.com/codex/enterprise/governance; https://platform.claude.com/docs/en/build-with-claude/administration-api; https://platform.claude.com/docs/en/build-with-claude/claude-code-analytics-api; https://support.claude.com/en/articles/9970975-access-audit-logs] 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.
[medium] [inference; source: https://docs.litellm.ai/docs/proxy/quick_start; https://docs.portkey.ai/docs/introduction/feature-overview; https://docs.portkey.ai/docs/product/ai-gateway/configs] 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.
[medium] [inference; source: https://docs.konghq.com/gateway/latest/ai-gateway/; https://cloud.google.com/solutions/apigee-ai; https://cloud.google.com/apigee/docs/api-platform/analytics/analytics-services-overview; https://cloud.google.com/apigee/docs/api-platform/reference/policies/quota-policy] 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.
[medium] [inference; source: https://learn.microsoft.com/en-us/azure/foundry/control-plane/overview; https://docs.github.com/en/copilot/concepts/policies; https://learn.microsoft.com/en-us/microsoft-365/copilot/copilot-control-system/security-governance; https://docs.konghq.com/gateway/latest/ai-gateway/; https://cloud.google.com/solutions/apigee-ai] 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 Application Programming Interface (API) level model traffic.

Evidence map:

Claim	Source	Confidence	Notes
[fact] Microsoft Foundry Control Plane documents shared inventory, observability, compliance, quota, and administration for a multi-platform agent fleet.	https://learn.microsoft.com/en-us/azure/foundry/control-plane/overview ; https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai-agents/governance-security-across-organization	medium	Direct product documentation plus explicit central-governance guidance.
[fact] GitHub Copilot governs policies, seats, usage, and audit, but not local prompt logs.	https://docs.github.com/en/copilot/concepts/policies ; https://docs.github.com/en/copilot/concepts/copilot-usage-metrics/copilot-metrics ; https://docs.github.com/en/copilot/how-tos/administer-copilot/manage-for-enterprise/review-audit-logs ; https://docs.github.com/en/rest/copilot/copilot-user-management	medium	Audit limitation is explicit in primary docs.
[fact] Microsoft 365 Copilot documents native coverage for data-access policy, oversharing remediation, auditability, and adoption reporting.	https://learn.microsoft.com/en-us/microsoft-365-copilot/microsoft-365-copilot-setup ; https://learn.microsoft.com/en-us/microsoft-365/copilot/copilot-control-system/security-governance ; https://learn.microsoft.com/en-us/purview/audit-copilot ; https://learn.microsoft.com/en-us/microsoft-365/admin/activity-reports/microsoft-365-copilot-usage?view=o365-worldwide	medium	Strong oversharing, audit, and reporting coverage.
[inference] Bedrock appears robust inside AWS but is not documented as a cross-tool enterprise control plane.	https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html ; https://docs.aws.amazon.com/bedrock/latest/userguide/model-access.html ; https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html ; https://docs.aws.amazon.com/bedrock/latest/userguide/agents.html ; https://docs.aws.amazon.com/bedrock/latest/userguide/evaluation.html	medium	Multi-model strength does not equal multi-surface governance.
[fact] Cursor, Codex, and Claude Code each document strong single-tool management surfaces rather than one shared enterprise layer across providers.	https://cursor.com/docs/enterprise/identity-and-access-management ; https://cursor.com/docs/enterprise/model-and-integration-management ; https://developers.openai.com/codex/enterprise/admin-setup ; https://developers.openai.com/codex/enterprise/governance ; https://platform.claude.com/docs/en/build-with-claude/administration-api ; https://platform.claude.com/docs/en/build-with-claude/claude-code-analytics-api	medium	Evidence is direct from current admin and analytics docs.
[inference] LiteLLM and Portkey appear to be plausible multi-provider gateway options because they document unified provider access with budgets, routing, fallbacks, logging, and caching.	https://docs.litellm.ai/docs/proxy/quick_start ; https://docs.portkey.ai/docs/introduction/feature-overview ; https://docs.portkey.ai/docs/product/ai-gateway/configs	medium	Excellent routing and budget controls, thinner documented enterprise-governance layer.
[inference] Kong AI Gateway and Apigee AI indicate that the enterprise API-management layer is extending into multi-provider AI governance because both document provider abstraction with quotas, analytics, observability, security policy, and operational integrations.	https://docs.konghq.com/gateway/latest/ai-gateway/ ; https://cloud.google.com/solutions/apigee-ai ; https://cloud.google.com/apigee/docs/api-platform/analytics/analytics-services-overview ; https://cloud.google.com/apigee/docs/api-platform/reference/policies/quota-policy	medium	Strong documented mix of routing, analytics, quotas, and security.
[inference] Unified registry, identity, data policy, cost control, and service quality remain fragmented across the market.	https://learn.microsoft.com/en-us/azure/foundry/control-plane/overview ; https://docs.github.com/en/copilot/concepts/policies ; https://learn.microsoft.com/en-us/microsoft-365/copilot/copilot-control-system/security-governance ; https://docs.konghq.com/gateway/latest/ai-gateway/ ; https://cloud.google.com/solutions/apigee-ai	medium	Gap conclusion is synthesized across native and gateway layers.

Assumptions:

[assumption; source: https://docs.github.com/en/copilot/concepts/policies; https://docs.konghq.com/gateway/latest/ai-gateway/] 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; source: https://docs.github.com/en/copilot/how-tos/administer-copilot/manage-for-enterprise/review-audit-logs; https://support.claude.com/en/articles/9970975-access-audit-logs] Product-native audit logs and analytics were treated as evidence of legibility and oversight even when retention windows or prompt-level depth differ materially between products. Justification: a stricter threshold would exclude most current SaaS copilots from any observability comparison at all.
[assumption; source: https://cloud.google.com/solutions/apigee-ai; https://docs.portkey.ai/docs/product/ai-gateway/configs] Gateway-layer token and routing controls were treated 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:

[inference; source: https://learn.microsoft.com/en-us/azure/foundry/control-plane/overview; https://learn.microsoft.com/en-us/microsoft-365/copilot/copilot-control-system/security-governance; https://docs.github.com/en/copilot/concepts/policies] 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.
[inference; source: https://docs.portkey.ai/docs/product/ai-gateway/configs; https://docs.konghq.com/gateway/latest/ai-gateway/; https://cloud.google.com/solutions/apigee-ai] 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.
[inference; source: https://learn.microsoft.com/en-us/azure/foundry/control-plane/overview; https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html; https://developers.openai.com/codex/enterprise/governance; https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-22-enterprise-ai-platform-operating-models.md] 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.
[inference; source: https://docs.github.com/en/copilot/how-tos/administer-copilot/manage-for-enterprise/review-audit-logs; https://learn.microsoft.com/en-us/purview/audit-copilot; https://support.claude.com/en/articles/9970975-access-audit-logs] 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, uncertainties:

[fact; source: https://learn.microsoft.com/en-us/azure/foundry/control-plane/overview] 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.
[fact; source: https://docs.github.com/en/copilot/how-tos/administer-copilot/manage-for-enterprise/review-audit-logs] GitHub Copilot's audit limitation means any enterprise that needs prompt-level local activity records still needs custom hooks or external logging.
[fact; source: https://support.claude.com/en/articles/9970975-access-audit-logs; https://learn.microsoft.com/en-us/purview/audit-copilot] Audit retention and export depth vary meaningfully between products, which makes direct comparability imperfect even when all of them expose some oversight features.
[inference; source: https://docs.portkey.ai/docs/product/ai-gateway/configs; https://cloud.google.com/solutions/apigee-ai; https://docs.konghq.com/gateway/latest/ai-gateway/] 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:

[inference; source: https://learn.microsoft.com/en-us/azure/foundry/control-plane/overview; https://docs.github.com/en/copilot/concepts/policies; https://developers.openai.com/codex/enterprise/governance] 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?
[inference; source: https://learn.microsoft.com/en-us/purview/audit-copilot; https://support.claude.com/en/articles/9970975-access-audit-logs] What minimum common event schema would allow prompt, model, tool, and cost events from different copilots to land in one normalized enterprise log?
[inference; source: https://docs.portkey.ai/docs/product/ai-gateway/configs; https://cloud.google.com/solutions/apigee-ai; https://docs.konghq.com/gateway/latest/ai-gateway/] 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?

§7 Recursive Review

Acronym audit completed for Research Skill Output and Findings: Artificial Intelligence (AI), Financial Operations (FinOps), quality of service (QoS), Model Context Protocol (MCP), Application Programming Interface (API), Single Sign-On (SSO), System for Cross-domain Identity Management (SCIM), Role-Based Access Control (RBAC), Mobile Device Management (MDM), Large Language Model (LLM), Retrieval-Augmented Generation (RAG), Security Information and Event Management (SIEM), and Digital Object Identifier (DOI) are expanded on first use in those sections.
Claim-label audit completed: factual, inferential, and assumption-bearing prose in Research Skill Output and Findings is labeled inline; metadata bullets are kept as metadata.
Logic check completed: the final conclusion only claims a full control plane where both management-plane and traffic-plane coverage are documented, which prevents over-crediting strong but partial products.
Consistency check completed: no unresolved contradiction remains between native-product strengths and gateway-product strengths after separating those layers explicitly.

Findings

(Populated from §6 Synthesis above.)

Executive Summary

[inference; source: https://learn.microsoft.com/en-us/azure/foundry/control-plane/overview; https://cloud.google.com/solutions/apigee-ai; https://docs.konghq.com/gateway/latest/ai-gateway/; https://docs.portkey.ai/docs/product/ai-gateway/configs; https://docs.github.com/en/copilot/concepts/policies; https://learn.microsoft.com/en-us/microsoft-365/copilot/copilot-control-system/security-governance] 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. [inference; source: https://learn.microsoft.com/en-us/azure/foundry/control-plane/overview; https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai-agents/governance-security-across-organization] 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. [fact; source: https://docs.portkey.ai/docs/product/ai-gateway/configs; https://docs.konghq.com/gateway/latest/ai-gateway/; https://cloud.google.com/solutions/apigee-ai; https://docs.litellm.ai/docs/proxy/quick_start] 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. [inference; source: https://docs.github.com/en/copilot/how-tos/administer-copilot/manage-for-enterprise/review-audit-logs; https://support.claude.com/en/articles/9970975-access-audit-logs; https://learn.microsoft.com/en-us/purview/audit-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

[medium] [fact; source: https://learn.microsoft.com/en-us/azure/foundry/control-plane/overview; https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai-agents/governance-security-across-organization] 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.
[medium] [fact; source: https://docs.github.com/en/copilot/concepts/policies; https://docs.github.com/en/copilot/concepts/copilot-usage-metrics/copilot-metrics; https://docs.github.com/en/copilot/how-tos/administer-copilot/manage-for-enterprise/review-audit-logs; https://docs.github.com/en/rest/copilot/copilot-user-management] 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.
[medium] [fact; source: https://learn.microsoft.com/en-us/microsoft-365-copilot/microsoft-365-copilot-setup; https://learn.microsoft.com/en-us/microsoft-365/copilot/copilot-control-system/security-governance; https://learn.microsoft.com/en-us/purview/audit-copilot; https://learn.microsoft.com/en-us/microsoft-365/admin/activity-reports/microsoft-365-copilot-usage?view=o365-worldwide] 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.
[medium] [inference; source: https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html; https://docs.aws.amazon.com/bedrock/latest/userguide/model-access.html; https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html; https://docs.aws.amazon.com/bedrock/latest/userguide/agents.html; https://docs.aws.amazon.com/bedrock/latest/userguide/evaluation.html] 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.
[medium] [fact; source: https://cursor.com/docs/enterprise/identity-and-access-management; https://cursor.com/docs/enterprise/model-and-integration-management; https://cursor.com/docs/account/teams/dashboard; https://developers.openai.com/codex/enterprise/admin-setup; https://developers.openai.com/codex/enterprise/governance; https://platform.claude.com/docs/en/build-with-claude/administration-api; https://platform.claude.com/docs/en/build-with-claude/claude-code-analytics-api; https://support.claude.com/en/articles/9970975-access-audit-logs] 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.
[medium] [inference; source: https://docs.litellm.ai/docs/proxy/quick_start; https://docs.portkey.ai/docs/introduction/feature-overview; https://docs.portkey.ai/docs/product/ai-gateway/configs] 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.
[medium] [inference; source: https://docs.konghq.com/gateway/latest/ai-gateway/; https://cloud.google.com/solutions/apigee-ai; https://cloud.google.com/apigee/docs/api-platform/analytics/analytics-services-overview; https://cloud.google.com/apigee/docs/api-platform/reference/policies/quota-policy] 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.
[medium] [inference; source: https://learn.microsoft.com/en-us/azure/foundry/control-plane/overview; https://docs.github.com/en/copilot/concepts/policies; https://learn.microsoft.com/en-us/microsoft-365/copilot/copilot-control-system/security-governance; https://docs.konghq.com/gateway/latest/ai-gateway/; https://cloud.google.com/solutions/apigee-ai] 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.

Evidence Map

Claim	Source	Confidence	Notes
[fact] Microsoft Foundry Control Plane documents shared inventory, observability, compliance, quota, and administration for a multi-platform agent fleet.	https://learn.microsoft.com/en-us/azure/foundry/control-plane/overview ; https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai-agents/governance-security-across-organization	medium	Direct product documentation plus explicit central-governance guidance.
[fact] GitHub Copilot governs policies, seats, usage, and audit, but not local prompt logs.	https://docs.github.com/en/copilot/concepts/policies ; https://docs.github.com/en/copilot/concepts/copilot-usage-metrics/copilot-metrics ; https://docs.github.com/en/copilot/how-tos/administer-copilot/manage-for-enterprise/review-audit-logs ; https://docs.github.com/en/rest/copilot/copilot-user-management	medium	Audit limitation is explicit in primary docs.
[fact] Microsoft 365 Copilot documents native coverage for data-access policy, oversharing remediation, auditability, and adoption reporting.	https://learn.microsoft.com/en-us/microsoft-365-copilot/microsoft-365-copilot-setup ; https://learn.microsoft.com/en-us/microsoft-365/copilot/copilot-control-system/security-governance ; https://learn.microsoft.com/en-us/purview/audit-copilot ; https://learn.microsoft.com/en-us/microsoft-365/admin/activity-reports/microsoft-365-copilot-usage?view=o365-worldwide	medium	Strong oversharing, audit, and reporting coverage.
[inference] Bedrock appears robust inside AWS but is not documented as a cross-tool enterprise control plane.	https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html ; https://docs.aws.amazon.com/bedrock/latest/userguide/model-access.html ; https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html ; https://docs.aws.amazon.com/bedrock/latest/userguide/agents.html ; https://docs.aws.amazon.com/bedrock/latest/userguide/evaluation.html	medium	Multi-model strength does not equal multi-surface governance.
[fact] Cursor, Codex, and Claude Code each document strong single-tool management surfaces rather than one shared enterprise layer across providers.	https://cursor.com/docs/enterprise/identity-and-access-management ; https://cursor.com/docs/enterprise/model-and-integration-management ; https://developers.openai.com/codex/enterprise/admin-setup ; https://developers.openai.com/codex/enterprise/governance ; https://platform.claude.com/docs/en/build-with-claude/administration-api ; https://platform.claude.com/docs/en/build-with-claude/claude-code-analytics-api	medium	Evidence is direct from current admin and analytics docs.
[inference] LiteLLM and Portkey appear to be plausible multi-provider gateway options because they document unified provider access with budgets, routing, fallbacks, logging, and caching.	https://docs.litellm.ai/docs/proxy/quick_start ; https://docs.portkey.ai/docs/introduction/feature-overview ; https://docs.portkey.ai/docs/product/ai-gateway/configs	medium	Excellent routing and budget controls, thinner documented enterprise-governance layer.
[inference] Kong AI Gateway and Apigee AI indicate that the enterprise API-management layer is extending into multi-provider AI governance because both document provider abstraction with quotas, analytics, observability, security policy, and operational integrations.	https://docs.konghq.com/gateway/latest/ai-gateway/ ; https://cloud.google.com/solutions/apigee-ai ; https://cloud.google.com/apigee/docs/api-platform/analytics/analytics-services-overview ; https://cloud.google.com/apigee/docs/api-platform/reference/policies/quota-policy	medium	Strong documented mix of routing, analytics, quotas, and security.
[inference] Unified registry, identity, data policy, cost control, and service quality remain fragmented across the market.	https://learn.microsoft.com/en-us/azure/foundry/control-plane/overview ; https://docs.github.com/en/copilot/concepts/policies ; https://learn.microsoft.com/en-us/microsoft-365/copilot/copilot-control-system/security-governance ; https://docs.konghq.com/gateway/latest/ai-gateway/ ; https://cloud.google.com/solutions/apigee-ai	medium	Gap conclusion is synthesized across native and gateway layers.

Assumptions

[assumption; source: https://docs.github.com/en/copilot/concepts/policies; https://docs.konghq.com/gateway/latest/ai-gateway/] 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; source: https://docs.github.com/en/copilot/how-tos/administer-copilot/manage-for-enterprise/review-audit-logs; https://support.claude.com/en/articles/9970975-access-audit-logs] 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; source: https://cloud.google.com/solutions/apigee-ai; https://docs.portkey.ai/docs/product/ai-gateway/configs] 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

[inference; source: https://learn.microsoft.com/en-us/azure/foundry/control-plane/overview; https://learn.microsoft.com/en-us/microsoft-365/copilot/copilot-control-system/security-governance; https://docs.github.com/en/copilot/concepts/policies] 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. [inference; source: https://docs.portkey.ai/docs/product/ai-gateway/configs; https://docs.konghq.com/gateway/latest/ai-gateway/; https://cloud.google.com/solutions/apigee-ai] 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. [inference; source: https://learn.microsoft.com/en-us/azure/foundry/control-plane/overview; https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html; https://developers.openai.com/codex/enterprise/governance; https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-22-enterprise-ai-platform-operating-models.md] 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. [inference; source: https://docs.github.com/en/copilot/how-tos/administer-copilot/manage-for-enterprise/review-audit-logs; https://learn.microsoft.com/en-us/purview/audit-copilot; https://support.claude.com/en/articles/9970975-access-audit-logs] 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

[fact; source: https://learn.microsoft.com/en-us/azure/foundry/control-plane/overview] 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.
[fact; source: https://docs.github.com/en/copilot/how-tos/administer-copilot/manage-for-enterprise/review-audit-logs] GitHub Copilot's audit limitation means any enterprise that needs prompt-level local activity records still needs custom hooks or external logging.
[fact; source: https://support.claude.com/en/articles/9970975-access-audit-logs; https://learn.microsoft.com/en-us/purview/audit-copilot] Audit retention and export depth vary meaningfully between products, which makes direct comparability imperfect even when all of them expose some oversight features.
[inference; source: https://docs.portkey.ai/docs/product/ai-gateway/configs; https://cloud.google.com/solutions/apigee-ai; https://docs.konghq.com/gateway/latest/ai-gateway/] 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

[inference; source: https://learn.microsoft.com/en-us/azure/foundry/control-plane/overview; https://docs.github.com/en/copilot/concepts/policies; https://developers.openai.com/codex/enterprise/governance] 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?
[inference; source: https://learn.microsoft.com/en-us/purview/audit-copilot; https://support.claude.com/en/articles/9970975-access-audit-logs] What minimum common event schema would allow prompt, model, tool, and cost events from different copilots to land in one normalized enterprise log?
[inference; source: https://docs.portkey.ai/docs/product/ai-gateway/configs; https://cloud.google.com/solutions/apigee-ai; https://docs.konghq.com/gateway/latest/ai-gateway/] 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?