Enterprise API Marketplace and GovernanceMarketplace Corporativo de APIs e GovernançaMarketplace Corporativo de APIs y Gobernanza
A unified control plane for governing APIs, VS Code extensions, MCP servers, and Copilot agents — from inventory and linting to policy enforcement and air-gapped deployment.Um plano de controle unificado para governar APIs, extensões VS Code, servidores MCP e agentes Copilot — do inventário e linting à aplicação de políticas e deploy air-gapped.Un plano de control unificado para gobernar APIs, extensiones VS Code, servidores MCP y agentes Copilot — desde el inventario y el linting hasta la aplicación de políticas y el deploy air-gapped.
The problem: sprawl without a control plane
Enterprise development environments accumulate risk in three compounding categories, and most organizations have no single surface from which to address all three at once.
Security is the first pressure point. Extensions and MCP servers installed ad hoc — outside any approval process — may exfiltrate code or credentials. The IDE becomes the soft target: it sits inside the perimeter, has deep access to the filesystem and network, and is rarely covered by the same threat model as production infrastructure.
Compliance is the second. Sensitive data reaches AI model APIs without authorization. Audit teams cannot prove what left the environment, when it left, or to whom it was sent. As AI-assisted development becomes standard, the compliance gap widens faster than manual governance can close it.
Productivity is the third — and often the least intuitive risk. When developers cannot discover what APIs exist, they rebuild. They reach for deprecated endpoints. They burn hours configuring tooling that already exists somewhere in the organization. Shadow APIs proliferate. The cost of duplication compounds quietly.
These three risks are not independent. Unvetted tooling drives shadow API usage. Shadow API usage produces data-flow gaps. Data-flow gaps create compliance exposure. A control plane that addresses only one category leaves the other two open.
Architecture: three hubs, one workstation
The integrated architecture closes all three loops through three specialized hubs that converge on a single developer workstation — VS Code (Desktop) with GitHub Copilot — protected by a shared policy layer enforcing AllowedExtensions, RBAC, identity, and audit logging.
Hub 01 — Azure API Center is the authoritative inventory for every API in the organization. Every version, every definition, every environment and deployment is registered here. CLI and CI/CD pipelines feed registration automatically. Custom metadata fields capture ownership and classification, making the catalog both a discovery surface and a governance record. Spectral linting rules run at registration time, blocking APIs that violate organizational design standards before they ship. Dev Proxy discovery surfaces undocumented APIs that developers are already calling, bringing shadow APIs into the catalog before they accumulate as production debt. Azure API Management feeds the catalog upstream automatically: gateway truth and inventory truth converge into one record.
Hub 02 — VS Code Private Marketplace gives enterprises a curated extension catalog under their own control. The architecture is intentionally stateless: a container with object storage backing that can be deployed in any region, serving internal extensions and rehosted public ones. Air-gap deployments keep developers productive without any network egress to the public marketplace. Policy enforcement uses Group Policy on Windows and Intune on macOS and managed devices. A bootstrap install ensures that every developer opens a curated VS Code on day one — not a raw, unmanaged installation.
Hub 03 — Copilot Governance extends the same design principle to AI artifacts. MCP servers are registered in .vscode/mcp.json and distributed through the marketplace, with a documented trust model per server. Copilot extensions are reviewed for data flow and allowlisted at the GitHub Enterprise organization level. Custom agents live in .github/agents/ files, version-controlled alongside the code they govern and reviewed in the same PR pipeline. Prompt files and skills are curated in a shared repository with an approval workflow before they reach the developer fleet.
The policy layer sits across all three hubs. Nothing reaches the developer workstation unvetted.
Deployment scenarios
The same architecture supports three deployment shapes, making it applicable across cloud-connected enterprises, restricted networks, and regulated industries.
| Scenario | Context | Key characteristics |
|---|---|---|
| A · Full integrated | Cloud-connected enterprise | API design in VS Code, registered to API Center, synced to APIM, consumed from the IDE. Marketplace and Copilot fully online. |
| B · Air-gapped | No public network egress | Marketplace rehosts public extensions on internal storage. MCP servers run on internal endpoints. Copilot Enterprise on private link. |
| C · Regulated | Finance, public sector | Audit log retention, classification labels, signed artifacts, identity propagation per request. Auditor independent from platform. |
The regulated scenario adds depth to the compliance posture: audit log retention, classification labels on artifacts, signed binaries, and per-request identity propagation ensure that every action is attributable and every artifact is traceable.
From Day 0 to Day 2
The operational sequence follows a clear progression. Day 0 establishes the platform: API Center provisioned, Private Marketplace deployed, Copilot governance policies configured, identity and RBAC wired up. Day 1 onboards the developer fleet: bootstrap installs distribute curated VS Code instances, API registrations flow through CI/CD, MCP server trust models are documented. Day 2 is steady-state operations: linting blocks non-compliant APIs at the gate, Dev Proxy surfaces shadow APIs before they reach production, audit logs give compliance teams continuous visibility.
The design principle
The three hubs share one design principle: each artifact category — APIs, extensions, AI tools — gets its own governance contract, but all contracts are enforced through the same control plane. The artifacts change. The contract does not.
Governance built this way is not a compliance layer bolted onto an existing development environment. It is the platform. Build it once, and every new artifact category — whatever comes after MCP servers and Copilot agents — inherits the same enforcement surface automatically.
O problema: dispersão sem plano de controle
Ambientes corporativos de desenvolvimento acumulam risco em três categorias que se compõem, e a maioria das organizações não tem uma superfície única a partir da qual endereçar as três ao mesmo tempo.
Segurança é o primeiro ponto de pressão. Extensões e servidores MCP instalados ad hoc — fora de qualquer processo de aprovação — podem exfiltrar código ou credenciais. O IDE vira o alvo fácil: está dentro do perímetro, tem acesso profundo ao sistema de arquivos e à rede, e raramente é coberto pelo mesmo modelo de ameaça que a infraestrutura de produção.
Compliance é o segundo. Dado sensível chega às APIs de modelo IA sem autorização. A auditoria não consegue provar o que saiu do ambiente, quando saiu ou para quem foi enviado. À medida que o desenvolvimento assistido por IA se torna padrão, a lacuna de compliance se alarga mais rápido do que a governança manual consegue fechar.
Produtividade é o terceiro — e muitas vezes o risco menos intuitivo. Quando o dev não descobre o que existe, ele reconstrói. Usa endpoints depreciados. Queima horas configurando ferramentas que já existem em algum lugar da organização. Shadow APIs proliferam. O custo da duplicação cresce silenciosamente.
Os três riscos não são independentes. Tooling sem vetting impulsiona o uso de shadow APIs. O uso de shadow APIs produz lacunas de fluxo de dados. Lacunas de fluxo de dados geram exposição de compliance. Um plano de controle que endereça apenas uma categoria deixa as outras duas abertas.
Arquitetura: três hubs, uma workstation
A arquitetura integrada fecha todos os três ciclos por meio de três hubs especializados que convergem para uma única workstation de desenvolvimento — VS Code (Desktop) com GitHub Copilot — protegida por uma camada de política compartilhada aplicando AllowedExtensions, RBAC, identidade e log de auditoria.
Hub 01 — Azure API Center é o inventário autoritativo para cada API da organização. Cada versão, cada definição, cada ambiente e deployment é registrado aqui. Pipelines de CLI e CI/CD alimentam o registro automaticamente. Campos de metadata customizada capturam ownership e classificação, tornando o catálogo tanto uma superfície de descoberta quanto um registro de governança. Regras Spectral de linting executam no momento do registro, bloqueando APIs que violam padrões organizacionais antes do deploy. A descoberta via Dev Proxy traz à superfície APIs não documentadas que os devs já estão chamando, incorporando shadow APIs ao catálogo antes que acumulem dívida em produção. O Azure API Management alimenta o catálogo upstream automaticamente: verdade do gateway e verdade do inventário convergem em um único registro.
Hub 02 — VS Code Private Marketplace oferece às empresas um catálogo curado de extensões sob seu próprio controle. A arquitetura é intencionalmente stateless: um container com object storage de apoio que pode ser implantado em qualquer região, servindo extensões internas e extensões públicas rehosted. Deploys air-gap mantêm os devs produtivos sem qualquer egress para o marketplace público. A aplicação de políticas usa Group Policy no Windows e Intune em macOS e dispositivos gerenciados. Um bootstrap install garante que todo desenvolvedor abra um VS Code curado no primeiro dia — e não uma instalação bruta, não gerenciada.
Hub 03 — Governança Copilot estende o mesmo princípio de design para artefatos de IA. Servidores MCP são registrados em .vscode/mcp.json e distribuídos pelo marketplace, com modelo de confiança documentado por servidor. Extensões Copilot são revisadas quanto ao fluxo de dados e adicionadas à allowlist no nível da organização GitHub Enterprise. Agentes customizados vivem em arquivos .github/agents/, versionados junto ao código que governam e revisados no mesmo pipeline de PR. Prompts e skills são curados em um repositório compartilhado com workflow de aprovação antes de chegarem à frota de desenvolvimento.
A camada de política abrange os três hubs. Nada chega à workstation do dev sem passar pelo processo de vetting.
Cenários de deploy
A mesma arquitetura suporta três formatos de deploy, tornando-a aplicável em empresas conectadas à nuvem, redes restritas e setores regulados.
| Cenário | Contexto | Características principais |
|---|---|---|
| A · Integrado completo | Empresa conectada à nuvem | Design de API no VS Code, registrado no API Center, sync para APIM, consumido no IDE. Marketplace e Copilot online. |
| B · Air-gapped | Sem egress público | Marketplace rehosting extensões públicas em storage interno. Servidores MCP em endpoints internos. Copilot Enterprise via private link. |
| C · Regulado | Financeiro, setor público | Retenção de log de auditoria, rótulos de classificação, artefatos assinados, propagação de identidade por request. Auditor independente. |
O cenário regulado adiciona profundidade à postura de compliance: retenção de log de auditoria, rótulos de classificação em artefatos, binários assinados e propagação de identidade por request garantem que toda ação seja atribuível e todo artefato seja rastreável.
Do Dia 0 ao Dia 2
A sequência operacional segue uma progressão clara. O Dia 0 estabelece a plataforma: API Center provisionado, Private Marketplace implantado, políticas de governança Copilot configuradas, identidade e RBAC conectados. O Dia 1 faz o onboarding da frota de desenvolvimento: bootstrap installs distribuem instâncias de VS Code curadas, registros de APIs fluem via CI/CD, modelos de confiança de servidores MCP são documentados. O Dia 2 é a operação em estado estável: linting bloqueia APIs não conformes no portão, Dev Proxy traz shadow APIs à superfície antes de chegarem à produção, logs de auditoria dão aos times de compliance visibilidade contínua.
O princípio de design
Os três hubs compartilham um princípio de design: cada categoria de artefato — APIs, extensões, ferramentas de IA — recebe seu próprio contrato de governança, mas todos os contratos são aplicados pelo mesmo plano de controle. Os artefatos mudam. O contrato não.
Governança construída dessa forma não é uma camada de compliance colada sobre um ambiente de desenvolvimento existente. É a plataforma. Construa uma vez, e toda nova categoria de artefato — o que vier depois de servidores MCP e agentes Copilot — herda automaticamente a mesma superfície de aplicação.
El problema: dispersión sin plano de control
Los entornos de desarrollo empresariales acumulan riesgo en tres categorías que se componen, y la mayoría de las organizaciones no tienen una superficie única desde la cual abordar las tres al mismo tiempo.
Seguridad es el primer punto de presión. Las extensiones y servidores MCP instalados ad hoc — fuera de cualquier proceso de aprobación — pueden exfiltrar código o credenciales. El IDE se vuelve el blanco fácil: está dentro del perímetro, tiene acceso profundo al sistema de archivos y a la red, y rara vez está cubierto por el mismo modelo de amenaza que la infraestructura de producción.
Cumplimiento es el segundo. Datos sensibles llegan a las APIs de modelo IA sin autorización. Los equipos de auditoría no pueden probar qué salió del entorno, cuándo salió ni a quién fue enviado. A medida que el desarrollo asistido por IA se convierte en estándar, la brecha de cumplimiento se amplía más rápido de lo que la gobernanza manual puede cerrarla.
Productividad es el tercero — y con frecuencia el riesgo menos intuitivo. Cuando el dev no descubre lo que existe, reconstruye. Usa endpoints deprecados. Quema horas configurando tooling que ya existe en algún lugar de la organización. Las shadow APIs proliferan. El costo de la duplicación crece silenciosamente.
Los tres riesgos no son independientes. El tooling sin revisión impulsa el uso de shadow APIs. El uso de shadow APIs produce brechas en el flujo de datos. Las brechas en el flujo de datos generan exposición de cumplimiento. Un plano de control que aborda solo una categoría deja las otras dos abiertas.
Arquitectura: tres hubs, una estación de trabajo
La arquitectura integrada cierra los tres ciclos a través de tres hubs especializados que convergen en una única estación de trabajo de desarrollo — VS Code (Desktop) con GitHub Copilot — protegida por una capa de política compartida que aplica AllowedExtensions, RBAC, identidad y log de auditoría.
Hub 01 — Azure API Center es el inventario autoritativo para cada API de la organización. Cada versión, cada definición, cada entorno y deployment se registra aquí. Los pipelines de CLI y CI/CD alimentan el registro automáticamente. Los campos de metadata personalizada capturan la propiedad y la clasificación, convirtiendo el catálogo tanto en una superficie de descubrimiento como en un registro de gobernanza. Las reglas de linting Spectral se ejecutan en el momento del registro, bloqueando APIs que violan estándares organizacionales antes del deploy. El descubrimiento vía Dev Proxy detecta APIs no documentadas que los devs ya están llamando, incorporando las shadow APIs al catálogo antes de que acumulen deuda en producción. Azure API Management alimenta el catálogo upstream automáticamente: la verdad del gateway y la del inventario convergen en un único registro.
Hub 02 — VS Code Private Marketplace ofrece a las empresas un catálogo curado de extensiones bajo su propio control. La arquitectura es intencionalmente sin estado: un contenedor con object storage de respaldo que puede desplegarse en cualquier región, sirviendo extensiones internas y extensiones públicas rehospedadas. Los despliegues air-gap mantienen a los devs productivos sin ningún egress al marketplace público. La aplicación de políticas usa Group Policy en Windows e Intune en macOS y dispositivos gestionados. Un bootstrap install asegura que cada desarrollador abra un VS Code curado desde el primer día — no una instalación bruta y no gestionada.
Hub 03 — Gobernanza Copilot extiende el mismo principio de diseño a los artefactos de IA. Los servidores MCP se registran en .vscode/mcp.json y se distribuyen a través del marketplace, con un modelo de confianza documentado por servidor. Las extensiones Copilot se revisan por flujo de datos y se agregan a la allowlist a nivel de la organización GitHub Enterprise. Los agentes custom viven en archivos .github/agents/, versionados junto al código que gobiernan y revisados en el mismo pipeline de PR. Los prompts y skills se curan en un repositorio compartido con workflow de aprobación antes de llegar a la flota de desarrollo.
La capa de política abarca los tres hubs. Nada llega a la estación de trabajo del dev sin pasar por la revisión.
Escenarios de despliegue
La misma arquitectura soporta tres formatos de deploy, haciéndola aplicable en empresas conectadas a la nube, redes restringidas e industrias reguladas.
| Escenario | Contexto | Características principales |
|---|---|---|
| A · Integrado completo | Empresa conectada a la nube | Diseño de API en VS Code, registrado en API Center, sync a APIM, consumido desde el IDE. Marketplace y Copilot online. |
| B · Air-gapped | Sin egress público | El marketplace rehospeda extensiones públicas en almacenamiento interno. Servidores MCP en endpoints internos. Copilot Enterprise vía private link. |
| C · Regulado | Finanzas, sector público | Retención de log de auditoría, etiquetas de clasificación, artefactos firmados, propagación de identidad por request. Auditor independiente. |
El escenario regulado añade profundidad a la postura de cumplimiento: retención de log de auditoría, etiquetas de clasificación en artefactos, binarios firmados y propagación de identidad por request garantizan que cada acción sea atribuible y cada artefacto sea trazable.
Del Día 0 al Día 2
La secuencia operacional sigue una progresión clara. El Día 0 establece la plataforma: API Center aprovisionado, Private Marketplace desplegado, políticas de gobernanza Copilot configuradas, identidad y RBAC conectados. El Día 1 hace el onboarding de la flota de desarrollo: los bootstrap installs distribuyen instancias de VS Code curadas, los registros de APIs fluyen vía CI/CD, los modelos de confianza de servidores MCP quedan documentados. El Día 2 es la operación en estado estable: el linting bloquea APIs no conformes en la puerta, Dev Proxy trae las shadow APIs a la superficie antes de que lleguen a producción, los logs de auditoría dan a los equipos de cumplimiento visibilidad continua.
El principio de diseño
Los tres hubs comparten un principio de diseño: cada categoría de artefacto — APIs, extensiones, herramientas de IA — recibe su propio contrato de gobernanza, pero todos los contratos se aplican a través del mismo plano de control. Los artefactos cambian. El contrato no.
La gobernanza construida de esta forma no es una capa de cumplimiento añadida sobre un entorno de desarrollo existente. Es la plataforma. Constrúyela una vez, y cada nueva categoría de artefacto — lo que venga después de los servidores MCP y los agentes Copilot — hereda automáticamente la misma superficie de aplicación.
Start with the platform, not the agents. Comece pela plataforma, não pelos agentes. Comience por la plataforma, no por los agentes.
Building the future of software development with AI and Agentic DevOps.