Control plane de IA: APIM, seguridad y escalado real en Azure

Introducción

En la primera parte hemos dejado claro algo fundamental:

MCP no es tu arquitectura. Es un adaptador.

Pero eso abre una pregunta crítica:

¿Qué controla realmente lo que un agente puede hacer cuando usa MCP?

Porque aquí cambia el paradigma.

Ya no hablamos de:

  • APIs invocadas por humanos
  • o sistemas integrándose de forma explícita

Ahora hablamos de:

un modelo tomando decisiones y ejecutando capacidades reales en tu sistema

Y eso tiene implicaciones directas en:

  • seguridad
  • gobierno
  • coste
  • escalabilidad

La respuesta en Azure es clara:

API Management como AI Gateway (control plane)

1. El problema real: MCP sin control es una superficie de ataque

Cuando expones MCP, estás exponiendo:

  • tools ejecutables
  • acceso a datos
  • operaciones reales

Pero además introduces un intermediario:

Usuario → LLM → decide → ejecuta tool → sistema

Esto genera nuevos riesgos:

1. Prompt Injection

El modelo recibe instrucciones maliciosas y ejecuta acciones no deseadas.

2. Tool Misuse

Uso indebido de tools válidas pero fuera de contexto.

3. Data Exfiltration

Extracción de datos vía tools.

4. Cost Explosion

Uso descontrolado de tokens o ejecución de operaciones costosas.

Insight clave

MCP convierte un problema de input en un problema de ejecución distribuida.

2. APIM como AI Gateway (control plane de IA)

Microsoft introduce explícitamente este concepto:

https://learn.microsoft.com/en-us/azure/api-management/genai-gateway-capabilities

APIM deja de ser solo un API Gateway y pasa a ser:

un punto de control para modelos, agentes y MCP servers

3. Qué aporta realmente APIM en escenarios MCP

No es solo “poner un gateway delante”.

3.1 Control de acceso y autenticación

  • integración con Entra ID
  • OAuth para agentes
  • control por consumidor

Sin esto:

  • cualquiera puede invocar tools
  • no hay trazabilidad real

3.3 Control de tokens (FinOps real)

En sistemas clásicos:

  • controlas requests

En IA:

  • controlas tokens

APIM permite:

  • limitar tokens por usuario
  • cortar ejecuciones antes de coste
  • medir consumo real

https://learn.microsoft.com/en-us/azure/api-management/genai-gateway-capabilities

Punto clave

El control debe hacerse antes de que el prompt llegue al modelo.

3.4 Observabilidad semántica

No es logging HTTP.

Es:

  • prompts
  • completions
  • tokens
  • uso de tools

Esto permite:

  • detectar anomalías
  • auditar comportamiento
  • entender decisiones

3.5 Routing inteligente y resiliencia

APIM permite:

  • fallback entre modelos
  • balanceo entre endpoints
  • circuit breaker

Esto es crítico cuando dependes de LLMs.

3.6 Semantic caching

  • cache basado en embeddings
  • reducción de latencia
  • reducción de coste

4. MCP + APIM: patrón correcto

[Agent / Copilot]
        │
        ▼
[APIM - AI Gateway]
        │
        ├── Auth
        ├── Prompt filtering
        ├── Token control
        ├── Observability
        │
        ▼
[MCP Server]
        │
        ▼
[Application / Domain]

5. Seguridad: cómo se mitiga realmente prompt injection

Error típico:

“el modelo lo gestiona”

No.

Estrategia correcta

1. Pre-filter en APIM

  • bloquear inputs maliciosos

2. Validación estricta en MCP

  • schema obligatorio
  • sin inputs libres

3. Dominio protegido

  • invariantes
  • validaciones

4. Observabilidad

  • detección de patrones anómalos

Regla de oro

Cada tool es potencialmente peligrosa.

6. Escalado de MCP en Azure (lo que diferencia a un arquitecto)

Aquí está el valor real.

6.1 Azure Container Apps (ACA)

Cuándo usarlo

  • cargas variables
  • arquitectura event-driven
  • simplicidad operativa

Patrón

Client → APIM → ACA (MCP Server) → Backend

Claves

  • stateless
  • autoscaling por concurrencia
  • cuidado con cold start

6.2 Azure Kubernetes Service (AKS)

Cuándo usarlo

  • alta carga
  • control fino
  • escenarios enterprise

Patrón

Client → APIM → Ingress → Pods MCP → Backend

Claves

  • estado fuera (Redis, DB)
  • affinity si hay sesiones
  • configuración de streaming (SSE)
  • HPA basado en métricas reales

Problema importante

MCP no es naturalmente stateless.

Tienes que diseñarlo como tal.

6.3 Azure MCP Server (managed)

https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/overview

Qué es

  • servicio gestionado
  • acceso a capacidades Azure vía MCP

Cuándo usarlo

  • acelerar integraciones
  • evitar infraestructura

Limitación

  • no sustituye tu backend

7. Arquitectura de referencia completa

                [Agents]
                    │
                    ▼
           [APIM - AI Gateway]
                    │
        ┌───────────┴───────────┐
        ▼                       ▼
[MCP Server Layer]     [Other APIs]
        │
        ├── Redis
        ├── Service Bus
        └── Databases
        │
        ▼
[Application / Domain]

8. Decisión arquitectónica

Sin APIM:

  • no hay control
  • no hay gobierno
  • no hay seguridad real

Con APIM:

  • tienes control plane
  • puedes escalar
  • puedes operar

MCP define cómo ejecutar.
APIM define qué está permitido ejecutar.

Para terminar

En sistemas con IA:

  • el modelo decide
  • MCP ejecuta
  • tu sistema responde

Pero alguien tiene que gobernar ese flujo.

En Azure, ese “alguien” es:

API Management como AI Gateway

Nota:

No expongas capacidades a un agente sin un control plane.
Porque en ese momento, ya no controlas el sistema tú.

Si revisas mis repositorios y artículos anteriores, verás que esta preocupación no es nueva.

En particular, llevo tiempo trabajando y escribiendo sobre piezas que hoy encajan directamente en este problema:

  • Reverse proxy y control de tráfico con YARP
  • Exposición y gobierno de capacidades (antes APIs, ahora MCP)
  • Evolución hacia modelos más dinámicos y agentic

Si conectas esos puntos, verás que el patrón es el mismo:

control del flujo, control de la ejecución y desacoplo de responsabilidades

Lo único que ha cambiado es el actor que está en medio.

Antes era un cliente.
Ahora es un modelo.

Y quizá ahora se entienda mejor por qué esta preocupación surgió en cuanto MCP empezó a hacerse mainstream: fue entonces cuando se hicieron evidentes, de forma bastante clara, muchas de sus carencias en escenarios reales.

Porque al final, el problema nunca ha sido la tecnología concreta.

El problema es no tener control sobre cómo se utiliza.