# MCP Gateway: La Próxima Gran Categoría de Seguridad para Agentes **URL:** \ **Category:** AI Dev Tools — General\ **Tags:** authentication, security, mcp-gateway, contro-de-acceso, mcp, seguridad\ **Created:** [29 Junio, 2026 21:08 UTC](https://www.yodev.dev/t/mcp-gateway-la-proxima-gran-categoria-de-seguridad-para-agentes/3505 "2026-06-29T21:08:11Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![Grego](https://yyz1.discourse-cdn.com/flex009/user_avatar/www.yodev.dev/grego/32/649_2.png) [@Grego](https://www.yodev.dev/u/Grego)\ **Post date:** [29 Junio, 2026 21:08 UTC](https://www.yodev.dev/t/mcp-gateway-la-proxima-gran-categoria-de-seguridad-para-agentes/3505/1 "2026-06-29T21:08:11Z")
![MCPGateway](https://canada1.discourse-cdn.com/flex009/uploads/inovacon/original/2X/7/7ed39c0ca1976504dac1693d52b7241c18756652.jpeg) 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: ```plaintext 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í: ```plaintext 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: ```plaintext github.list_issues github.create_pr ``` Pero querés bloquear: ```plaintext github.delete_repository github.change_admin_settings ``` Con un gateway podés definir exactamente qué herramientas exponer. Por ejemplo: ```yaml 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 ```plaintext GitHub Jira Documentation ``` ### Plataforma ```plaintext AWS Kubernetes GitHub Terraform ``` ### Finanzas ```plaintext 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: ```plaintext 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: ```plaintext 15 MCP servers × 20 desarrolladores = 300 credenciales ``` No escala. Un gateway permite centralizar credenciales. El flujo pasa a ser: ```plaintext 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 ```plaintext Leer documentación Consultar issues Buscar logs ``` ### Requiere aprobación humana ```plaintext Modificar producción Escribir en la base de datos Ejecutar migraciones ``` ### Siempre bloqueado ```plaintext 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.