Durante los últimos meses agregamos MCP servers a una velocidad difícil de justificar.
GitHub.
Slack.
Jira.
Postgres.
AWS.
Documentación interna.
Herramientas propias.
Y en la mayoría de los casos la arquitectura se parece bastante a esto:
Claude Code
├── GitHub MCP
├── Slack MCP
├── Jira MCP
├── Postgres MCP
└── AWS MCP
Funciona.
También da un poco de miedo.
Porque a medida que los agentes empiezan a interactuar con sistemas reales, aparece una pregunta inevitable:
¿Quién decide qué herramientas puede utilizar el agente?
La respuesta tradicional fue:
“El prompt.”
Pero el ecosistema está empezando a converger en otra idea:
El prompting no es seguridad. La arquitectura es seguridad.
Y eso está dando origen a una categoría completamente nueva: los MCP Gateways.
¿Qué es un MCP Gateway?
Un MCP Gateway se ubica entre el agente y los servidores MCP.
En lugar de que Claude Code, Cursor o Copilot hablen directamente con cada herramienta, todas las llamadas pasan primero por el gateway.
La arquitectura pasa a verse así:
Claude Code
│
▼
MCP Gateway
│
┌────┼─────┐
▼ ▼ ▼
GitHub Slack Postgres
El gateway se convierte en un control plane para todas las herramientas disponibles para los agentes.
Cada llamada.
Cada permiso.
Cada credencial.
Cada política.
Todo pasa por él.
¿Por qué necesitamos esto?
Porque una laptop personal y una organización no tienen las mismas necesidades.
En un proyecto individual probablemente no importe demasiado si Claude tiene acceso completo a GitHub.
En una empresa es otra historia.
Imaginá:
- decenas de desarrolladores,
- cientos de repositorios,
- múltiples agentes,
- infraestructura productiva,
- datos sensibles,
- requisitos de compliance.
Dar acceso directo a todo deja de ser razonable muy rápido.
1. Control de Acceso por Herramienta
El caso más simple.
Supongamos que querés permitir:
github.list_issues
github.create_pr
Pero querés bloquear:
github.delete_repository
github.change_admin_settings
Con un gateway podés definir exactamente qué herramientas exponer.
Por ejemplo:
allow:
- github.list_issues
- github.create_pr
deny:
- github.delete_repository
- github.change_admin_settings
La parte importante:
el modelo nunca ve las herramientas prohibidas.
No puede invocarlas accidentalmente.
No puede alucinarlas.
Simplemente no existen.
2. Permisos Basados en el Usuario
No todos los usuarios necesitan las mismas capacidades.
Por ejemplo:
Equipo de Ingeniería
GitHub
Jira
Documentation
Plataforma
AWS
Kubernetes
GitHub
Terraform
Finanzas
Slack
Salesforce
Analytics
El mismo agente puede exponer herramientas completamente diferentes dependiendo de quién lo está utilizando.
Esto empieza a parecerse mucho a un IAM tradicional.
Solo que aplicado a agentes.
3. Auditoría Completa
Una de las funcionalidades más atractivas para entornos enterprise.
Cada invocación queda registrada.
Por ejemplo:
09:12
Usuario: greg
Agente: Claude Code
Tool: github.create_pr
09:15
Usuario: greg
Agente: Claude Code
Tool: jira.create_ticket
09:17
BLOQUEADO
Tool: aws.delete_cluster
Razón: política de seguridad
Esto responde preguntas fundamentales:
- ¿Quién ejecutó esta acción?
- ¿Qué agente la realizó?
- ¿Qué herramientas utilizó?
- ¿Qué fue bloqueado?
- ¿Cuándo ocurrió?
Para equipos de seguridad y compliance, esto es enorme.
4. Gestión Centralizada de Credenciales
Hoy muchos desarrolladores hacen algo parecido a esto:
15 MCP servers
×
20 desarrolladores
=
300 credenciales
No escala.
Un gateway permite centralizar credenciales.
El flujo pasa a ser:
Agente
↓
Gateway
↓
Backend
El agente nunca necesita acceder directamente a secretos sensibles.
El gateway maneja la autenticación y las credenciales quedan centralizadas.
5. Políticas de Ejecución
No todas las operaciones tienen el mismo nivel de riesgo.
Por ejemplo:
Permitido automáticamente
Leer documentación
Consultar issues
Buscar logs
Requiere aprobación humana
Modificar producción
Escribir en la base de datos
Ejecutar migraciones
Siempre bloqueado
DROP TABLE
terraform destroy
aws delete-cluster
Esto permite introducir niveles progresivos de autonomía.
Los agentes pueden trabajar rápido donde el riesgo es bajo y solicitar aprobación cuando el impacto potencial aumenta.
Algunos proyectos interesantes
El ecosistema todavía es muy joven, pero ya empiezan a aparecer implementaciones interesantes:
Microsoft MCP Gateway
Orientado a entornos Kubernetes y despliegues enterprise.
Permit MCP Gateway
Enfocado en autenticación, autorización y auditoría.
Lasso MCP Gateway
Gateway open source con fuerte foco en seguridad.
Pomerium MCP Gateway
Acceso basado en identidad y políticas centralizadas.
Todos apuntan al mismo problema:
cómo gobernar un ecosistema creciente de agentes y herramientas.
La verdadera historia
La mayoría de las discusiones sobre agentes siguen centradas en los modelos.
GPT.
Claude.
Gemini.
Pero las organizaciones grandes ya están empezando a preocuparse por otra cosa:
¿Cómo controlamos cientos de agentes accediendo a cientos de sistemas?
Porque el problema deja de ser inteligencia.
Pasa a ser gobernanza.
Y ahí es donde aparecen categorías completamente nuevas:
- Agent IAM
- MCP Gateways
- Policy Engines
- Agent Observability
- Agent Security
La intuición es bastante simple.
Si los humanos necesitan:
- autenticación,
- autorización,
- auditoría,
- políticas,
los agentes probablemente también.
Y es muy posible que dentro de algunos años consideremos normal tener un IAM para agentes del mismo modo que hoy consideramos normal tener uno para personas.
La próxima gran plataforma de infraestructura podría no ser para humanos.
Podría ser para agentes.